Re: IOWait Problem
Am Sonntag, 21. Oktober 2012 schrieb Markus Schulz:
> > > > 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.
>
> aehm, der Rechner dient ausschließlich der sun-jvm. Diese bekommt daher den
> größten Brocken direkt zugewiesen (-Xms == -Xmx, da die jvm ihren Speicher
> selbst verwaltet. Das Betriebssystem hat dann eigentlich mit der
> Speicherverwaltung nicht mehr so viel zu tun, die ~13GB an java sind halt
> dauerhaft vergeben.
>
> Ich formuliere meine Frage jetzt um:
> was bedeutet exakt pgpgin/s? und wie kann ich ohne Swap noch pages von disk
> lesen?
Ich bekomme den Eindruck, als möchtest Du das Problem auf eine andere
weise lösen, als ich für sinnvoll erachte.
Wie Java den Speicher verwaltet, damit kenne ich mich nicht sonderlich
gut aus.
Und meine Empfehlung, die ich hier in diesem Rahmen noch zu geben
bereit ja, hast Du auch.
Daher klinke ich mich hier aus.
Zu der Bedeutung:
pgpgin/s
Total number of kilobytes the system paged in from disk per second.
(man sar)
Stichwort: Page faults, eine Page ist nicht im Speicher und die
virtuelle Speicherverwaltung lädt sie ein.
merkaba:~> echo 3 > /proc/sys/vm/drop_caches | /usr/bin/time -v perl
Command being timed: "perl"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.79
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1812
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 3
Minor (reclaiming a frame) page faults: 520
Voluntary context switches: 13
Involuntary context switches: 3
Swaps: 0
File system inputs: 3488
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Hier als Major Page Fault.
Einige Fälle dafür:
- Teile von ausführbaren Programmen oder Bibliotheken laden.
- Via mmap() in den Speicher eingeblendete Dateien
- Ich glaub da war noch was, fällt mir aber grade nicht ein.
Abgesehen davon habe ich noch grob in Erinnerung, dass auch eine PostgreSQL
auf dem System läuft. Die braucht auch RAM.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: