Hallo, erst mal vielen Dank für die ausführliche Erläuterung. Mit war ehrlich gesagt nicht bewusst, was da alles im Hintergrund passiert. Bisher war ich so naiv zu glauben, dass ich nach einem malloc wirklich speicher in Händen hätte, und nicht erst nach einem page fault...
Theoretisch ich schalte auf der Maschine den swap komplett ab, wie zuverlässig ist dann die Aussage von RSS? Selbst verständlich ist der von mir verwendete Speicher darin immer noch auf page size Granularität, aber das ist o.k., denn wenn ich Dich richtig verstehe, kann den restlichen Speicher eh kein anderer Prozess erhalten. Also sollte mir das doch weiter helfen, oder? tschau Sascha Am Donnerstag, den 22.04.2010, 23:07 +0200 schrieb Jan 'RedBully' Seiffert: > Sascha Effert schrieb: > > Am Mittwoch, den 21.04.2010, 17:01 +0200 schrieb Florian Lohoff: > [snip] > >> Die RSS ist ja nur ein real life parameter der den best case darstellt. > >> wenn dein system memory pressure hat wird das ja weniger. Besser ist es > >> die VSZ sich anzuschauen - das ist ja eher die worst case betrachtung. > >> > >> Ansonsten mal valgrind ansehen - ich meine der spuckt auch stats aus, > >> die beinhalten aber IIRC nur malloc d.h. nicht dein text segment deiner > >> libs. > >> > >> Flo > > > > O.K., danke für die vielen Antworten. Mir war nicht bewusst, dass das so > > ein Problem ist. In Java ist das irgendwie einfacher... :-) > > > > Ich werde weiter per ps den Prozess scannen, bessere Werte scheine ich > > auch aus dem Prozess selbst heraus nicht zu erhalten ohne erheblichen > > Aufwand in das mitzählen bei jedem new/malloc und der Berechnung des > > Verbrauchs auf dem Stack zu benötigen. > > > > Als Parameter werde ich VSZ verwenden. Ich hatte tatsächlich vorher > > nicht realisiert, dass RSS nicht den geswapten Speicher mit > > einberechnet. Sehe ich es richtig, dass auf einem Rechner ohne Swap > > immer RSS=VSZ gilt? Ich bin ein wenig verwundert, denn auf meinem gerade > > gestarteten Notebook erhalte ich für Evolution RSS 50664 (ca. 50 MB) und > > VSZ 198364 (ca. 200 MB). top sagt mir aber, dass ich momentan keinen > > SWAP (0 k) verwende. Kann mir das jemand erklären? > > > > Der Grund, warum ich eigentlich auch erst Florians Hinweis auf die VSZ so > nicht > stehen lassen wollte, ist dass die VSZ IMHO nicht sooo viel aussagt. > Ja, sie ist ein Worst-Case-Mass. > Aber ein seeehr grobes. > > Die VSZ ist nur die "groesse" des virtuellen Adressraums, dieser muss nicht > mit > irgendwas unterfuettert (a.k.a. echtem Speicher, RSS & SHR) sein. > Es gibt da zwar eine enge Korrelation, aber es gibt genug Situationen in denen > einfach ein riesen Adressraum da ist, aber nichts dahinter. > mmap eine grosse Datei im Stueck und fass nur ein bischen davon an oder schieb > mit sbrk deinen Heap um 5MB hoch (z.B. default inkrement um nicht so oft sbrk > aufzurufen), bumm, deine VSZ ist sofort einen ganzen Sack groesser. > > Klassische Beispiele sind Virtuelle Maschinen/Interpreter, die erstmal ein > grossen "Spielplatz" anlegen, oder Emulatoren, oder Wine (versucht den > Adressraum aussehen zu lassen wie unter Windows, da hat man schnell VSZ=2G, > bei > RSS=30M). > > Aber auch duenn besiedelte grosse Strukturen oder einfach Fragmentation > koennen > dazu fuehren (Du kannst die VSZ "hinten" nicht verkleinern weil da noch ein > Objekt lebt, aber du kannst die Speicherseiten dazwischen schon mal mit > madvise(WONT_NEED) zurueckgeben). > > Bei Evolution, ich wuerd sagen der uebliche C++ bloat mit gaaanz viel > Allokationen (man hat ja endlich richtige Strings, in Containern...). > > Schau dir z.B. mal den neuen Firefox mit jemalloc in htop an. Auch der belegt > riesige mengen VSZ (hier grad 380M), aber (wegen jemalloc) um die > Fragmentation > zu senken (dynamische Skriptsprache integriert, viel Grafik gedoense, GUI ist > in > Javascript, viel Textverabeitung, Berge von Libs, Plugins), so das die RSS > schoen rauf und runter gehen kann, je nachdem wieviel Speicher grad _wirklich_ > gebraucht wird. > > Mit anderen worten: > VSZ ist der max. moegliche Speicherverbrauch (aka Adressraumgroese) > RSS ist der tatsaechliche eigene Speicherverbrauch > SHR ist der teilbare Speicherverbrauch, er muss aber nicht geteilt sein > > Wenn was rausgeswapt wird, werden AFAIK RSS und SHR kleiner. > Leider ist SWP AFAIK nicht einzeln fuer einen Prozess verfuegbar. > > Das Speichermanagement ist eben kompliziert (im Kernel und in guten > Allokatoren) > um aus dem Speicher in einer Maschine das "maximum" (klar, koennte immer alles > noch viel besser sein) rauszuholen. > (minus Hardware beschraenkungen, wenn deine kleinste Speicherseitengroesse 64k > ist (PowerPC?), dann kannst du nur in 64k Schritten das ganze verwalten. > Kleine > Seiten haben aber mehr overhead, siehe hugepages fuer z.B. Datenbanken und so > feaky high perfomance teuer business stuff, der mal kurz seine eigene > Speicherverwaltung mitbringt, um genau den overhead zu senken da man eh weiss > das man vieeel Speicher braucht) > > Der Kernel kennt mehrere Arten und zustaende von Speicher, eingeteilt in > mappings (siehe /proc/pid/smaps) denen er "echte" Speicherseiten zuordnet > (oder > entfernt). Mal ein paar Begriffe: > - Anon und File > File ist eine Datei in den Speicher ge-mmap-t. Da die CPU die Festplatte nicht > direkt adressieren kann, muss das mit Hilfe von "echtem" RAM passieren (Datei > in > RAM laden, Prozess(or) zur verfuegung stellen). > Anon ist Speicher, der keine Datei dahinter hat, ausser swap. > - shared und private > shared Speicher bedeuted, das die gleiche Speicherseite in mehreren Prozessen > "vorhanden" ist (oder sein kann), und falls drauf geschrieben wird, das auch > in > allen Prozessen sichtbar ist. > private bedeutet das aenderungen nur in diesem Prozess sichtbar sind. > - clean und dirty > Speicherseiten die "clean" sind, sind Seiten die so 1:1 dem backing store > entsprechen, sie sind quasi nur gecached, damit die CPU die Daten ansprechen > kann. Wenn Speicher gebraucht wird, koennen diese Seiten einfach verworfen > werden, man kann sie ja so wieder von irgendwoher laden. > Speicherseiten die dirty sind, sind Seiten die so nicht mehr dem backing store > entsprechen, die muessen gesichert werden, bevor sie fuer irgendwas anderes > benutzt werden koennen. > - R W X > ist das mapping Les-, Schreib-, Ausfuerbar > > > So, damit laesst sich jetzt ein bisschen was beschreiben: > Z.B. dein Heap (im Sinne von sbrk). > Er ist ein linearer Bereich (mapping) aus privatem Anon Speicher. > Solange du den Speicher nicht beschreibst, ist er clean. Solange sind > (zumindest > wenn overcommit an ist) auch keine echten Speicherseiten daran gebunden. > Du kannst problemlos ein malloc(100*1024*1024) machen, dein VSZ wird um 100MB > steigen, aber deine RSS erstmal nicht (wir vergessen jetzt mal grade > prefaulting). > Beim lesen "siehst" du immer die gleiche Speicherseite (eine Zero Page). > Erst beim schreiben (pagefault) bekommst du eine "eigene" Speicherseite, sie > ist > danach dirty (dein RSS steigt). Wenn der Kernel diese Seite fuer was anderes > braucht, muss er sie erst clean bekommen, da es kein File backing gibt, kann > sie > nur in den Swap wandern. > > Da das ganze ein linearer Bereich ist, der nur laenger (hinten mehr Raum fuer > mehr moegliche Speicherseiten) oder kuerzer (Speicherseiten hinten wieder > freigeben) werden kann, hast du das Problem dass Fragmentation dazu fuert, das > du den heap nicht verkuerzen kannst, also Speicherseiten "in der Mitte" nicht > an > den Kernel zurueck gegeben werden koennen. > Frueher hat sich das durch swappen geloest, der Kernel hat dann Seiten in den > swap geschrieben, die der Prozess so selber nicht mehr braucht (sie waren > "kalt", der Prozess hat sie lange nicht benutzt, beste swap "opfer"), > unnoetig, > aber egal, es lief. > Heutzutage kann ein guter Allocator da mit madvise(WONT_NEED) Loecher in den > heap stanzen. (Problem ist, dass das nur auf Seitengranularitaet funzt, wenn > der > Heap also schlimm fragmentiert ist hast du auf jeder Speicherseite noch > irgendein nn Byte Objekt, Allokatoren versuchen das mit schlauen Algorithmen > zu > vermeiden). > > Man kann aber Anon Speicher auch ueber mmap bekommen. Der Vorteil ist: So > bekommt man ""kleine", _einzelne_ Stuecke Speicher (mappings), die man einzeln > eben auch wieder freigeben kann. > Der Nachteil ist, dass das einen grossen overhead hat. > > Darum benutzen Allokatoren oft eine Mischung aus sbrk und mmap (z.B. kleine > Objekte auf klassischem Heap, Objekte > x per mmap). Oder sie benutzen mmap > exklusiv um viele mittelgrosse Stueckchen zu bekommen, in denen sie dann > lauter > kleine heaps "aufmachen", ist so ein heap wieder leer, kann er problemlos > einzeln wieder freigegeben werden. Oder Oder Oder. > > Jetzt kann man dank mmap auch mit Dateien rumspielen. > Wenn du eine Datei mmap'st, dann steigt dein VSZ auch erstmal um die > Dateigroesse (bzw. mapping laenge). Denoch belegt das so erstmal keinen > Speicher > (ok,ok, minus Kernel overhead etc.). > Du kannst dir aussuchen ob das mapping shared oder private ist, ob es les-, > schreib- und/oder ausfuerbar ist. > > Ist es shared, bedeuted das, dass aenderungen (du schreibst in den gemapten > Speicher) auch wirklich in die Datei zurueck geschrieben werden. Dieses > mapping > hat quasi sein eigenes swapfile. Jeder Prozess der die Datei shared mapped, > hat > die gleichen Speicherseiten und sieht die aenderungen der anderen Prozesse. > > Ist es private, bedeuted das, das aenderungen _nicht_ in die Datei zurueck > geschrieben werden. Denoch kannst du (so das mapping nicht read only ist) da > reinschreiben. > Was passiert denn da? Die zu der Datei gehoerenden Seiten sind erstmal > ge-shared > und read only. Wenn du in eine Seite reinschreibst, erzeugt das einen > pagefault > (da Seite RO), der Kernel sieht dann das du da doch reinschreiben darfst, > sucht > eine freie Seite, kopiert den orig. Inhalt da rein, und gibt dir diese Seite > dann als RW (COW, Copy on write), du kannst deinen Schreibvorgang beenden. > Jetzt > ist in dem ganzen mapping (vielleicht mehrere MB, SHR), eine Seite Anon, dirty > (RSS). > > Executables und Libs werden heute auch so behandelt: > Wenn du z.B. eine .so benutzt, so wird sie vom loader (meist /lib/ld.so) per > mmap in den Speicher geholt. Das ist File backed. Zum Ausfuehren muss das > natuerlich erst in echtes RAM geladen werden. Denoch, falls die Seiten knapp > werden, kann der Kernel problemlos diese Seiten weg werfen, da sie File backed > und meist clean sind (und mit ein Grund warum bei Speicherknappheit X so derbe > ruckelt. Der X Binaercode wird aus dem Speicher geschmissen... ). > Das ganze mapping der Lib ist zwar als privat markiert, aber solange keiner in > den Binaercode reinschreibt, teilen sich alle Prozesse die diese Lib benutzen > die gleichen Speicherseiten. > In den Binaercode wird auch normalerweise nicht geschrieben (Read Only > gemappt), > denoch kann es konstruktionen geben wo das noetig ist (Text relocationen), in > dem Fall wird das shared mapping gebrochen, der Prozess bekommt seine eigene > Seite, in der nur er seine Aenderung sieht (COW). > Danach ist diese Seite dirty. Das ist schlecht. > Um das zu verhindern wird eine Executable/Lib in mehrere Sektionen unterteilt, > um Stellen die sich einfach mappen lassen (.text, .rodata) in eigenen mappings > von denen zu trennen, in die reingeschrieben werden muss (.got, .plt). > > Wie du siehst, Speicherseiten gehen hin, her, das geht rubbel-die-Katz. Mal > wird > mehr geladen weil Speicher uebrig ist (readahead), mal werden dir hinten rum > Seiten gemopst. Und das ist nur der Kernel, was die runtime libs so machen, > ist > eben noch mal ein ganz eigener Film. Ganz oben sitzt dann dein Programm und > tut > irgendwas (was das positiv oder negativ beeinflusst). > Deshalb ist es so kompliziert zu sagen, was da jetzt wie _warum_ wieviel > Speicher braucht. > > So, ich hab jetzt keine Lust mehr das 20 mal Korrektur zu lesen. > > Wenn die VSZ gross ist, dann gilt es erstmal rauszufinden warum sie so gross > ist. Dann kann man abwaegen ob das ein Problem ist, oder nicht. > > Die besten Chancen hast du da noch mit valgrind (oder zumindest mem_usage um > das > etwas besser aufgeschluesselt zu bekommen als VSZ, RSS, SHR). > > > tschau > > > > Sascha > > > Gruss > Jan > > -- > <zindhietche> In England wurde ein Lehrer festgenommen. Bei ihm wurden ein > Bleistift, ein Lineal und ein Geodreieck gefunden. Angeblich war er Teil > des Al-Gebra Netzwerks und besaß "weapons of math instruction" > -- > Linux mailing list Linux@lug-owl.de > subscribe/unsubscribe: http://lug-owl.de/mailman/listinfo/linux > Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo -- Linux mailing list Linux@lug-owl.de subscribe/unsubscribe: http://lug-owl.de/mailman/listinfo/linux Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo
