Nyní v pravý čas se mi to podařilo vyřešit sám, takže na to mohu alespoň sám navázat pro potomky.
Bohužel jsem ztratil původní problém při upgradu jádra, ale místo toho jsem získal nový, ještě horší ve výkonu a stejně těžké ho vystopovat. Techniky, které jsem našel, byly následující:
Nejprve blktrace /blkparse je nástroj, který mi docela pomohl. Umožňuje sledovat průběh jednotlivých I/O požadavků s mnoha užitečnými podrobnostmi, jako je například proces, který požadavek odeslal. Je užitečné umístit výstup na tmpfs , aby se manipulace s uložením trasování nezačala sama trasovat.
To však pomohlo jen zatím, takže jsem zkompiloval jádro s více funkcemi pro ladění. Konkrétně jsem našel ftrace docela užitečné, protože mi to umožnilo sledovat špatně fungující proces v prostoru jádra, abych viděl, co udělal a kde se zablokoval. Kompilace ladícího jádra také poskytuje funkční WCHAN výstup pro ps také, což může fungovat jako snazší způsob, jak zjistit, co proces dělá uvnitř jádra, alespoň pro jednodušší případy.
Také jsem doufal, že LatencyTop bude užitečný, ale zjistil jsem, že je dost chybný a také to, že zobrazuje pouze důvody latence, které jsou příliš "vysoké" na to, aby byly skutečně užitečné.
Také mi to přišlo užitečnější než iostat jednoduše zobrazit obsah /sys/block/$DEVICE/stat ve velmi krátkých intervalech, jednoduše takto:
while :; do cat /sys/block/sda/stat; sleep .1; done
Viz Documentation/iostats.txt ve zdrojovém stromu jádra pro formát stat soubor. Sledování v krátkých intervalech mi umožnilo vidět přesné načasování a velikost I/O shluků a podobných věcí.
Nakonec jsem zjistil, že problém, který jsem měl po upgradu jádra, byl způsoben stabilními stránkami, což je funkce zavedená v Linuxu 3.0, která v mém případě způsobila, že se Berkeley DB na delší dobu zastavila, když byly znečištěny stránky v jeho mmap'ed. regionální soubory. I když se zdá, že je možné tuto funkci opravit a také to, že problémy, které způsobuje, mohou být opraveny v Linuxu 3.9, vyřešil jsem nejhorší problém, který jsem zatím měl, záplatou Berkeley DB, abych mohl umístit soubory jeho oblasti do jiného adresáře. (v mém případě /dev/shm ), což mi umožňuje se tomuto problému úplně vyhnout.
Podle mých zkušeností nejjednodušší a nejpodrobnější statistický nástroj, který můžete nainstalovat pro sledování záhadných problémů s výkonem systému, je http://freecode.com/projects/sysstat aka. sar
určitě se chcete také podívat na výstup příkazu iostat, konkrétně kolik je vaše %iowait by mělo být pod 5-10% při normálním zatížení systému (pod 1,0 nebo tak).
podívejte se na výstup ps, pokud ve sloupci STAT vidíte stavy D, což znamená, že tyto procesy jsou uzamčeny a čekají na IO, velmi pravděpodobně jde o hardwarový problém s řadičem nebo diskem, zkontrolujte statistiky S.M.A.R.T, stejně jako dmesg a syslog, abyste našli stopy
zkontrolujte protokol sar a identifikujte doby špičky, pokud k tomu někdy dojde, a pokuste se tyto časy sladit s úlohami cron náročnými na disk, např. zálohování přes síť
můžete porovnat výkon svého disku pomocí bonnie++
Myslel jsem, že zmíním strace, i když tato otázka je nyní stará měsíce. Může to pomoci někomu s podobným problémem, kdo najde tuto stránku.
zkuste.
strace "application"
můžete také
strace -e read,write "application"
pouze zobrazit události čtení/zápisu.
Aplikace se načte jako obvykle (i když se spouští trochu pomaleji) a můžete ji použít jako obvykle, abyste vyvolali problém. Výstup se objeví v shellu, který jste použili ke spuštění strace.
Dobrá věc na strace je, že můžete vidět poslední volání funkce/kernelu v době, kdy aplikace spouští zpomalení. Možná zjistíte, že pokud je vaše /home účty jsou na NFS, pak má aplikace z nějakého důvodu potíže se souborovým I/O přes NFS.