Re: Swap Control??

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Wed, 21 Dec 2005 11:20:46 +0100 (CET)

Dieter Deinert <dd(at)radio-do.ath.cx> wrote:
> Ich habe hier einen AMD64 mit 2G Ram (2Riegel) / 4G Swap(am Stück). 2
> SATA-Platten 6.0 stable

Bei so einer Konfiguration wäre es sinnvoller, den Swap auf
beide Festplatten aufzuteilen. Das sollte zumindest das
Problem der I/O-Contention etwas lindern, wenn die Paging-
Aktivität stark zunimmt.

> Gimp benutzt für die Bild-History einen eigenen, selbst angelegten
> Swapbereich. Der wird
> gleichbleibend fix bearbeitet. Digikam, KDE, Firefox etc. nutzen den
> Systemswap.
>
> Ich glaube zu ahnen warum Gimp das so macht:-((

Das liegt einfach daran, weil Gimp selbst am besten weiß,
welches das optimale Swapverhalten für seine Daten ist.
Der System-Pager, so clever er auch sein mag, ist zwangs-
läufig auf generische Heuristiken angewiesen und kann ja
nicht erraten, welche Speicherbereiche Gimp als nächstes
wohl benötigen mag.

Ein weiterer Effekt durch den separaten Gimp-Swap ist, daß
das VM-System entlastet wird (sofern die Programmierer von
Gimp schlau genug waren, mmap() und madvise() in geeigneter
Weise zu benutzen).

> In den ersten Minuten, bei den ersten Bildern... geht die Maschine sehr
> fix mit dem System-Swap um.
> Nach einiger Zeit wird die Swap-Nutzung immer extensiver (bis zu 90%)

D.h. eine oder mehrere Anwendungen benötigen zunehmend mehr
Speicher.

> UND immer langsamer,

Das ist logisch. Zunehmende Swap-Nutzung (und 90% ist
eigentlich schon kritisch viel) erhöht den Druck auf das
VM-System, es muß dann zunehmend mehr Zeit mit Paging-
und Swapping verbringen. Wenn es aufgrund von Speicher-
mangel dann sogar anfangen muß, Teile von Anwendungen
auszupagen (oder gar ganze Prozesse auszuswappen), die
gerade in Benutzung sind, dann wird das System natürlich
erheblich langsamer.

> trotzdem das immer nur 1 Bild bearbeitet wird.

Bist Du sicher, daß immer nur ein Bild bearbeitet wird?
Wenn immer mehr Swap benutzt wird, dann wird normalerweise
auch immer mehr benötigt. Deine 2 Gbyte RAM müssen ja für
irgendwas verwendet werden -- für Caching allein kann das
nicht sein, da es da Limits gibt (die man normalerweise
auch nicht verändern sollte). Schau mal in der Prozeßliste
nach, welche Prozesse am meisten Speicher benötigen.

> Die Swapnutzung pendelt dabei zwischen 5-90%. Beginnt meist klein, läuft
> dann hoch bis zu 90%,
> bleibt oben und zeigt zum Schluss Werte zischen 10-30%.Die IN-OUT Werte
> pendeln zwischen 2000-3000 k.

Meinst Du die Spalten "pi" und "po" in der Ausgabe von
"vmstat 5"? 2000k-3000k ist da extrem viel. Wunder mich
nicht, daß das System kaum noch reagiert. Interessant
wären auch die anderen Spalten zwischen "flt" und "sr".
Insbesondere "sr" gibt einen guten Anhaltspunkt dafür,
wie groß der Druck auf das VM-System ist.

> Es wird permanet auf die Platte zugegriffen.

Logisch. :-)

> Schließen /Neustarten der Programme bingt nicht viel. Swapctl hilft mir
> da auch nicht wirklich weiter.

Naja, was sollte swapctl auch tun.

> Frage: Gib es irgendeine Möglichkeit, den Swap zu kontollieren bzw.
> aufzuräumen?

Das tut das VM-System bereits.

Erstens könnte ein Software-Problem vorliegen. Zum Bei-
spiel eine Anwendung, die alle Daten cacht, die Du bisher
bearbeitet hast. Dies kann z.B. auch der X-Server sein,
der aufgrund eines Bugs viel zu viele Pixmaps cacht.
Oder ein Programm erzeugt Shared-Memory-Segmente (SysV
IPC) und gibt sie aufgrund irgendwelcher Umstände nicht
mehr frei (normalerweise ist der SysV-IPC-Speicher be-
grenzt, aber das kann man einstellen). Das kannst Du Dir
mit »ipcs -a« angucken.

Wenn das Problem sich nicht softwareseitig lösen läßt, gibt
es nur eins: Du brauchst mehr RAM. Swap kann RAM ja nicht
ersetzen, sondern nur vorübergehende Spitzen abfedern -- so
eine Art Tankreserve, damit das Auto nicht sofort stehen-
bleibt, wenn der Zeiger auf Null ist.

> Bzw. ist es ein Denkfehler den Systemswap verantwortlich zu
> machen?

Eine Festplatte ist nunmal eine Faktor > 1000 langsamer als
RAM. Und bei 90% Füllung ist der Verwaltungsoverhead schon
recht groß; der Prozessor ist dann überwiegend mit dem
Scannen, Freigeben, Page-in und Page-out beschäftigt, so
daß noch weniger Taktzyklen für Deine eigentlichen Anwendun-
gen übrigbleiben.

Das Problem ist einfach, daß für die Art Deiner Anwendungen
zu wenig RAM vorhanden ist. Du mußt entweder versuchen,
Deine Anwendungen genügsamer zu machen (vielleicht ist dort
auch einfach nur ein Memory-Leak oder sonstiger Bug vorhan-
den), oder mehr RAM in die Kiste stecken.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 21 Dec 2005 - 11:21:59 CET

search this site