Szinte mindennek kell IO - ha versengeni kell érte, akkor minden lassabb lesz. Majdnem minden processz olvasgat/írogat a diszkre vagy kommunikál olyan processzel ami ezt teszi. Az elvileg IO mentes processzek sincsenek biztonságban, mert a kód ott is IO-ból származik és a VM azt is könnyedén kidobja ha memória kell, hiszen újra be lehet húzni a diszkről. A versengést pedig tovább rontja a thrashing, mivel a kernel intenzívebben fogja kidobálni a cache-elt lapokat ha masszív IO van, a visszatöltésnél pedig már versengenie kell. A mai kerneleknél szinte minden akadozás ebből fakad.
"Otthon" kb a következőket lehet könnyen meglépni:
0. a rendszerdiszket a rendszernek dedikáljuk és lehetőleg SSD
2. a thrashing ellen be lehet vetni a cgroup memory limiteket vagy alkalmazás szinten kezelni a problémát man 2 fadvise -zal (van belőle LD_PRELOAD lib is 3rd party alkalmazásokhoz)
3. bevetni a CFQ IO scheduler prioritásokat (cgroup vagy nice/ionice alapon)
Az IO prioritások variálása amúgy közel se elég megoldás, mert írásnál nem sokat ér: a journaling miatt össze vannak kötve az adott fájlrendszerre író processzek bizonyos pontokon (pl journal flush), azaz elég gyakran be kell várniuk egymást.. Ilyenkor a priorizált IO még ronthat is a helyzeten.
Jó összetett probléma, doktorit lehetne írni egy-egy aspektusáról :)