Re: Speicherverbrauch und top unter FreeBSD 6.x

Alvar Freude <alvar(at)a-blast.org> wrote:
> schon länger ist mir aufgefallen: kann es sein, dass ab FreeBSD 6 bei
> top ein anderer Speicherverbrauch angezeigt wird als bei älteren
> Versionen,

In 7-current wurde vor kurzem ein neues malloc eingeführt,
das zu gewissen Anomalien bei der Anzeige des Speicherver-
brauchs von Prozessen führte (es wird erheblich mehr ange-
zeigt, als tatsächlich benutzt wird).

Das neue malloc wurde allerdings bisher nicht nach 6-stable
MFCt, daher wäre das vermutlich keine Erklärung für Deine
Beobachtung.

> evtl. werden alle genutzten Libraries etc. dazugerechnet?

Die werden grundsätzlich zur VSZ eines Prozesses dazuge-
rechnet. Das war aber schon immer so.

> Oder liegt das an amd64-Code?

64bit-Code benötigt natürlich tendenziell mehr Speicher,
da bestimmte Datentypen (z.B. Pointer) doppelt so groß
sind. Auch amd64-Maschinencode ist tendenziell auch etwas
größer als der entsprechende i386-Code (das wird aber
teilweise wieder dadurch ausgeglichen, daß 64bit-Opera-
tionen weniger Anweisungen benötigen). In der Praxis dür-
fte das allerdings nur einen geringen Unterschied machen,
d.h. keinesfalls Faktor zwei oder mehr.

> Denn ein normaler Apache ohne irgendwelche besonderen Module verbraucht
> laut top gleich beim Start schon >30 MB.

Das ist eigentlich nicht ungewöhnlich, wenn Du die ganzen
Standard-Module, mod_ssl, mod_perl und php drinhast.
Oder zählst Du die schon als »besondere Module«?

Es kommt natürlich auch darauf an, was Du mit »Speicher-
verbrauch« genau meinst. top(1) und ps(1) zeigen ja so-
wohl die virtuelle Größe (VSZ oder SIZE) als auch die
residente Größe (RSS oder RES) an.

Erstere beinhaltet sämtliche Pages des VM-Systems, die
dem Prozeß zugeordnet sind, was z.B. auch gemappte Dateien
und Devices beinhaltet, und Speicher, der zwar alloziiert
wurde, aber nie verwendet wird (und daher auch keinen
Speicher belegt). Manche Programme gehen mit sowas recht
großzügig um (prominente Beispiele sind der rpc.statd und
der X-Server), was ja auch nicht schadet.

Letzteres (die residente Größe) ist die Summe aller Pages,
die resident sind, also in physikalishen RAM gemappt sind.

Allerdings beinhalten _beide_ Angaben auch Pages, die meh-
reren Prozessen gleichzeit gehören. Das sind z.B. Pages
von Executables (wenn ein Binary mehrfach gestartet wird
-- auch von unterschiedlichen Benutzern --, liegt sein
Text-Segment nur einmal im Speicher), Libraries oder
Shared-Memory-Segmente, mit denen Prozesse untereinander
kommunizieren.

Wenn man also die RSS aller laufenden Prozesse zusammen-
zählt, kann die Summe durchaus erheblich mehr sein als
die Größe des RAM, und es kann trotzdem noch genügend
RAM frei sein.

> Außerdem stelle ich mir mal wieder die Frage, wie ich herauskriegen
> kann, wieviel Speicher die einzelnen Childs eines forkenden Prozesses (in
> diesem Falle Apache) geshared haben und wieviel sie jeweils selbst
> verbrauchen. Soweit ich das verstanden habe wird ja immer nur der gesamte
> Speicherverbrauch angezeigt, aber nicht der, den sich ein Prozess mit
> anderen teilt. Kann ich also irgendwie rauskriegen, wieviel Speicher sich
> die einzelnen Prozesse teilen?

Nö. Das ist auch gar nicht so ohne weiteres möglich, weil
die Information im VM-System nicht vorhanden ist. Soviel
ich weiß, verwaltet der Kernel nur eine Zuordnung von Pro-
zessen zu Pages, aber nicht umgekehrt. Der Overhead wäre
einfach zu groß, und der Nutzen gering.

Gruß
   Olli

PS: Übrigens, im Zweifelsfall würde ich der Ausgabe von
ps(1) mehr trauen als der von top(1). ps ist ein »native«
BSD-Tool, das entsprechend gepflegt wird, während top nur
»contributed« ist (Third-party), das zwar auch von BSDlern
integriert und gepflegt wird, aber manchmal ist es halt
nicht so richtig am Ball. Ich habe es schon mehrfach er-
lebt, daß die Ausgaben von top schlicht und einfach falsch
waren, während ps eine vernünftige Ausgabe produzierte.

-- 
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.
"Python is an experiment in how much freedom programmers need.
Too much freedom and nobody can read another's code; too little
and expressiveness is endangered."
        -- Guido van Rossum
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message