[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 1334 +0100, Bernd Petrovitsch appeared and said:
> On Tue, 2007-03-06 at 12:29 +0100, René Pfeiffer wrote:
> > 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.
> 
> Da macht mbMn 128MB Swapspace bei 384MB RAM wenig Sinn.

Das war auch die einzige Kiste, die gerade frei war. Die ist sowieso
nicht für diese Dinge konfiguriert und wartet eigentlich auf die
Pension.

> Der 2.6er allokiert im Swapspace auch Pages, die im RAM sind - und
> gelegentlich lagert er die auch "auf Verdacht" aus, weil ihm und der
> Disk grade fad ist.

Na ja, eigentlich benutzen meine Kisten kaum Swapspace. Der 2.4 Kern war
da viel ärger als der 2.6. Das heißt zwar alles nichts, weil es keine
vergleichbare Aussage über die Auslastung der Kisten gibt.

> [...]
> > 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
> 
> Ja. Aber wenn du jede Page eh nur einmal liest, bringt das mbMn nicht so
> arg viel.

Nein, allerdings könnte es sein, daß da noch I/O-Operationen dazukommen.
Der Code entsteht erst gerade.

> > [...]
> Und das ist worauf ich hinauswollte:
> Eigentlich willst Du das ge-mmap-te gar nicht swappen (weil die
> Applikation es eh nur einmal braucht). Das weißt Du (und jetzt ich und
> die luga@ Liste und Google und ...), aber weiß das der Kernel drunter?
> 
> Wohl nicht a priori.
> 
> Deshalb will man/Du schlauerweise dem Hinweise geben. Gut.

Ja, und genau das habe ich bisher herausgefunden. Das wußte ich noch
nicht als ich die Frage gestellt habe.

> Nur zum einem braucht Mechanismen dafür (madvise(2), /proc/sys/...,
> etc.) und zum anderen müssen die in der VM natürlich auch
> "berücksichtigt" werden.

Es gäbe noch die Optionen MADV_RANDOM und MADV_DONTNEED, die weniger
Read Ahead Caching provozieren. Ich werde das mal vergleichen.

> *Wie* gut die berücksichtigt werden, müßte man 1mal untersuchen (und das
> istmbMn eher mühsam und nach 2 Kernel-Releases ist es vielleicht wieder
> anders).

Ich probiere es gerade. Ich dachte jemand auf dieser Liste hat auch
schon mal ähnliche Experimente gemacht.

> Und bei "nur sequentielles Lesen" ist das Verwenden von mmap(2) mbMn
> eher unüblich - und das könnte schon ein Grund sein, warum da
> Kompromisse gemacht werden bzw. gar nicht wirklich ausgereizt wird.

Klar, ich bin auch sicher, daß Andrew Morten weiß wovon er redet.
Eigentlich ging's mir mehr um das Sparen eines Puffers in meinem Code,
und meine primäre Sorge dabei war der OOM-Killer, der aber seit Einfügen
der madvise() Optionen sich nicht mehr blicken ließ (das lag wohl auch
an der antiken Maschine, auf der das lief).

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