Pierre Willaime writes:
I have a nvme SSD (CAZ-82512-Q11 NVMe LITEON 512GB) on debian stable (bulleye now).For a long time, I suffer poor I/O performances which slow down a lot of tasks (apt upgrade when unpacking for example).I am now trying to fix this issue.Using fstrim seems to restore speed. There are always many GiB which are reduced :
[...]
but few minutes later, there are already 1.2 Gib to trim again : # fstrim -v / / : 1,2 GiB (1235369984 octets) réduits Is it a good idea to trim, if yes how (and how often)?Some people use fstrim as a cron job, some other add "discard" option to the /etc/fstab / line. I do not know what is the best if any. I also read triming frequently could reduce the ssd life.
I do `fstrim` once per week by a minimalistic and custom script as cron job: https://github.com/m7a/lp-ssd-optimizationThere is no need for custom scripts anymore, you can nowdays enable the timer from `util-linux` without hassle:
# systemctl enable fstrim.timer This will perform the trim once per week by default.When the use of SSDs increased people tried out the `discard` options and found them to have strange performance characteristics, potential negative effects on SSD life and in some cases even data corruption (?) Back then it was recommended to use the periodic `fstrim` instead. I do not know if any of the issues with discard are still there today.
I also noticed many I/O access from jbd2 and kworker such as : # iotop -bktoqqq -d .511:11:16 364 be/3 root 0.00 K/s 7.69 K/s 0.00 % 23.64 % [jbd2/nvme0n1p2-] 11:11:16 8 be/4 root 0.00 K/s 0.00 K/s 0.00 % 25.52 % [kworker/u32:0-flush-259:0]
[...]
I do not know what to do for kworker and if it is a normal behavior. For jdb2, I have read it is filesystem (ext4 here) journal.
I highly recommend you to find out what exactly is causing the high number of I/O operations. Usually there is a userspace process responsible (or a RAID resync operation) for all the I/O which is then processed by the kernel threads you see in iotop.
I usually look at `atop -a 4` (package `atop`) for half a minute or so to find out what processes are active on the system. It is possible that something is amiss and causing an exceedingly high I/O load leading to the performance degradation you observe.
[...]
P-S: If triming it is needed for ssd, why debian do not trim by default?
Detecting reliably if the current system has SSDs that would benefit from trimming AND that the user has not taken their own measures is difficult. I guess this might be the reason for there not being an automatism, but you can enable the systemd timer suggested above with a single command.
HTH Linux-Fan öö
Attachment:
pgpyefRwXCrdE.pgp
Description: PGP signature