KDE slow to load after login

HotDogEnemy · 2021-06-08 13:34:23

KDE takes about 30-40 seconds to load after login no matter whether I use startx (without autologin) or SDDM. However if I log out without rebooting and login again, KDE loads within 5 seconds. This also happens with Xfce, it takes 20 seconds to load after login. How can I decrease the time to load KDE?

Skunky · 2021-06-08 14:33:07

Maybe because without rebooting you still have KDE in your RAM cache?
30-40 is pretty quick for KDE to start, if you are using a mechanical drive

Last edited by Skunky (2021-06-08 14:33:58)

Durden · 2021-06-08 16:01:27

Have anything in your startup applications list? I've run into a couple instances where something in there would hang

HotDogEnemy · 2021-06-08 17:30:23

Skunky wrote:

Maybe because without rebooting you still have KDE in your RAM cache?
30-40 is pretty quick for KDE to start, if you are using a mechanical drive

Yeah, I'm using a mechanical HDD for KDE. I've seen GNOME take faster to load after login than KDE on my install, which seems strange if you consider that GNOME is a relatively heavier DE than KDE.

Durden wrote:

Have anything in your startup applications list? I've run into a couple instances where something in there would hang

No, I don't have anything in my Autostart list, which I believe is in System settings > Startup and Shutdown > Autostart.

Skunky · 2021-06-09 06:57:36

Gnome might be heavier in terms of memory and cpu usage but not for disk usage, both Gnome and KDE disk usage are sick though, even slower than windows 10 on a mechanical hard drive, this is the main reason why i only use light window managers as i only use mechanical drives.

Anyway just to get an idea of how fast (slow?) you should boot kde, how many seconds does it take e.g. to:
boot into multi.user.target
login
Wait for your shell to load
run htop

I suggest you launch htop just after logging into tty and check uptime because systemd-analyze might be unprecise

Last edited by Skunky (2021-06-09 07:14:44)

HotDogEnemy · 2021-06-09 09:15:54

Skunky wrote:

Gnome might be heavier in terms of memory and cpu usage but not for disk usage, both Gnome and KDE disk usage are sick though, even slower than windows 10 on a mechanical hard drive, this is the main reason why i only use light window managers as i only use mechanical drives.
Anyway just to get an idea of how fast (slow?) you should boot kde, how many seconds does it take e.g. to:
boot into multi.user.target
login
Wait for your shell to load
run htop
I suggest you launch htop just after logging into tty and check uptime because systemd-analyze might be unprecise

On booting up and logging into tty, htop reports an uptime of 30 seconds, while systemd-analyze gives:

Startup finished in 12.551s (firmware) + 1.856s (loader) + 3.287s (kernel) + 17.064s (userspace) = 34.759s 
graphical.target reached after 17.063s in userspace

I checked the uptime before and after starting KDE, which gave me a time of 54 seconds to load KDE. Doing this again after logging out but not rebooting gives me a time of 7 seconds to load KDE.
Doing the same while loading Xfce gives me a time of 25 seconds, and 3 seconds after logging out without rebooting. No idea if this is due to Xfce having high disk usage or something to do with my setup.
I tested this both on my user account and a freshly made user account, and the results were pretty much the same.

Last edited by HotDogEnemy (2021-06-09 09:45:21)

V1del · 2021-06-09 09:41:26

KDE accesses hundreds of config files during session setup which will simply be slow on a HDD. The best way to fix this is get yourself an SSD an putting your $HOME (... or at least .config and .cache) on there.

That it's faster after log out is simply explained by the fact that linux caches disk accesses so you don't roundtrip back to the slow HDD and can load all of these files from RAM.

FWIW a few things you might want to try is disabling the splash screen for KDE startup, as that leads to an implicit and not entirely necessary few seconds of delay, and what I'd personally do is change the IO scheduler to BFQ for rotational disks: https://wiki.archlinux.org/title/Improv … _scheduler and maybe disable the SMART service in

kcmshell5 kcmkded

that will lead to Plasma not warning you anymore should your HDDs start to fail but that check can be slow on certain disks.

Maybe post a

journalctl -b

after login so we can check whether there are any obvious delays, but from the outset this sounds pretty normal to me.

HotDogEnemy · 2021-06-09 10:20:44

V1del wrote:

KDE accesses hundreds of config files during session setup which will simply be slow on a HDD. The best way to fix this is get yourself an SSD an putting your $HOME (... or at least .config and .cache) on there.
That it's faster after log out is simply explained by the fact that linux caches disk accesses so you don't roundtrip back to the slow HDD and can load all of these files from RAM.
FWIW a few things you might want to try is disabling the splash screen for KDE startup, as that leads to an implicit and not entirely necessary few seconds of delay, and what I'd personally do is change the IO scheduler to BFQ for rotational disks: https://wiki.archlinux.org/title/Improv … _scheduler and maybe disable the SMART service in
kcmshell5 kcmkded
that will lead to Plasma not warning you anymore should your HDDs start to fail but that check can be slow on certain disks.
Maybe post a
journalctl -b
after login so we can check whether there are any obvious delays, but from the outset this sounds pretty normal to me.

I have already disabled the KSplash screen, and it did result in less time spent on loading KDE but only by a small amount.

My system is already using BFQ, this is the output of grep "" /sys/block/*/queue/scheduler :

/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sdb/queue/scheduler:mq-deadline kyber [bfq] none

I'd rather keep SMART on, could be useful in the future. Plus, I don't think SMART has anything to do with this, I tested the same on Xfce and it has the same problem as KDE. Please see comment #6 on this post, I've put more details there.

As for the journalctl logs, here's a pastebin : https://pastebin.com/q96ufdde

Skunky · 2021-06-09 12:28:39

Then nothing is wrong with your setup, 54 seconds it's exactly the time plasma should take to start on your system, i did some benchmark on mine (slower) to compare.
I usually boot in:
multi-user.target in ~40 seconds
X session with i3 ~54 seconds

Then i tried KDE Plasma:
1°st KDE boot: took the laughable time of 3 minutes and 20 seconds, and that's not all, it kept doing his tracking-miner stuff until 4 minutes(+40 seconds because of indexing), at that point it was ready to use.

I know KDE it's slower on 1°st boot so i gave it another chance.

2° KDE boot: took 2 minutes and 20 seconds, tracking stopped at 2 minutes and 30 seconds (+20 seconds because of indexing)

Last edited by Skunky (2021-06-09 12:41:56)

V1del · 2021-06-09 12:48:23

tracking-miner stuff is a GNOME thing though, does this improve if you mask the relevant user services e.g. just from the evolution space

systemctl --user mask evolution-addressbook-factory.service evolution-user-prompter.service evolution-calendar-factory.service evolution-source-registry.service #Unmask to reenable

and also check through /etc/xdg/autostart for similar services

HotDogEnemy · 2021-06-09 12:50:15

Skunky wrote:

Then nothing is wrong with your setup, 54 seconds it's exactly the time plasma should take to start on your system, i did some benchmark on mine (slower) to compare.
I usually boot in:
multi-user.target in ~40 seconds
X session with i3 ~54 seconds
Then i tried KDE Plasma:
1°st KDE boot: took the laughable time of 3 minutes and 20 seconds, and that's not all, it kept doing his tracking-miner stuff until 4 minutes(+40 seconds because of indexing), at that point it was ready to use.
I know KDE it's slower on 1°st boot so i gave it another chance.
2° KDE boot: took 2 minutes and 20 seconds, tracking stopped at 2 minutes and 30 seconds (+20 seconds because of indexing)

Huh, maybe I'll go learn i3 just to get a faster login speed
What about the loading time after logging out without rebooting?

V1del · 2021-06-09 13:01:15

Logging out and back in will be faster for 2 reasons:

The biggest: most data that had to be accessed from the slow HDD will be able to be read from RAM the second time around. If you want a proper test run
```
sync
echo 3 > /proc/sys/vm/drop_caches
```
from a root shell after logging out before going back in
Systemd retains the user dbus and session information for a while before bringing it down, afaik the default is 10 seconds, if you log back in immediately that can also be reused instead of having to be restarted, you might also want to enable KillUserProcesses to be extra sure https://wiki.archlinux.org/title/System … _on_logout

Last edited by V1del (2021-06-09 13:02:03)

HotDogEnemy · 2021-06-09 13:32:43

I terminated the X session and ran those commands before logging back in, KDE loading time was more or less the same as a fresh reboot.
So it's confirmed, the slow reading of config files on my HDD was the cause of the problem.

Skunky · 2021-06-10 08:10:34

With

systemctl --user mask evolution-addressbook-factory.service evolution-user-prompter.service evolution-calendar-factory.service evolution-source-registry.service #Unmask to reenable

Things improve a bit,
1°st KDE boot: 2 minutes and 53 seconds
2°nd KDE boot: 2 minutes and 12 seconds

@HotDogEnemy as expected logging out and back in, only take few seconds because of RAM cache

Last edited by Skunky (2021-06-10 08:11:02)

G3ro · 2021-08-22 20:22:41

For those interested, I opened a Feature Request on KDE Bugs regarding a faster start of KDE: https://bugs.kde.org/show_bug.cgi?id=441389

wudu · 2021-08-23 11:50:37

A possible improvement if you need to read data from mechanical disk would be a filesystem with enabled compression like btrfs. But since data != data (large vs. small files and if they are scattered over the disk) I'm not sure this could help

kokoko3k · 2021-08-23 12:11:21

Hibernate.

When I was still on mechanical drives, i solved the slow kde startup by hibernating on 3GB image instead of shutting down the PC.
Fast startup™ in 20 seconds from the bootloader.
I still do that today with kde on SSD and image on HDD; boot time is about the same of a full boot from ssd, but i still find hibernation handy.
Make sure to close heavy-on-ram applications (browsers...) before hibernating to avoid an unresponsive system at resume and/or use a larger image.
If you want to go deeper with fine-tuning, you could even use a preload daemon and restart his service at resume time or just before suspend to disk to have a snappy system when you resume it.
Preload instead of go-preload may be a more set and forget solution.
https://wiki.archlinux.org/title/Preload#Preload
I'd automate the killing of the browser and the restart of the preload deamon, then suspend to disk.

Last edited by kokoko3k (2021-08-23 12:26:54)

Arch Linux

#1 2021-06-08 13:34:23

KDE slow to load after login

#2 2021-06-08 14:33:07

Re: KDE slow to load after login

#3 2021-06-08 16:01:27

Re: KDE slow to load after login

#4 2021-06-08 17:30:23

Re: KDE slow to load after login

#5 2021-06-09 06:57:36

Re: KDE slow to load after login

#6 2021-06-09 09:15:54

Re: KDE slow to load after login

#7 2021-06-09 09:41:26

Re: KDE slow to load after login

#8 2021-06-09 10:20:44

Re: KDE slow to load after login

#9 2021-06-09 12:28:39

Re: KDE slow to load after login

#10 2021-06-09 12:48:23

Re: KDE slow to load after login

#11 2021-06-09 12:50:15

Re: KDE slow to load after login

#12 2021-06-09 13:01:15

Re: KDE slow to load after login

#13 2021-06-09 13:32:43

Re: KDE slow to load after login

#14 2021-06-10 08:10:34

Re: KDE slow to load after login

#15 2021-08-22 20:22:41

Re: KDE slow to load after login

#16 2021-08-23 11:50:37

Re: KDE slow to load after login

#17 2021-08-23 12:11:21

Re: KDE slow to load after login

Board footer