[LUGA] Mit freundlicher Unterstützung von:
OCG

Mail Thread Index


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

Re: [luga] mmap() Frage



On Thu, 2007-03-01 at 00:25 +0100, René Pfeiffer wrote:
> On Feb 22, 2007 at 1148 +0100, Bernd Petrovitsch appeared and said:
> > On Thu, 2007-02-22 at 11:28 +0100, René Pfeiffer wrote:
> > [...]
> > > Dateien eigentlich keine Speicherprobleme im Sinne von OOM hervorrufen
> > > dürften.
> > 
> > Ja, sollte so sein.
> 
> 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?

> 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?
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?

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.
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.

[...]
	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




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