I have a problem with the performance of my laptop. In fact I needed to install quite some things recently and the whole machine froze from time to time completely.
First some general information: I am running Archlinux with kernel version 4.19.11-arch1-1-ARCH at the moment. The machine has 8GB of RAM and two internal disks: one rotational disk and one SSD.
Now, I needed to access some data on the rotational disk. (Everything I write here only refers only to the rotational one. The SSD was not tested.) I found, that when copying data from the disk over the network, the host system almost froze. That means, that the graphical interface got irresponsive and I had to wait the termination of the process to gain access to my machine again. Mouse did no longer move on screen and and keyboard strokes where delayed by more than half a minute.
After the termination I did some tests with the disk and found that even a simple
ionice -c idle dd if=/dev/sda of=/dev/null bs=1M count=1000 status=progress
caused the problem. It is nothing related to the network.
Further investigations (looking at
free etc) gave the following results:
- No huge swappping was active.
- The CPU was most of the time idle except for 1-2 core(s) that were in IO Wait state. (20-30% in a 8 core system)
- There was plenty of RAM ready to use
- The load average (number of pending processes reported by
uptime) jumps to high values of over 13 and keeps there (even the longer running averages converge to these high values).
- As soon as the IO operation is interrupted, the machine quickly gets responsive again and the load drops to below 2-4.
I tried to find some information in the internet. Not much was found there. I only found the hint to look at the current IO scheduler. By default is is set to
mq-deadline for all disks.
I tried the other ones and it seems that
bfq works best in the sense that the whole problem is the least critical using it.
It does not vanish completely.
I would assume, that due to the
ionice class of
idle the impact on the overall system performance should be negligible.
In realty the system keeps responsive but with some obvious lag of some part of a second. Better than before but not perfect.
A recent formating of a VM's disk caused a complete lockup of the host system. I had to restart in a hard fashion. Using
bfq at least allowed to format the virtual disk.
As the machine was no longer resonsive in any way, I did not get any information from
dmesg. I do not know if anything crazily happening behind the scenes. I need to track down this problem. I found someone in the internet assuming a bug in the kernel. I do not know if this might be true. What can I further do?