[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] mmap() Frage



On Mar 06, 2007 at 1211 +0100, Bernd Petrovitsch appeared and said:
> On Thu, 2007-03-01 at 00:25 +0100, René Pfeiffer wrote:
> > [...]
> > Ich habe jetzt noch etwas ausprobiert. In meinem Fall habe ich noch
> > madvise() mit MADV_SEQUENTIAL dazugenommen, da ich das Logfile
> > sequentiell lese. Bei einem 1,5 GB Logfile auf einem 384+128 MB System
> > (RAM + Swap, Dual PII, ergo 32-Bit-System) stieg die Prozeßgröße stetig
> 
> Was für Kernel-Version läuft dort?

2.6.20 oder neuer.

> > an bis 100 MB ausgelagert waren. Ich habe dann dem mmap() Call noch
> > MAP_NORESERVE als Option dazugegeben, um zu verhindern, daß die Mapped
> > Pages im Swap Space landen. Jetzt ist der „gefühlte Speicherverbrauch”
> > des Prozesses geringer.
> 
> Was tut die Applikation eigentlich?

Eigentlich liest sie nur eine Datei sequentiell.

> Wenn die eigentlich nur ein Logfile (eher mehr als weniger) sequentiell
> liest, warum dann nicht einfach(er) read(2) und u.U. lseek(2) (bzw.
> fgets(3) und u.U. ftell(3)/fseek(3)) verwenden?

Ja, das geht in jedem Fall. Ich dachte mir nur ich verwende mmap(), weil
man dann bequemer auf die Daten zugreifen kann und im Userspace keine
zusätzlichen Puffer braucht.

> Bei mmap(2) muß der Kernel entscheiden, wann er gemappte Pages
> wiederverwendet. Da mögen obige Flags helfen, aber ich weiß nicht, wie
> "aggressiv" die im Kernel beachtet werden.

Der Kernel nimmt das als Ratschlag an. Was er dann wirklich tut,
entscheidet der VMM und die jeweilige Memory Situation. Ich habe die
Erfahrung gemacht, daß bei mmap() Lesevorgängen auf sehr große Files
immer alte Pages ausgelagert werden, weil RAM für Pages, die öfter
gebraucht werden, wohl einfach schneller ist. Das dürfte von Read Ahead
Mechanismen herrühren, da der Kern Teile der Datei „vorliest”. Man kann
die „swappiness” des Kerns via /proc/sys/vm/swappiness in einem Bereich
zwischen 0 (möglichst wenig auslagern) und 100 (möglichst viel
auslagern) einstellen. „swappiness” ist ein heiß diskutiertes Thema mit
fast schon religiöser Natur:

http://kerneltrap.org/node/3000

Defaultwert ist 60. Auf Laptops, die auf Akku laufen, empfiehlt es sich
den Wert auf 0 zu setzen.

> Wenn die Applikation mit read(2) explizit etwas in diverse Buffer liest
> (und die Buffer recycelt, sobald die Applikation sie nicht mehr
> braucht), hat die Applikation die vollständige Kontrolle über den
> verbrauchten Speicher, weil der Kernel nur die Pages verwenden wird, die
> hinter den Buffern liegen.

Das ist mir klar, und das werde ich auch implementieren, wenn die
Applikation sich zu arg aufführt. Bisher geht es mit MAP_NORESERVE und
„swappiness” eigentlich ganz gut. Ich hatte nur angenommen man könne
die Speichernutzung von mmap() besser steuern.

Viele Grüße,
René.

-- 
"From the delicate strands,
 between minds we weave our mesh:
 a blanket to warm the soul."
 --- Lady Deirdre Skye (SMAC) ---




powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010