If your system hangs at times this comment from the arch wiki may be of interest.
There are several key parameters to tune the operation of the virtual memory (VM) subsystem of the Linux kernel and the write out of dirty data to disk. See the official Linux kernel documentation for more information. For example:
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
- vm.dirty_background_ratio = 2
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data. As noted in the comments for the parameters, one needs to consider the total amount of RAM when setting these values. For example, simplifying by taking the installed system RAM instead of available memory:
- Consensus is that setting vm.dirty_ratio to 10% of RAM is a sane value if RAM is say 1 GB (so 10% is 100 MB). But if the machine has much more RAM, say 16 GB (10% is 1.6 GB), the percentage may be out of proportion as it becomes several seconds of writeback on spinning disks. A more sane value in this case is 3 (3% of 16 GB is approximately 491 MB).
- Similarly, setting vm.dirty_background_ratio to 5 may be just fine for small memory values, but again, consider and adjust accordingly for the amount of RAM on a particular system.
Another parameter is:
- vm.vfs_cache_pressure = 60
The value controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects (VFS cache). Lowering it from the default value of 100 makes the kernel less inclined to reclaim VFS cache (do not set it to 0, this may produce out-of-memory conditions).
What it’s saying in effect is that when caches are written it can result in a long delay while this happens. The kernel will generally do this in background but can also boost priority. Flash drives may be more suitable for large numbers but a modify write is very slow as is a clear.
You can see your current settings via
sysctl -a | grep dirty
I asked if my setting where the default in another thread but no answer. I ran without swap for a while so they may have been changed but they are as per the ones arch say are best to avoid. I have 24gB of ram.
The byte versions of that are zero’d when the % ratio’s are set and the same thing will happen to the ratio’s if bytes are set. The background figures are the point where the kernel starts being more aggressive. It’s of interest to me because my machine does block occasionally. Also there are disk accesses every 5 secs due to writeback checks timing. They hardly ever do anything so probably also relate to low memory systems from years ago.
You can also clear unused write caches via
echo 3 > /proc/sys/vm/drop_caches
echo 1 and 2 clear other things.
At the moment I am not sure what goes on in respect to read caching but there are oddities. For instance if I have firefox using a gig plus this may or may not clear when it’s closed. Also an update increased them markedly and they just stopped there. It’s hard to see why changes in the read cache needs should noticeably slow thing down. Only the need to load from a drive.
In order to see what is going on I’ve found top to be more useful than free. The man pages are pretty long. The main things to read are the meaning of the column headers and that a press of the f key can be used to change the sort order and which columns are displayed. Pressing it brings up a short help message at the top of the view. The cursor keys navigate that. Also that shift w saves the current settings for next time it’s run. . In fact many key presses do something while it’s running so take care, esc or q quit.