0

For some times now, my Dell XPS 13 7390 has been lagging in a very annoying way. Startup time has got longer, and the laptop is sometimes very unresponsive.

After some investigation, it came to suspect the SSD. At first, it looks healthy. smartctl says:

(...)
SMART overall-health self-assessment test result: PASSED
(...)
Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged

However, gnome-disk's benchmark gives strange results: just after the sluggish startup, running the benchmark gives me a mediocre read rate (<300MB/s) and huge access time (20-30 msec).

Then I noticed that if I run the benchmark a second time, just after the first one, results are back to normal with a read rate of ~500MB/s and access time of 0.1 msec! And then the system is responsive again. But the lagging comes again after a while, although running the benchmark again seems to fix it... :-/.

I tried with slightly older versions of the kernel (down to 5.8.0.34), and notice that:

  • if linux-module-extras is not installed, the first benchmark I run after boot is ok;
  • if linux-module-extras is installed, I have the same strange behavior as described above.

So maybe one of the extra modules is messing with the SSD? And maybe the benchmark does something that puts it back in order?

Can anyone make sense of all this? Thanks in advance...

edit I first assumed that benchmark was doing some clean-up operation at the end that fixed the problem temporarily, but it does not always work. More probably, it is just the fact that I am doing nothing else than waiting for the benchmark to finish, allowing whatever causes the lag to cool down...

edit I just got a long period of lag, with no app running except for the software updater. iotop revealed that update-mime-database was consuming 99% of IO. The lag stopped once the update was over. This seems to be related to this issue. So background updates could be causing these seemingly random lags. Since the absence of extra-modules means no network, hence no background update, this is consistent...

Pierre-Antoine
  • 496
  • 3
  • 9
  • No problems here with the same equipment. Is the SSD properly trimmed? Should be setup properly by default, but perhaps your system was upgraded above older versions? – vanadium Feb 04 '21 at 17:22
  • @vanadium thanks for your feedback. I didn't know about trimming, thanks for the pointer! systemctl status fstrim.service (and fstrim.timer) both report as 'active'. Is there anything else I need to check? – Pierre-Antoine Feb 05 '21 at 08:45
  • Have "top" running in a terminal, and while you are having the lag, try to see what is using the processor. The list of top by default sorts most processor intensive processes on top. Maybe also have the kernel output displayed and updated continuously: sudo dmesg -w. There should be no or very few red error messages. Messages should not appear continuously. – vanadium Feb 05 '21 at 10:25
  • @vanadium thanks for your help. top and dmesg do not show anything suspect. However, iotop was instructive, see my edit above. – Pierre-Antoine Feb 10 '21 at 09:22

1 Answers1

0

I am quite confident that the lag is caused by background updates. In particular for the slow boot, systemd-analyze blame revealed that apt-daily.service was running for 7 minutes!

A workaround the "slow boot" issue was to do this: https://askubuntu.com/a/1085711/38648

To properly fix this issue, I guess the update-mime-database issue needs to be solved. There is another question on this: update-mime-database is the bottle neck of apt intall now, any workaround?

Pierre-Antoine
  • 496
  • 3
  • 9