mojodoll
Registered User
Vorweg: ich poste das einfach mal auf gut Glück hier ins Dedicated-Server Forum, sollte es eher ins Monitoring/Serverhardware Forum passen - bitte moven.
Folgender Umstand - Dedicated Server von Manitu, verbaut sind 2 ST3500418AS, also 500gb 7,2k rpm Seagate HDDs.
Nun zeigt mir Munin seit dem 17.4 doch stark erhöhte Disk-Latency-Times an, von vorher maximal 80ms (eher im 60er Bereich), peaked jene nun auf bis zu 160-200ms und das recht konstant/häufig (siehe Anhängende Graphs).
edit: ausschliesslich auf sda, also der Systemfestplatte, auf sdb liegt eine encryptete partition für /home, dort ist alles in Ordnung.
Nun hat sich seit dem 17. eigtl. nichts nennenswertes geändert auf der Box, eine Wordpress install war so ziemlich das einzige (und die cached erst seit gestern ;>, und ist auch generell keineswegs so voluminös/gut besucht als dass da ein Zusammenhang bestünde).
Diagnose bisher:
- SMART output und -selftests: ok
- Temperatur auf niedrigem Niveau, 27° wkly avg
- IO ServiceTime / IOStat zeigen auch nichts unerwartetes
- Disk Throughput auch konstant niedrig
Habe mir gerade sysstat, also iostat emerged und beschäftige mich nun damit erstmal, hier schonmal der erste Output
Im Allgemeinen läuft nichts sonderlich anspruchsvolles auf der Kiste, 2 CMS (drupal/wp) unter nginx, ein Minecraftserver mit maximal 3 aktiven Spielern, ein kleiner Squid für einen User (mich), und dovecot/qmail für ~10 user.
Während ich den Post hier verfasse hab ich mir mal den top output angesehen, und festgestellt dass java, also der Minecraft-Server, mehr als die ihm zugewiesenen 2GB ram genutzt hat, schlussendlich waren dann 800mb in der swap belegt, da könnte ja durchaus ein Zusammenhang bestehen.
Habe den Daemon mal restarted, könnte durchaus sein dass das Problem dadurch behoben wird, mein Interesse gilt aber trotzdem der Frage: Wie kann ich zuverlässig herausfinden welcher spezifische Prozess (bzw. welcher "Vorgang") für Disk-Latency verantwortlich ist?
Nach fixem einlesen bin ich auf latencytop gestossen, das erfordert aber einen Kernelpatch (nicht wirklich eine möglichkeit, zumindest fürs erste) und eben sysstat/iostat, mit dem ich mich jetzt erstmal befassen werde.
Jmd. mit Tips/Anregungen/Erfahrungen um (in Zukunft) sowas besser zu diagnostizieren?
Folgender Umstand - Dedicated Server von Manitu, verbaut sind 2 ST3500418AS, also 500gb 7,2k rpm Seagate HDDs.
Nun zeigt mir Munin seit dem 17.4 doch stark erhöhte Disk-Latency-Times an, von vorher maximal 80ms (eher im 60er Bereich), peaked jene nun auf bis zu 160-200ms und das recht konstant/häufig (siehe Anhängende Graphs).
edit: ausschliesslich auf sda, also der Systemfestplatte, auf sdb liegt eine encryptete partition für /home, dort ist alles in Ordnung.
Nun hat sich seit dem 17. eigtl. nichts nennenswertes geändert auf der Box, eine Wordpress install war so ziemlich das einzige (und die cached erst seit gestern ;>, und ist auch generell keineswegs so voluminös/gut besucht als dass da ein Zusammenhang bestünde).
Diagnose bisher:
- SMART output und -selftests: ok
- Temperatur auf niedrigem Niveau, 27° wkly avg
- IO ServiceTime / IOStat zeigen auch nichts unerwartetes
- Disk Throughput auch konstant niedrig
Habe mir gerade sysstat, also iostat emerged und beschäftige mich nun damit erstmal, hier schonmal der erste Output
Code:
avg-cpu: %user %nice %system %iowait %steal %idle
2.77 0.39 0.88 1.36 0.00 94.60
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 15.61 227.33 131.14 934092323 538857088Im Allgemeinen läuft nichts sonderlich anspruchsvolles auf der Kiste, 2 CMS (drupal/wp) unter nginx, ein Minecraftserver mit maximal 3 aktiven Spielern, ein kleiner Squid für einen User (mich), und dovecot/qmail für ~10 user.
Während ich den Post hier verfasse hab ich mir mal den top output angesehen, und festgestellt dass java, also der Minecraft-Server, mehr als die ihm zugewiesenen 2GB ram genutzt hat, schlussendlich waren dann 800mb in der swap belegt, da könnte ja durchaus ein Zusammenhang bestehen.
Habe den Daemon mal restarted, könnte durchaus sein dass das Problem dadurch behoben wird, mein Interesse gilt aber trotzdem der Frage: Wie kann ich zuverlässig herausfinden welcher spezifische Prozess (bzw. welcher "Vorgang") für Disk-Latency verantwortlich ist?
Nach fixem einlesen bin ich auf latencytop gestossen, das erfordert aber einen Kernelpatch (nicht wirklich eine möglichkeit, zumindest fürs erste) und eben sysstat/iostat, mit dem ich mich jetzt erstmal befassen werde.
Jmd. mit Tips/Anregungen/Erfahrungen um (in Zukunft) sowas besser zu diagnostizieren?
Attachments
Last edited by a moderator: