- iostat 2 ukáže vytížení disků (MBps i IOps)
- iotop ukáže konkrétní proces, který generuje hodně IO per second
- top ukáže procesy, které žerou CPU
- pak třeba existuje ještě latencytop = kde jaký proces tráví hodně času čekáním (v zablokovaném syscallu, třeba na
- přístup k disku apod).
Bohužel na dálku Vám mnoho neporadíme.
Pokud říkáte, že přihlášení někde na konzolu a "su" způsobuje vytížení systému, tak je to dobrá haluz! V památných dobách prvních soukromých serverů na Silicon Hillu zvládla 486 se 16 MB RAM nízké trojciferné počty uživatelů, kteří pracovali pravda tehdy ještě spíš v telnetu než v ssh. Chci říct, že ta korelace s "su" spíš vypdá, že si něco špatně vykládáte.
Pokud nepoužíváte mutt (starobylý mailový klient), tak se myslím nemusíte stydět, přidat opšnu -o noatime do fstabu klidně pro kořenový svazek. By default souborový systém *zapisuje* do metadat čas posledního čtení ze souboru, i když se ze souboru pouze čte. Tahle fičura je schopná srazit reálnou průchodnost na půlku nebo třetinu = zdvojnásobí nebo ztrojnásobí počet IOps generovaný čtecí aktivitou. Kromě toho zkracuje životnost flaškám (SSD).
Stejně tak zvednutí dirty_ratio a dirty_background_ratio může pomoci dost citelně. Je to hodně znát třeba při instalaci (balíčkovacím systémem apt apod.) nebo při kompilaci kernelu, na stroji s moderním výkonným procesorem a relativně pomalým točivým diskem. Máte otevřená dvě terminálová okna, v jednom třeba kompilujete kernel. Vidíte, jak rychle roluje výpis. V druhém okně provedete
echo "90" > /proc/sys/vm/dirty_ratio
echo "80" > /proc/sys/vm/dirty_background_ratio
a okamžitě si všimnete, že disk poněkud ztichnul (přestal tak zuřivě seekovat) a rolování výpisu kompilace se nápadně zrychlilo.
...zmínil jste se už, co to máte za linux? Ony se historicky vyvíjejí také diskové IO schedulery. Osobně ale nechci tvrdit, že zrovna výměna scheduleru bude mít ve Vašem případě nějaký význam. Schválně mrkněte do /sys/block/sda/queue/scheduler . Defaultní IO scheduler v moderních distrech (jednu dobu frčelo cfq, později bfq, dnes ani nevím) se obvykle snaží o co nejlepší "svižnost desktopu" = krátké latence. Ovšem navrub úhrnné sekvenční průchodnosti. Pro serverové nasazení by mohlo mít smysl, použít scheduler "deadline" nebo i "none" (noop). Aspoň to zkusit. Výsledek / vhodná varianta scheduleru záleží na konkrétním mixu zátěže.
Zda to všechno pomůže konkrétně ve Vašem případě, to je těžko říct.
Nemohu vyloučit, že se na tom lví měrou podílí zejména NFS - dost se na něj nadává :-)
Osobně používám NFS jenom pro read-only root při diskless bootu. Svazky pro užitečná data mám na Sambě, a provozuji na tom převážně sekvenční zátěž. Zato klidně desítky klientů simultánně. Jeden konkrétní můj server má nějaké staré úsporné Core2 duo. Úzkým hrdlem bývá spíš gigová síť než disky v serveru.
Jo a taky zkuste nainstalovat smartmontools a zeptat se disku pomocí "smartctl -a /dev/sda", jak se mu daří.
20 Odpovědí
5891 Zhlédnutí