Boot and KDE very slow after installation

English Install/Boot/Login
#1

Hi,

I’m using Leap15.2 now for a few weaks and it starts running really slow after some time. Also the startup time is really slow.

I’m using a Thinkpad x230 with 8GB RAM and a 1TB WD Blue SSD. During install I encrypted the drive.

Thanks for your help!

**1) Slow KDE
**
The symptom is that the system is often unresponsive or very laggy. E.g. running krunner might take a few seconds to start, then there is another few second lag when typing.

I feel that there are multiple issues with my system. E.g. having firefox open for a while with lots of tabs put the system to its knees. It is typically getting better once firefox is closed, however the system is even then still far from what I’m used to running Linux on this and other laptops. Currently the memory is as follows, and I do experience some lag:


     >>> free -mh
                   total        used        free      shared  buff/cache   available
     Mem:          7.5Gi       3.3Gi       2.1Gi       646Mi       2.1Gi       3.2Gi
     Swap:         7.5Gi       950Mi       6.5Gi

There might be also issues with the SSD, with disk reads seeming very slow


     >>> sudo hdparm -Tt /dev/sda


      /dev/sda:
      Timing cached reads:   14646 MB in  1.99 seconds = 7346.54 MB/sec
      Timing buffered disk reads: 126 MB in  3.04 seconds =  41.47 MB/sec

When the system gets really slow, there seem to be a lot of audible writing happening.

I looked through journalctl and could find the following popping up very frequently:


     qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 21483, resource id: 75497482, major code: 19 (DeleteProperty), minor code: 0

The following error also occured every now and then:


    pam_kwallet5(su:session): pam_kwallet5: Couldn't fork to execv kwalletd

Not sure how to analyse this issue… I used the same laptop with Debian and XFCE before and it was flying…

**2) Slow startup
**
I think some of it might be caused by the slow decryption, which is ok I guess. But there are definitely other issues too. systemd-analyze blame shows output below. What is dracut and unbound anchor? How can I speed up the rest of the top 10 or so?


   >>> sudo systemd-analyze blame                        
         23.343s mandb.service
         16.025s unbound-anchor.service
         15.301s backup-rpmdb.service
         14.050s docker.service
         12.173s backup-sysconfig.service
         10.554s dracut-initqueue.service
          8.724s systemd-cryptsetup@cr_ata\x2dWDC_WD10SPZX\x2d08Z10_WD\x2dWX92AA01FZ9D\x2dpart2.service
          8.446s logrotate.service
          5.340s btrfsmaintenance-refresh.service
          5.111s display-manager.service
          4.937s systemd-tmpfiles-clean.service
          4.229s initrd-switch-root.service
          3.614s postfix.service
          3.309s plymouth-quit-wait.service
          3.035s apparmor.service
          2.974s polkit.service
          2.972s rsyslog.service
          2.905s udisks2.service
          2.659s mcelog.service
          2.566s firewalld.service
          2.544s smartd.service
          2.537s kbdsettings.service
          2.534s nscd.service
          2.530s vboxdrv.service
          2.498s check-battery.service
          2.457s avahi-daemon.service
          1.576s lvm2-pvscan@254:0.service
          1.362s tmp.mount
          1.140s home.mount
#2

Just for comparison – a Desktop machine with various disks – /dev/sdd is due to be retired …


 > inxi --disk
           ID-1: /dev/sda vendor: Intenso model: SSD Sata III size: 111.79 GiB 
           ID-2: /dev/sdb vendor: Western Digital model: WD10EZEX-60M2NA0 size: 931.51 GiB 
           ID-3: /dev/sdc vendor: Western Digital model: WD40EZRZ-22GXCB0 size: 3.64 TiB 
           ID-4: /dev/sdd vendor: Seagate model: ST3500418AS size: 465.76 GiB 
 > 



 # hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   22688 MB in  2.00 seconds = 11357.57 MB/sec
 Timing buffered disk reads: 1566 MB in  3.00 seconds = 521.47 MB/sec
 # 
 # hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   23218 MB in  2.00 seconds = 11622.68 MB/sec
 Timing buffered disk reads: 552 MB in  3.00 seconds = 183.89 MB/sec
 # 
 # hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   22404 MB in  2.00 seconds = 11214.72 MB/sec
 Timing buffered disk reads: 526 MB in  3.00 seconds = 175.17 MB/sec
 # 
 # hdparm -Tt /dev/sdd

/dev/sdd:
 Timing cached reads:   23192 MB in  2.00 seconds = 11609.41 MB/sec
 Timing buffered disk reads: 340 MB in  3.01 seconds = 112.79 MB/sec
  #

Yes, the buffered disk read rate on your Laptop’s SSD is only ½ the speed of the HDDs in the Desktop and, nowhere near the buffered disk read rate of the SSD in the Desktop …

  • Why did you encrypt the complete SSD?
  • What do you hope to achieve by encrypting the system partitions?
  • Is it really not sufficient to encrypt only those user directories containing sensitive information?
#3

I simply wasn’t aware that this could cause problems, particularly once it is decrypted when working with it. I sort of expected longer decryption, when booting, which definitely happens, but the system also is quite slow after the decryption.

I generally always had a separate partition for my user, and this partition has always been encrypted. I can’t recall having had problems, even when using larger SSDs.

Is the fact that the whole drive is encrypted really a potential cause for slow performance when working with the laptop?

To answer your question re purpose:

The main purpose of the encryption is to de-risk data loss when I forget the laptop while travelling, loose it or should it get stolen. So, I guess having the user partition only encrypted would be sufficient, if it would enhance performance.

Is there a way to test a) whether the encryption is the cause and b) to remove the encryption an re-encrypt only the user partition?

My drive is partitioned as follows:


/dev/sda          0.91 TiB WDC
/dev/sda1        8.00 MiB    BIOS Boot Partition
/dev/sda2        0.91 TiB     PV of system
/dev/system     0.91 TiB     LVM
/dev/system/home    0.59 TiB     XFS LV
/dev/system/root       318.01 GiB      BtrFS LV
/dev/system/swap     7.48 GiB    Swap LV

Thanks for the pointers and response!

#4

AFAIK, only by setting up with a parallel identical machine which has been installed with no encryption being used for the system partitions.

Please show us your partition set-up either with “lsblk --fs” or “inxi --partitions”.

#5

I do not understand this rationale. Do you suggest that you assume that the whole of an encrypted file system is decrypted on mounting it? Then where do you assume that all that the unencrypted data is stored? And what at a power outage? IMHO every read/write goes through the decryption/encryption algorithm after/before retrieved from/stored on the disk.

#6

Yes, exactly this.

#7

@peluch:

Please also note what the openSUSE documentation has to offer on this subject: <https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-cryptofs.html>

#8

Here you go!

NAME                                                FSTYPE      LABEL                 UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                                                                         
├─sda1                                                                                                                                      
└─sda2                                              crypto_LUKS                       c47bdad9-f79f-4ffc-80b3-9fb5f31f7203                  
  └─cr_ata-WDC_WD10SPZX-08Z10_WD-WX92AA01FZ9D-part2 LVM2_member                       A7l7ry-WCvN-243y-M6BL-xEKm-WNUN-2HyuYP                
    ├─system-swap                                   swap                              c53b3542-588b-491f-9099-166e568499da                  [SWAP]
    ├─system-root                                   btrfs                             ce882ab7-1823-4b2c-8835-055e6224fc2f      284G    10% /var/lib/docker/btrfs
    └─system-home                                   xfs                               c51b079c-eff6-47fc-99fb-265c4bd2712e    518.4G    14% /home

I did read up a little on encryption and it seems that there can be quite a substantial performance hit…

What would you recommend to encrypt as part of the installation process? Just the home partition?

#9

If you encrypt the home partition, then you should also encrypt swap.