Am Friday 25 March 2011 schrieb Alexander Skwar: > Hallo. > > Ja, die Frage mag "etwas" peinlich sein, aber… Spannend, genau diese Frage möchte ich für den Linux Performance Analyse & Tuning-Kurs, den ich halte, auch noch etwas genauer als bislang eruieren. > Also, wenn man sich top anschaut, so sieht man 4 Angaben zum benutzen > Speicher. Von meinem System hier http://nopaste.me/paste/4d8c56884646f > : > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ PPID SWAP > COMMAND 8365 askwar 20 0 1387m 7556 5604 S 0 0.4 0:03.02 > 8299 1.3g nm-applet > 8621 askwar 20 0 705m 315m 36m S 5 15.7 1:08.67 21965 389m > firefox > > Da gäbe es also VIRT, RES, SHR und SWAP Am nächsten kommt RES, wenn es um den physikalisch belegten Speicher geht. Denn: Der Kernel hat eine virtuelle Speicherverwaltung. Er gibt also an die meisten Prozesse virtuellen Speicher, genauer Adreßraum raus. Das sind im Grunde Phantasie-Adressen, die der Kernel mit der MMU nach Bedarf auf physikalische Adressen abbildet. Das macht der Kernel aber nur für virtuellen Adreßraum, den der Prozess auch benutzt. Dabei verhält sich der Kernel standardmäßig wie ein Hochstapler. Wie eine Bank, die 1000 Euro hat, aber 4 Kunden eine Bürgschaft von je 500 Euro gibt und hofft, dass sie die nie vollständig anfordern. Wenn die Prozesse das dann doch machen und kein physikalischer - Hauptspeicher + Swap - Speicher mehr da ist, dann ruft der Kernel den Out of Memory Killer auf den Plan, der hoffentlich (!) den richtigen Prozess beendet. Programme benutzen jedoch in der Regel nicht allen Adreßraum, den sie anfordern vollständig aus. Ein guter Vergleich ist zwischen Konqueror und Iceweasel. Iceweasel nimmt sich auf den ersten Blick wie ein Speichermonster aus, da es wesentlich mehr virtuellen Adreßraum anfordert, als er dann auch verwendet. Da dürfte RES wesentlich aussagekräftiger sein. Allerdings enthalten sowohl VIRT als auch in RES noch die Anteile von potentiell gemeinsam genutzten virtuellen oder physischen Speicher. RES wäre also recht exakt, wenn der Prozess der einzige wäre, der läuft. Ein pmap -d zeigt am Ende unter "writable/private", wieviel ein Prozess für sich privat beansprucht. Doch unterscheidet pmap nicht zwischen RES und VIRT. Und daher ist da "writable/private" auch mehr, als der Prozess physikalisch verbraucht. Ein Weg ist es, den gemeinsamen verwendeten *physikalischen* Speicher, durch die Anzahl der Prozesse zu teilen, die ihn nutzen. So wie es der ksysguard auf KDE 4.5 (weiß nicht, ob das schon in KDE 4.4 drin war) macht, wenn man bei einem Prozess das Kontextmenü öffnet und "Detailliere Speicherinformationen" auswählt. Dennoch gibt es einen deutlichen Unterschied: Für Iceweasel 4: The process firefox-bin (with pid 14996) is using approximately 95.1 MB of memory. It is using 93.2 MB privately, and a further 9.7 MB that is, or could be, shared with other programs. Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 1982.0 KB. Adding that to the private usage, we get the above mentioned total memory footprint of 95.1 MB. Für Konqueror: The process konqueror (with pid 9619) is using approximately 9.1 MB of memory. It is using 7.2 MB privately, and a further 21.9 MB that is, or could be, shared with other programs. Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 1919.0 KB. Adding that to the private usage, we get the above mentioned total memory footprint of 9.1 MB. Und da bin ich nicht sicher, obs da nicht nochwas zu beachten ist. Ob RES wirklich von tatsächlich *belegtem* physischen Speicher ausgeht. Oder ob es auch physikalisch gemappten Speicher gibt, der "clean", also ungenutzt ist. Die Informationen zieht sich der ksysguard zumindest teilweise aus der Datei /proc/<PID>/smaps. Und da gibts noch die Unterscheidung dirty und clean, über die ich mir noch mehr Klarheit beschaffen möchte als bislang. Zu den Smaps gibts auch eine Perl-Bibliothek nebst Beispielprogramm. Eine gute Annäherung ist ein free -m vor und nach dem Starten des Prozesses. Und da wird schon deutlich, dass virtuellen Werte für Iceweasel nicht einmal ansatzweise stimmen. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.