KDE freezes/becomes unresponsive - SSD load

General system Newbie
1

Hello!

I have a problem related to SSD load (at least I think it is).

Every time I do something which writes does a lot of operations of my SSD, KDE becomes nearly unresponsive. I can’t open programs, can’t use most of the open ones and some windows get “stuck”.

This happens mostly when I download a game in Steam or update a few programs.

Things I tried:

  • I checked htop during that problem, but nothing spikes at all.
  • I added a zram swap file, just in case (didn’t have SWAP before), but it also didn’t improve the problem.

System info: https://0x0.st/8uS1.txt

  • My system is not located on the fastest SSD I have, but I don’t think this should cause THAT kind of issue.
  • I use X11 instead of Wayland because I have trouble with my Nvidia GPU + Wayland + Gaming

Any ideas how I could start troubleshooting that problem further?

Thanks in advance!
Liam

2

Hi and welcome to the forum.

Firstly your root partition is quite full (73% so you might want a slight tidy up there).

Simple things first; I’m not sure if you’ve ever trimmed your drives. If not run the following:

sudo fstrim -av

It will take a while to complete and I’d run it again after.

If that doesn’t help you probably want to look at the health of your drives next. There is information on smartctl on the Arch wiki - https://wiki.archlinux.org/title/S.M.A.R.T.#smartctl which I’d suggest you run for each of your SSDs.

3

Thanks for the reply!

sudo fstrim -av
image

Not sure why it can run that way on root, maybe because of luks?

I also checked

systemctl status fstrim.timer

Screenshot_20250309_114036
Screenshot_20250309_114036696×138 17.8 KB

and I think it runs trim automatically every week, if i interpret this correctly.

I ran a short and a long SMART test and both passed, so I guess at least the SSD is not dying without me noticing.

4

This may not tell you anything. Many Times physical and Filesystem damage is not picked up by SMART.
I would do a check of the disk (fsck, badblocks)

5

That should not happen even if your SSD is slow. Even with a broken SSD your GUI should still be responsive.

Have you tried a different DE, like xfce, gnome, etc.?

EDIT
One more question: Do you experience this slowness from day 1 of your endeavouros installation? If not, can you tell when it started to happen?

What does your journal say when it happens? Can you share the output of “journalctl -b” when this happend?

2 Likes
6

Maybe, you have to unlock with the discard option in /etc/crypttab. Not sure if the EOS installer puts it in by default.

7

If you want to do an fstrim right away you can simply refresh the luks device with the proper option:

cryptsetup refresh --allow-discards /dev/mapper/name-of-the-device

After that the fstrim command should work. If that is all ok you can make the --allow-discards option persistent in the LUKS header of the device so that it is automatically applied when the device is opened:

cryptsetup refresh --allow-discards --persistent /dev/mapper/name-of-the-device

1 Like
8

Your Bios version is quite dated. What drive is the os installed on?

lsblk -f

9

would do a check of the disk (fsck, badblocks)

Did do this, badblocks took a while but no errors, fsck no errors.

Have you tried a different DE, like xfce, gnome, etc.?

Not yet, but that’s a good idea, I will test this.

One more question: Do you experience this slowness from day 1 of your endeavouros installation? If not, can you tell when it started to happen?

Not sure if it happened right away. I think so, but I had quite some trouble with the Nvidia driver which might have caused me to overlook this issue at first.

What does your journal say when it happens? Can you share the output of “journalctl -b” when this happend?

Will check this.

Your Bios version is quite dated.

Oh yeah, you are right. Will update that, it’s been a while.

What drive is the os installed on?

/dev/sdb - Samsung 840 EVO