Von ------------------------------ am Do, 16. Juni 2011 um 23:22 #
Speicher der NICHT wirklich von dem Prozess zur Zeit belegt ist, aber theoretisch belegt werden könnte.
Na, dann bin ich mal nicht so
VIRT (der virtuelle Speicher) umfaßt Speicherbereiche, die vom Prozess adressiert werden (können).
Das hat (so direkt*) nichts mit dem physischen RAM zu tun, das Zauberwort ist hier mmap() (*Natürlich muß auch der tatsächlich durch Funktionen und Daten allozierte Speicher adressiert werden können
Die Angabe kann nahezu beliebig groß sein, ohne daß irgendwelcher RAM berührt wird (bei KDE Anwendungen dürfte da zB. der PixmapCache, die Konfigurationen & die Services mit eingehen)
Das heißt im Zweifel nur, daß der Prozess eine (große oder viele kleine) Datei(en) in seinen Speicher eingeblendet hat (nicht vergessen: unter Unix ist alles was kein Prozess ist eine Datei - sowas kommt also häufiger vor) Das bedeutet noch nicht mal, daß die Datei (je oder im Moment) "geöffnet" oder auch nur ein Byte davon in den RAM geladen wurde.
Warum das Ding per default am Anfang steht kann ich Dir so auch nicht sagen - dem Benutzer sagt es (imho) eigentlich nichts (und shift+m sortiert auch NICHT danach).
Insgesamt hat "ac" schon völlig recht: nichts in top eignet sich richtig zur Speicheranalyse - schon gar nicht zur Analyse der gesamten Speicherauslastung (weswegen das mit dem richtigen Spalte raten auch andeuten sollte: jaja... "Geleier")
RES (RSS, resident set size) ist noch am Aussagekräftigsten, aber da ist SHR schon mit drin - nur daß der Prozess der einzeige sein könnte, der von dem theoretisch "sharebaren" Speicher Gebrauch macht und daher die einfache Aussage: "RSS-SHR=Prozesslast" auch zu einfach gedacht ist.
Das Thema ist eben wirklich kompliziert und es geht immer um den Aspekt, der Dich gerade interessiert.
Und um deutlich ganz ehrlich zu sein: Ich gehe zwar davon aus, einen halbwegs brauchbaren Überblick über das Speichermanagement zu haben, aber wenn jetzt so ein ungewaschener Waldschrat um die Ecke käme und meinen würde: "Hey, das hier ist aber so nicht ganz korrekt, sondern eher so!" - ich würde nicht eine Sekunde zögern, das nachzuprüfen
VIRT (der virtuelle Speicher) umfaßt Speicherbereiche, die vom Prozess adressiert werden (können).
Das hat (so direkt*) nichts mit dem physischen RAM zu tun, das Zauberwort ist hier mmap()
(*Natürlich muß auch der tatsächlich durch Funktionen und Daten allozierte Speicher adressiert werden können
Die Angabe kann nahezu beliebig groß sein, ohne daß irgendwelcher RAM berührt wird (bei KDE Anwendungen dürfte da zB. der PixmapCache, die Konfigurationen & die Services mit eingehen)
Das heißt im Zweifel nur, daß der Prozess eine (große oder viele kleine) Datei(en) in seinen Speicher eingeblendet hat (nicht vergessen: unter Unix ist alles was kein Prozess ist eine Datei - sowas kommt also häufiger vor)
Das bedeutet noch nicht mal, daß die Datei (je oder im Moment) "geöffnet" oder auch nur ein Byte davon in den RAM geladen wurde.
Warum das Ding per default am Anfang steht kann ich Dir so auch nicht sagen - dem Benutzer sagt es (imho) eigentlich nichts (und shift+m sortiert auch NICHT danach).
Insgesamt hat "ac" schon völlig recht:
nichts in top eignet sich richtig zur Speicheranalyse - schon gar nicht zur Analyse der gesamten Speicherauslastung (weswegen das mit dem richtigen Spalte raten auch andeuten sollte: jaja... "Geleier")
RES (RSS, resident set size) ist noch am Aussagekräftigsten, aber da ist SHR schon mit drin - nur daß der Prozess der einzeige sein könnte, der von dem theoretisch "sharebaren" Speicher Gebrauch macht und daher die einfache Aussage: "RSS-SHR=Prozesslast" auch zu einfach gedacht ist.
Das Thema ist eben wirklich kompliziert und es geht immer um den Aspekt, der Dich gerade interessiert.
Und um deutlich ganz ehrlich zu sein:
Ich gehe zwar davon aus, einen halbwegs brauchbaren Überblick über das Speichermanagement zu haben, aber wenn jetzt so ein ungewaschener Waldschrat um die Ecke käme und meinen würde: "Hey, das hier ist aber so nicht ganz korrekt, sondern eher so!" - ich würde nicht eine Sekunde zögern, das nachzuprüfen