PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Dockapp Mem Anzeige bei 89%



items
08.10.03, 19:56
Moin Forum,
ich habe hier ein Laptop mit 512 MB. Weil unter anderem Eclipse laeuft und mir das DIngens ein bisschen sehr traege vorkam hab ich mal ein Dockapp installiert, das CPU Last, Speicherverbrauch usw. anzeigt.
Gestaunt hab ich ja schon beim Start von Window Maker, weil mir da eine Speicherauslastung von 87% angezeigt wird (ohne das auch nur eine Applikation läuft). Starte ich dann aber noch Eclipse, komme ich auf 91%.
Mache ich allerdings ein ps -aux und addiere da mal ueber den Daumen den Speicherverbrauch, komme ich auch mit allerschwerstem Aufrunden aller Prozesse auf keinen Fall ueber 40%.
Jetzt ist die Frage, was spinnt. Die Dockapp, ps -aux oder ich? Auch kann ich mir beim besten Willen nicht vorstellen, das eine überaus schmale App wie Window Maker den groessten Teil meines Speichers schon beim Start verbraucht.

Kanns jemand erhellen?

Danke und Gruesse
items

Iluminat23
08.10.03, 21:07
gib mal in der konsole top ein
dann siehst du wieviel speicher er gerade verwendet

Sonny
08.10.03, 21:11
$ free
total used free shared buffers cached
Mem: 255892 252252 3640 0 6692 91512
-/+ buffers/cache: 154048 101844
Swap: 1188728 10132 1178596

wieviel RAM ist frei? 3640 Bytes :( ? Nee, 101844 Bytes :)

Berufspenner
08.10.03, 21:12
Hi@all

Wenn der Speicher voll ist und das System trotzdem ordentlich läuft, dann ist alles in Ordnung. Intelligente Systeme nutzen den zur Verfügung stehenden Systemspeicher voll und ganz aus. Denn freier Speicher ist nutzloser Speicher.

Cu
André

items
08.10.03, 22:06
Moinsen nochmal,
ich hab den Rechner mal neugestartet. Los gehts dann mit Window Maker und einer Auslastung von 35%. Dann mal Eclipse hochgefahren und die VM Ware Trial gestartet und da noch mal Eclipse aufgemacht :o).
Da gehts dann hoch auf 99%. Dann alle Progs wieder runterfefahren, so dass der Desktop sozusagen "wie Gott ihn erschuf" vor mir lag und der Speicherbedarf ging laut Dockapp auf 67% zurueck (wieso aber nicht auf den Startwert von 35%?) und mal ein free gemacht.

Raus kam dieses:
chickendirt:~ # free
total used free shared buffers cached
Mem: 514960 407792 107168 0 34380 273408
-/+ buffers/cache: 100004 414956
Swap: 1028120 112 1028008

Das wuerde nach der Aussage von Sonny bedeuten, dass 414965 Byte frei sind und das waere in der Tat erfreulich. Aber was fuer einen Sinn machen dann Dockapps fuer den Speicherbedarf, ausser das ihre schwankenden Balken das Erscheinungsbild meines Desktops etwas beleben.

Wenns sich so verhaelt, wie Berufspenner sagt und das eigentlich gar keine Rolle spielt, weils schon passt, frag ich mich aber trotzdem, was sich in meinem Speicher so rumtreibt, wenn kein einziges Prog gestartet ist.

Weiss das jemand? Sonst wuerde ich naemlich mal morgen meine Kollegen fragen und dann hier berichten.

Gruss und schoenen Abend
items

Berufspenner
08.10.03, 22:19
Wenns sich so verhaelt, wie Berufspenner sagt und das eigentlich gar keine Rolle spielt, weils schon passt, frag ich mich aber trotzdem, was sich in meinem Speicher so rumtreibt, wenn kein einziges Prog gestartet ist. Der Systemkernel ist ja u.a. für die Speicherzuweisung an die einzellnen Programme zuständig. Nun belegt der Kernel so viel wie möglich vom Systemspeicher und stellt jedem Programm den nötigen Speicher zur verfügung. Wenn das Programm beendet ist besetzt der Kernel diesen Speicherbereich wieder, bis ein anderes Programm ihn benötigt. So wird eine optimale Speichernutzung erreicht. Sollte dennoch mehr Speicher benötigt werden, so lager der Kernel die Daten in den Swapbereich aus. Wenn du also speicherintensive Programme laufen lässt kann es passieren, dass das System durch die Auslagerung in den langsammeren Swapbereich träger wird. Das wäre dann normal. Fängt das System aber an zu swapen, ohne das irgendwas wirklich Speicher verbraucht, stimmt meist irgend etwas nicht.

Cu
André

kth
09.10.03, 01:14
Das Stichwort ist "Buffer Cache": nicht von Programmen belegter Hauptspeicher, den der Kernel nutzt, um Schreibzugriffe auf langsame Speichermedien wie z. B. Festplatten hinauszögern zu können (Asynchronität) und um wiederholte Lesezugriffe auf bereits gelesene Blöcke schnell zu bedienen.