Speicherverwaltung unter Mavericks

[Kaito]

Genau kann ich dir zwar auch nicht beweisen was unter "Datei-Cache" fällt, aber ich vermute mal jede read() Anweisung eines Programms füllt diesen, bloses herunterladen von z.B. einem Netzlaufwerk genügt nicht. Es ist auch richtig, dass OSX allen verfügbaren RAM damit auffüllt und, theoretisch, hier wieder Sachen rauswirft, wenn ein Programm mal wirklich RAM benötigt.

Der letzte Part ist bewusst so formuliert, denn in früheren OSX Versionen traten hier teils gewaltige Probleme ('inaktiver RAM' war früher das, was heute 'Datei-Cache' heißt) auf, die dein OS zum swappen brachten wie blöd, wodurch alles bitterlich langsam wurde. Das wurde mit 10.9 besser.
Aber wenn ich eine Situation erzeuge, in der ich von 16GB ca. 4GB echt belegt und den Rest vollständig* durch Datei-Cache gefüllt habe, braucht er immer noch definitiv länger, wenn nun plötzlich viel Speicher von einem Programm alloc'ed werden will; in dieser Situation fängt er auch wieder an etwas zu swappen, aber weit nicht so schlimm wie früher (vlt. weil unter 10.9 erst die Komprimierung einsetzt und diese vor dem totalen Swap rettet). Perfekt ist es aber noch immer nicht.

* Der Pager von OSX kommt wohl mit durch Datei-Cache vollständig aufgebrauchtem RAM nicht klar, wenn du nämlich noch etwas freien Platz hast, scheint er weit weniger Probleme zu haben und kann schnell(er) RAM frei machen.

 

[Stefan79gn]

Dankeschonmal für die Info.
Im groben verstehe ich das System ja.
Was ich mich nur Frage ist , selbst wenn ich 32 gb Ram verbaut hätte, würde dieser sicherlich genutzt werden. Allerdings dürfte selbst bei 16gb nix swappen, es sei denn irgendwelche Programme streuben sich bei der Ramfreigabe.
Hatte bis vor kurzen noch Firefox und den vlc player in gebrauch. Dort wurde mehr geswappt als es jetzt mit Safarie und MPlayerx der Fall ist. Obs an den Programmen lag , keine Ahnung.

 

[Kaito]

(Hab meinen Post darüber etwas erweitert)

Datei-Cache untersteht nicht dem Programm, von dem er erzeugt wurde, sondern OSX selbst, entsprechend auch das Handling/Management von diesem.
Und ja, korrekt, swappen sollte nichts—vor allem nicht, wenn du aktuell nur wegen Datei-Cache zu 'wenig' RAM hast, denn dieser sollte in so einem Fall ja direkt freigegeben werden. Aber das ist nur die Theorie, in der Praxis kannst du Situationen erzeugen, in denen die Systeme nunmal nicht ganz so nach der Theorie arbeiten.

 

[Stefan79gn]

Ich werd das mal beobachten und hoffen das Apple mit einem Update die Speicherverwaltung noch ne ecke verbessert ( was nicht heißen soll das sie in irgendeiner Form schlecht ist).

 

[pmau]

Man kann sich den Speicher eine Applikation mit dem Befehl "vmmap" anschauen.

Daran sieht man:
- Dymanisch allokierten Speicher (Malloc und Co)
- Speicher der Dateien hinterlegt ist (System Libraries, geöffnete Dateien, etc),

Beispiel (das soll kein Negativ-Beispiel sein, man kann auch Safari oder iTunes nehmen):

[mau@macpro] vmmap Terminal
Virtual Memory Map of process 61020 (Terminal)
Output report format:  2.2  -- 64-bit process

...

REGION TYPE                      VIRTUAL
===========                      =======
ATS (font support)                 31.9M
ATS (font support) (reserved)         8K        reserved VM address space (unallocated)
CG backing stores                  12.8M
CG image                            108K
CG raster data                      220K
CG shared images                    212K
CoreImage                             8K
Foundation                            4K
Image IO                              4K
Kernel Alloc Once                     8K
MALLOC                            158.0M        see MALLOC ZONE table below
MALLOC (admin)                       48K
MALLOC freed, no zone              7392K
MALLOC_LARGE                       8024K
MALLOC_LARGE (reserved)             128K        reserved VM address space (unallocated)
Memory Tag 242                       12K
Memory Tag 251                        8K
OpenCL                               20K
STACK GUARD                        56.0M
Stack                              10.6M
VM_ALLOCATE                        16.4M
VM_ALLOCATE (freed)                  12K
VM_ALLOCATE (reserved)               64K        reserved VM address space (unallocated)
__DATA                             24.9M
__IMAGE                             528K
__LINKEDIT                         65.6M
__TEXT                            129.6M
__UNICODE                           544K
mapped file                        50.5M
shared memory                         4K
===========                      =======
TOTAL                             573.3M
TOTAL, minus reserved VM space    573.1M

Im übrigen liegt der hohe "Speicherverbrauch" einfach an schlecht programmierten Applikationen, die von irgendwo her portiert wurden.

Das "Problem" ist dass OSX allen Datei Cahes und "Memory Mapped" Dateien eine höhere Priorität einräumt weil es davon ausgeht dass die Applikation sagt, wann es sie nicht mehr braucht (Stichworte: mmap, madvise, mincore, etc)

Viele Applikationen und Libraries kommen von Open Source Projekten die sich nie die Mühe gemacht haben diese API auf OSX ordentlich zu benutzen.

Das führt zum Beispiel dazu, dass Media Player komplette Filme im Speicher halten, da OSX glaubt das diese Daten für das Programm enorm wichtig sind. (Sehr viele kleine Zugriffe auf Speicherbereiche).

Wer Spass daran hat, kann sich ja mal anschauen wie vielen Tonnen an Speicher so ein Programm benutzt, weil es eben den Film von einer Datei in anonymen Speicher transferiert und damit jede Optimierung von OSX unmöglich macht.

Es stimmt zwar dass OSX manchmal etwas seltsam mit Speicher umgeht, ich wollte nur mal darstellen das alles einen Grund hat.

Anmerkung:

"_TEXT"
sind gut, das sind read-only code Segmente, die einfach weggeworfen werden können.

"__DATA"
sind Datensegmente in Programm Binaries, sind gut oder schlecht je nachdem ob sie nur lesbar sind. Sonst werden
sie notfalls zu Swap (sozusagen).

"MALLOC"
muss ins Swap, wenn der Speicher knapp wird.

"mapped file"
ist prinzipiell auch gut, wenn man dem OS sagt welche Bereiche man gerade braucht.
Hier liegt mit MALLOC der Hauptteil deer Probleme

Ich wollte das nur mal hier reinstellen.

 

[tocotronaut]

Ich finde, einmal im Jahr kann man schon neu Starten...

Kommt aber auf den Rechner an. Einen Server startet man seltener neu als ein Mobiles gerät...

 

[Stefan79gn]

Danke pmau sehr aufschlußreich dein Beitrag. Also liegt es quasi an schlechtportierten apps. Das hatte ich vermutet. Dann bleibt zu hoffen das es in Zukunft besser wird.

 

[pmau]

Ich habe gerade mal VLC angeschaut. Nur mal weil mir gerade langweilig ist.
(Kann man mit "Instruments" machen wenn man Xcode installiert hat)
Spult man ein paar Filme hin und her kommt man schnell auf lustige Sachen.
Eine Minute Video macht 78MB Memory (zuwachs)
Hauptübeltäter ist ein malloc Aufruf über 32 byte
Der passiert X Mal in der Sekunde.
In der Funktion "av_mallocz" in der Library "libavcodec_plugin.dylib". Die ist Teil von VLC/ffmpeg.
Das ist erstmal nicht falsch, man muss halt mal schauen wo das herkommt.

(Was ich jetzt mal mache ...)

 

[Stefan79gn]

Also lags teilweise bei mir wirklich am vlc player

 

[Kaito]

Also lags teilweise bei mir wirklich am vlc player

Würde ich so noch nicht sagen. MplayerX (bzw. alle MPlayer derivate) nutzen ebenfalls die libavcodec zum dekodieren ihrer Frames—das heißt noch nichts. Ist halt die Frage was VLC mit dem Zeug dann anstellt, was es anfordert, aber bösartig kann es auch nicht sein, wirkliche große/echte Leaks gibts ja nicht.

 

[pmau]

Würde ich so noch nicht sagen. MplayerX (bzw. alle MPlayer derivate) nutzen ebenfalls die libavcodec zum dekodieren ihrer Frames—das heißt noch nichts. Ist halt die Frage was VLC mit dem Zeug dann anstellt, was es anfordert.

Ja, absolut. Ich habe das auch nicht behauptet. Aber es fällt halt auf, dass der Speicherverbrauch kontinuierlich wächst.

Man findet auch ne Menge valgrind backtraces im VLC Trac dazu.
Allerdings sind die meisten Reports echt alt, das gebe ich zu.

Ich kann das ja mal bauen und schauen ob ich was finde.
Bis Dienstag habe ich nichts mehr vor

 

[NeoAtti]

Hallo,
Virtueller Speicher: ist ne virtuelle Auslagerungsdatei, wird wohl aufgrund des Rams vom os angelegt. oder irre ich dort?

Nein. Virtueller Speicher ist der komplette Speicher den das OS adressiert, d.h. er ist min so gross wie der physikalische Speicher (es sei denn das OS adressiert RAM aus irgendwelchen Gründen nicht - sowas gibt es bei Mac OS X aber meines Wissens nicht).

Verwendeter swap : Daten die zeitweise auf die Festplatte ausgelagert werden, wenn nicht genügend Ram vorhanden ist. Sollte eigendlich ja 0 sein oder? Wenn doch ausgelagert wird kann es sein das ein Programm nicht schnell genug Ram freigibt. Die swap datei sollte eigendlich nicht ständig wachsen.

Das ist pauschal auch so nicht richtig. Swap kann durchaus auch verwendet werden, obwohl noch genügend RAM frei ist und das kann sogar sinn machen. Es ist völlig normal das man "verwendeten Swap" von einigen MB bis durchaus einem GB hat - zumindest wenn das System lange (> mehrere Tage) läuft. Das ist erstmal kein Problem - interessant sind die Swap IN/OUT Vorgänge (die aber nicht mehr in der Aktivitätsanzeige sieht)

Datei -Cache: hier werden Dateien in dem Ram geladen für schnellen zugriff. Soweit so gut aber was beinhaltet dies alles? Auch wenn ich dateien kopiere von laufwerk a- b ?

Was heisst "was beinhaltet dies alles?" - Ich versteh die Frage nicht. (Kinski)
Dateien, wenn sie gelesen werden landen im RAM und bleiben dort auch vorerst - solange bis das OS meint den Speicher für sinnvollere Dinge zu brauchen. Und: Ja, auch Dateien die man von a nach b kopiert landen dort.

Atti

 

[Kaito]

Ja, absolut. Ich habe das auch nicht behauptet. Aber es fällt halt auf, dass der Speicherverbrauch kontinuierlich wächst.

Dich meinte ich gar nicht, nur seinen Schluss daraus, der VLC sei "schuld". Finde deine Suche aber interessant, freue mich über Ergebnisse!
(Das Folgende ist auch an den TE, bzw. allgemein, gerichtet)

Allgemein wage ich zu bezweifeln, dass ein MPlayer sich bezüglich Speicher auf OSX auch nur ansatzweise besser anstellt, als VLC. Wenn, dann eher unabsichtlich. Ich glaube OSX ist meilenweit von den Haupt-Tagets der MPlayer Entwicklung entfernt. MPlayerX selbst ist nur ein "Wrapper" um MPlayer herum, um die Bedienung angenehmer zu machen.
VLC hat ein paar eigene Demuxer, aber abgesehen davon nutzen beide sowieso die gleichen unterliegenden Bibliotheken.

Persönlich nutze ich mpv, was (speziell auf OSX) MPlayer imo meilenweit übertrifft. Da ich von einer NAS schaue, ist der Cache ziemlich groß gewählt und der haut mir auch, über die Zeit hinweg, praktisch das ganze File in den RAM. Das ist in diesem Fall aber gewollt, denn selbst wenn die NAS aus ist, kann ich weiter zu jeder Stelle im Video springen, sofern ich sie schon gesehen hab—die Daten müssen nur irgendwo im RAM gecached sein.

 

[Stefan79gn]

Also erstmal möchte ich mich bei euch bedanken, meine Fragen wurden zu 99,9% alle beantwortet. Auch die hilfreichen Erklärungen dafür ein Daumen hoch. Werd den mpv player mal testen.
Also generell bin ich von der Speicherverwaltunf unter osX ja begeistert. Bin noch seit jahren im PCGH Forum aktiv und dort wird ja immer gesagt mehr als 8gb bringen nix ( für Windows Pcs und wenn man nicht gerade Rendert/Videobearbeitung betreibt.) Bei Apple habe ich den Eindruck mehr Ram bringt auch was. Das finde ich Super.