When heavy writing on ssd, ui not responsive

Hello everyone,


 ██████████████████  ████████     henres@henres-home
 ██████████████████  ████████     OS: Manjaro 22.0.0 Sikaris
 ██████████████████  ████████     Kernel: x86_64 Linux 5.19.17-2-MANJARO
 ██████████████████  ████████     Uptime: 37m
 ████████            ████████     Packages: 1787
 ████████  ████████  ████████     Shell: zsh 5.9
 ████████  ████████  ████████     Resolution: 9120x2560
 ████████  ████████  ████████     DE: GNOME 43.1
 ████████  ████████  ████████     WM: BudgieWM
 ████████  ████████  ████████     WM Theme: Adwaita
 ████████  ████████  ████████     GTK Theme: adw-gtk3-dark [GTK2/3]
 ████████  ████████  ████████     Icon Theme: Papirus-Maia
 ████████  ████████  ████████     Font: Noto Sans 11
 ████████  ████████  ████████     Disk: 2,4T / 4,5T (54%)
                                  CPU: AMD Ryzen 9 5950X 16-Core @ 32x 3.4GHz
                                  GPU: NVIDIA GeForce RTX 2080 SUPER
                                  RAM: 21384MiB / 32007MiB

Each time I unzip a package, download a file or copy large file, the UI is unresponsive.
If I’m looking at a video, I can continue to see the video, but the UI is completely unresponsive.
Can’t change window, or anything.

Got this problem with different disk. But currently, got this problem over a samsung 870 QVO 1to (for my home disk) and a Samsung 980 pro 500gb.

Thanks in advance for your helps !

You need adjust your swap and swappines.

https://linuxatemyram.com - heavy disk IO will use your RAM as cache.

Also take into account that /tmp is mounted on tmpfs which will - when in use - allocate up to 50% or the available RAM.

So yes - depending on your usage - you may experience various effects from the system at work.

There is no golden rule - just search the forum for dirty bytes cache bytes - something like that - use :mag: in upper right corner

image

Thanks a lot for your help.
I have 36gb of swap. Is it too much ?
Will see if I can find something on dirty bytes cache bytes.

Thanks

Hello,
I already have changed the swapiness to 10.
Still have the problem.
Can’t find post related to dirty bytes cache bytes There is a lot of post not related to it.
Thanks

I just try to uncompress some archives. And still get the UI freeze (mouse can still move).
No swap at all get used when trying. Try with 3 archives at the same time, 1.5go, 1.9go and 4go. Have 32gig of ram. It should not swap at all …

I’m unable to recreate your issue on my laptop, which has 16GB of RAM.

(Whether large copies over SMB/NFS, or decompressing a gigantic archive file that is 4GB in size.)


What is the output of these values:

sysctl vm.swappiness

sysctl vm.max_map_count

sysctl vm.dirty_background_bytes

sysctl vm.dirty_background_ratio

sysctl vm.dirty_bytes

sysctl vm.dirty_ratio

Thanks for your help @winnie

Here what you ask:

vm.swappiness = 10
vm.max_map_count = 65530
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_ratio = 20

I set six particular values of mine some time ago (and some of these I forget why :sweat_smile:), but the main problem I was addressing was to speedup rsync tasks and heavy metadata operations. I tailored it to my 16GB RAM system.

vm.swappiness = 10
vm.max_map_count = 131072
vm.dirty_background_bytes = 16777216
vm.dirty_background_ratio = 0
vm.dirty_bytes = 50331648
vm.dirty_ratio = 0

I created a custom config file under /etc/sysctl.d/99-custom.conf, which contains the above settings. Albeit, without any “white spaces” (but that shouldn’t matter.)

I have a 1GB swap file configured and located at /swapfile (which rarely seems to be used.)

You could try the above 6 settings all together, and see if it makes any difference. (I’d test it after a reboot. Just keep in mind that rebooting will clear your buffers/cache in RAM.)

Here is the contents of my custom /etc/sysctl.d/99-custom.conf file:

vm.swappiness=10
vm.max_map_count=131072
vm.dirty_background_bytes=16777216
vm.dirty_background_ratio=0
vm.dirty_bytes=50331648
vm.dirty_ratio=0

So I tried with your setting, and it’s still exactly the same. Don’ t know what else to try …

You could try editing your default grub config and add nvme_load=YES to the kernel command line.

sudo nano /etc/default/grub

Then rebuild grub.cfg and restart.

sudo grub-mkconfig -o /boot/grub/grub.cfg

Just to confirm, the settings were permanently applied even after a reboot?


What queue scheduler is currently configured?

cat /sys/block/nvme0n1/queue/scheduler

(Replace nvme0n1 with your actual NVMe devices.)

Do the same for your other SSD (sda?)

The home partition is mounted in a QVO that is not an nvme SSD.

# This one is the root / mount, with the 980 pro
╰─$ sudo cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq 

# This one is the /home mount with the qvo.
╭─henres@henres-home ~ 
╰─$ sudo cat /sys/block/sdd/queue/scheduler    
[none] mq-deadline kyber bfq 

Those are fine.

To rule this out? :point_up:

Yes, same at every reboot.

How long has this behavior been apparent?

I have two different computers (both KDE) one with 16GB of RAM, the other with 12GB. I can’t recreate the issue, even if I’m simultaneously copying a large file over an SMB share and uncompressing a large archive on the SSD.

The notable effect is it might slow down the copy operation itself (too much happening on the same storage device at the same time), but my UI remains the same.


Maybe your SSDs need a trim?

sudo fstrim -va

It will only output the results to filesystems with TRIM support.

Make sure your weekly fstrim.timer is also enabled and active:

systemctl status fstrim.timer

Since 1 year I think.

The problem occurred on my old 9900k setup and now occurred on my 5950x setup. (I completely reinstalled everything between the setup, I switched from Solus to Manjaro, And it was the best idea I got from a long time <3)
Got the problem on solus OS before. And now the same occurred on manjaro with gnome or budgie UI.
It is very frustrating, I use linux as a daily os and this problem bother me a lot as git clone can freeze the UI …

So I tried to enable TRIM for luks but only arrive to set it for the /home.
But anyway. The problem occurred for both drive. So trim enable for /home and I trimmed the partition manually and still doing the same error.

Still thanks for your help !

Can you have an instance of htop visible while you are doing a massive copy operation?

Does it use much CPU?

Something’s not making sense here. Why the entire GUI would just freeze on you is strange.

I can understand if the file browser starts to act laggy, or other data/metadata operations are sluggish at the same time. But the GUI? :woozy_face:

I think the trim worked. And I was tricked by nautylus … when you click to the icon showing the time remaining and the speed you can’t click anywhere else on the screen (Thought It was freeze …).
But regarding the copy/move and download from firefox everything seem to work well.
I will see on the run If encounter this problem again.

Thanks a lot for your help !

1 Like

Since you mentioned you’re using LUKS encryption.

Confirm the following:


:white_check_mark: Make sure your timer is indeed enabled and active (and shows an upcoming “Trigger”):

systemctl status fstrim.timer

If not, enable and start it.

systemctl enable fstrim.timer

systemctl start fstrim.timer

:white_check_mark: Make sure your home partition’s entry in the crypttab has discard in its options column.

sudo cat /etc/crypttab

If it’s missing, add it using nano.

Also comment out the entry that references your root partition. This is handle by the initramfs!


:white_check_mark: Make sure your boot entries are using nvme_load=YES and discard and/or allow-discards in the loader options.

cat /etc/default/grub | grep GRUB_CMDLINE_LINUX_DEFAULT

For example, mine looks something like so:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_load=YES cryptdevice=UUID=XXXXYYYYZZZZ:luks-XXXXYYYYZZZZ:allow-discards rd.luks.options=allow-discards root=/dev/mapper/luks-XXXXYYYYZZZZ apparmor=1 security=apparmor udev.log_priority=3

Notice the :allow-discards attached to the end of the cryptdevice line? Also the line that reads rd.luks.options=allow-discards

Then you can confirm all partitions are allowing TRIM through the LUKS layer:

sudo fstrim -va