Re: IOWait Problem
Am Mittwoch, 17. Oktober 2012 schrieb Markus Schulz:
> Nabend,
[…]
> Nabend,
>
> Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> > Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> > umgebrochen, ist aber für meine Antwort egal.
> >
> > Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
>
> hab sie einfach mal als text-attachment angehangen.
> Roundcube konnte die format=flowed Mail problemlos darstellen.
> KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
Einfach mal so daher geschrieben, was?
KMail aus Debian nutzt Akonadi derzeit noch gar nicht. Das einzige, was
im Standard-Setup auf Akonadi aufsetzt, ist das Adreßbuch. Den Kalender
habe ich aber auch umgestellt.
> > Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B. wo
> > es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise läßt
> > sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber, das ganze
> > etwas netter aufzubereiten, wenn du hier schon um kostenlosen Support für
> > einen Unternehmens-Server bittest.
>
> - 8x Intel(R) Xeon(R) CPU X5365 @ 3.00GHz"
> - 16GB Ram
> - 10k 72GB Disks im HW-Raid1 (hier müsste ich den Admin fragen, bin eigentlich
> nur für die Software im JBoss zuständig)
Naja, das ist schon ordentlich, bis auf das RAM.
> > Auch fehlt ein Blick auf die Prozesse.
>
> auf der Kiste läuft sonst nix relevantes: ssh/ntpd/nagios-statd/nfs-
> client/bacula-fd. Alles keine Speicherfresser....
> mal aktuelle Daten um eine Vorstellung zu bekommen:
> # ps -eo cputime,etime,pmem,rss,sz,vsz,comm | grep -v "^00:00"
> TIME ELAPSED %MEM RSS SZ VSZ COMMAND
> 00:01:47 108-11:24:18 0.0 0 0 0 events/7
> 00:09:27 108-11:24:18 0.0 0 0 0 kswapd0
> 01:52:20 108-11:24:06 0.0 0 0 0 kjournald
> 00:01:07 108-11:24:05 0.0 0 0 0 edac-poller
> 00:06:01 108-11:24:03 0.0 0 0 0 flush-8:0
> 00:03:19 108-11:22:39 0.0 0 0 0 bond0
> 00:01:00 108-11:22:37 0.0 6092 8391 33564 nagios-statd
> 00:03:08 108-11:22:37 0.0 1024 8533 34132 ntpd
> 00:49:26 108-11:22:36 0.0 3384 38131 152524 bacula-fd
> 00:01:17 36-04:50:10 0.0 1116 29929 119716 rsyslogd
> 00:01:17 23-04:35:53 0.0 7236 11091 44364 munin-node
> 01:29:56 07:08:49 65.2 10747944 4430036 17720144 java
Das meinte ich anders: Ich habe atop nicht umsonst erwähnt. Ich möchte
wissen, welche Prozesse zu den Zeiten mit der Page In/Out-Aktivität aktiv
sind.
Die Information wird Dir ps nicht auf die Weise liefern können wie atop.
> Der gesamte Speicher ist für den JBoss, der deshalb auch mit reservierten
> 12,5GB Heap und 512MB PermGen gestartet wird.
>
> iotop und co. wurde bereits herangezogen. der jboss erzeugt keine große io-
> Last (die lokale Platte enthält quasi keine Laufzeitdaten die cache-relevant
> sind).
> Man sieht nur kernel-threads mit hoher io-Last. (falls es ohne Swap nochmal
> auftritt protokolliere ich das)
Aha.
Welche Kernel Threads sind das?
Diese Informationen sind wichtig.
> > Für einen recht netten Überblick empfehle ich atop zu verwenden. Das kann
> > I/O nach Prozess anzeigen.
> >
> > Interessanterweise gleich dann, wenn das Problem auftritt.
> > Laut
> >
> > > 14:05:01 kbmemfree kbmemused %memused
> > > kbbuffers kbcached kbcommit %commit
> > > 14:15:01 107832 16363460 99,35 162796 809300 14976404
> > >
> > > 77,12
> > ist die Speicherauslastung ziemlich hoch, wenn ich mich da nicht in den
> > Spalten vertan hab. Und das, was für Caches bereit steht, ziemlich
> > niedrig.
> >
> > Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
> > auch nicht ausschalten.
>
> 800MB cache und 160MB buffers-cache sind in meinen Augen für die Kiste
> eigentlich ausreichend. Wie gesagt da liegen keine relevanten Daten auf der
> Platte die der JBoss braucht, die holt er aus dem Alfresco bzw. Postgresql.
> Der Rechner hat auch in der restlichen Zeit keine nennenswerte IO-Last.
16 GB RAM mit 800 MB frei für Caches? Da klingeln bei mir die Alarmglocken.
Ich würde eine Kiste so nicht laufen lassen.
Wenn das System bei 16 GB RAM nur noch 800 MB für Caches aufbringen kann,
wird es mit hoher wahrscheinlich mit zunehmender Betriebsdauer und
Speicherfragmentierung immer intensiver nach freien Pages suchen. Meiner
groben Erinnerung nach kann das mitunter auch als Last vom Kernel-Thread
kswapd auftauchen. Die Details stehen in meinem Schulungsfolien zum
Performance Tuning Kurs nach. Aber da schaue ich heute nicht rein.
Meine Empfehlung ist: Doppelt so viel RAM rein wie der Workload erfordert.
Oder wenigstens eineinhalb mal so viel. Das dürfte bei sehr viel RAM dann
auch reichen. Auf jeden Fall: Deutlich Spielraum für Caching lassen.
Aus meinem Bauchgefühl heraus folgende Empfehlungen:
- 2.6.32 => 3.2 Backport-Kernel und schauen, was passiert. Meiner groben
Erinnerung nach hat 3.2 bereits die Anti Fragmentation Patches integriert.
- 16 GB RAM dazu stecken und schauen, was passiert.
- oder: JVM von 12 auf maximal 8 GB reduzieren und schauen, was passiert.
Meines Erachtens dürfte angesichts der Kosten für Deine Arbeitszeit und
die etwaigen Kosten für einen Dienstleister, der sich das Problem anschaut,
die einfachste *und* kostengünstigste Möglichkeit sein, der Kiste noch
16 oder 32 GB zusätzliches RAM zu verpassen.
Mich würde doch arg wundern, wenn das von Dir beschriebende Problem
dann immer noch auftritt.
Wenn das alles nicht tut, dann würde ich Dir empfehlen, Dich nach einem
Dienstleister mit Spezialisierung im Linux Performance Tuning umzuschauen,
oder aber Dich näher mit atop zu befassen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: