>> Mein Gott. > Ich bestehe schon lange nicht mehr auf diese Anrede.
Ähm, sorry, du warst doch garnicht gemeint
Aber danke für deine Ausführungen.
> Du tust gerade so als hätte ich das behauptet. Ja, hörte und hört sich immer noch schwer so an. Kann ein absolutes Mißverständnis (gewesen) sein, in dem Fall: sorry. k.A. wie deine Agenda in Sachen Systemanalyse so aussieht.
Schwamm drüber
> Ich frag mich echt warum hier einige immer so vehement > bestreiten, dass KDE zuviel Speicher braucht Habe ich nicht, würde ich nicht. Aber ich würde die Aussage undifferenziert und damit unbrauchbar nennen. Das ist nicht unbedingt Deine Schuld, die KDE Macher sind sich schon länger selbst nicht mehr über ihre Marketingstrategie im klaren (KDE, KDE SC, KDE frameworks, ...)
OK, ack.
Es wäre in diesem Zsgh. sinnvoll, Bestandteile mit hohem RSS oder meinetwegen mit ausufernden Abhängigkeiten (derzeit imo noch das größte Problem des KDE ) zu benennen, oder "KDE" in diesem Kontext zumindest zu definieren (mit/ohne nepomuk, akonadi, welche plasmoids, etc., kram) Alles andere ist vielleicht gerechtfertigter rant, aber weder nützlich noch informativ. Sorry nochmal.
So genau hab ich mir KDE wirklich nicht angesehen. Aber es ist ja auffällig, dass eben bei anderen DEs eine schwache Maschine nicht so schnell anfängt zu swappen. Es war also eher eine Beobachtung als eine fundierte Analyse von KDE's Innerem.
> Wenn man sich die Ausgabe von "free" ansieht [...] > Die anderen Werte ignoriere ich jetzt mal.
Möglicherweise ist dir aufgefallen, daß die Summe der Spalten 1-5 (iA.) nicht dem Wert der Spalte 0 (total) entspricht?
Vielleicht wirfst Du Oberschlaumeier doch noch einen Blick in die zweite Zeile? Was denkst Du wohl was "-/+ buffers/cache:" bedeutet?
Ähm, ja. Zugegeben, das hatte ich jetzt wirklich ignoriert. Mea culpa.
"cached" macht einen Teil von "cache" aus und ist NICHT komplementär zum Wert der ersten Zeile der "Free" Spalte und warum verf**** nochmal halte ich hier eigentlich Vorlesungen?
Weiss ich nicht, aber danke
Ich will gar nicht wissen, was Du Dir so unter VIRT vorstellst oder wo Du meinst den per shared object geerbten Speicherverbrauch von Anwendungen zu lesen)
Naja ganz ehrlich ohne jetzt irgendwo nachzulesen (das kann ja jeder ;-)): Speicher der NICHT wirklich von dem Prozess zur Zeit belegt ist, aber theoretisch belegt werden könnte. Ist mit sicherheit so nicht ganz richtig, aber der erste - entscheidende Teil denke ich schon.
Da, lies hier - ich hab's erst mal satt, sorry zum dritten. http://linux-mm.org/LinuxMMInternals
Danke für den Link.
Sorry zum vierten für den leicht genervt klingenden Ton, ist nicht bös' gemeint.
Macht nix. Ich reagier manchmal auch so. Danke dir nochmal.
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
>> Mein Gott.
> Ich bestehe schon lange nicht mehr auf diese Anrede.
Ähm, sorry, du warst doch garnicht gemeint
Aber danke für deine Ausführungen.
Schwamm drüber
OK, ack.
So genau hab ich mir KDE wirklich nicht angesehen. Aber es ist ja auffällig, dass eben bei anderen DEs eine schwache Maschine nicht so schnell anfängt zu swappen. Es war also eher eine Beobachtung als eine fundierte Analyse von KDE's Innerem.
Ähm, ja. Zugegeben, das hatte ich jetzt wirklich ignoriert. Mea culpa.
Weiss ich nicht, aber danke
Naja ganz ehrlich ohne jetzt irgendwo nachzulesen (das kann ja jeder ;-)): Speicher der NICHT wirklich von dem Prozess zur Zeit belegt ist, aber theoretisch belegt werden könnte. Ist mit sicherheit so nicht ganz richtig, aber der erste - entscheidende Teil denke ich schon.
Danke für den Link.
Macht nix. Ich reagier manchmal auch so. Danke dir nochmal.
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