Swapfile bei 16GB Ram

Oli am Mac

Oli am Mac

Aktives Mitglied
Thread Starter
Dabei seit
26.12.2005
Beiträge
995
Reaktionspunkte
166
Hallo,

mein MBP legt immer mal wieder swapfiles an.
Interessehalber: müssten 16GB Ram nicht ausreichen ohne dass diese Files angelegt werden?
Oder habe ich einen Denkfehler?

Fahre mit den Originaleinstellungen ohne jedwedes Tuning.

VD Oli
 
Das machen meine Geräte schon immer, und mit den neuen Betriebsystemen besonders, obwohl der Speicher nicht ansatzweise voll ist oder war in letzter zeit voll war.

Screenshot 2016-12-19 09.07.09.png
 
macOS ist in Sachen Speicherverwaltung völlig kaputt. Es ist nicht einzusehen, dass das OS Swapped wenn es nebenbei RAM für "Caching" übrig hat.
Mit Sierra ist es besser geworden aber das Verhalten bleibt kaputt
 
Ich zitier mich mal selbst:
Eine "Swappiness" (so heißt der Parameter unter Linux) von 0, d.h. ein Auslagern nur dann wenn der RAM wirklich voll ist (so wie du es dir vorstellst) ist NICHT zwangsläufig der beste Weg (aus diesem Grund ist das unter Linux auch frei einstellbar - und keine mir bekannte Distribution nutzt das von dir favorisierte Setting).

Der Grund dafür ist ganz einfach, dass der Arbeitsspeicher nicht nur für aktive Programme genutzt wird, sondern z.B. auch als Disk Cache, und das nicht zu knapp. Wenn das System Daten im RAM findet, die nicht freigegeben werden können aber auch nicht genutzt werden (z.B. Memory Leaks in lange laufenden Programmen) können die auch ohne jemals irgendwem zu schaden ausgelagert werden. Dafür werden z.B. häufig wiederkehrende Lesezugriffe weggepuffert (den selbst Apples Super-SSDs sind ein Scherz gegen die Datenrate von RAM).

Auf diese Weise versucht Apple offensichtlich die Ausnutzung des RAMs mit sinnvollen Aufgaben (toten Speicher zu halten oder brach zu liegen ist nicht sinnvoll) zu optimieren.
Wie bei Apple typisch ist das Verhalten (meines Wissens nach) nicht konfigurierbar (abgesehen von z.B. einer Abschaltung des Swaps - ganz blöde Idee) und muss dementsprechend nicht für jedes System optimal sein. Meiner Erfahrung nach funktioniert das System in der Praxis aber doch sehr gut.

tl;dr: Das Verhalten ist gewollt, jedes aktuelle System macht das so.
 
Was soll macOS denn machen? Wenn ich ein großes Anonymous Mapping erzeuge, muss Platz dafür da sein.
Sobald beim Taskswitching die Page Table gewechselt werden muss zumindest das File Mapping da sein.
Gerade wenn man noch 32bit Binaries irgendwo hat.

Java Downloader oder Bittorrent Clients die einfach mal ein paar GB virtuellen Speicher mappen reichen da.

Wer Interesse hat kann sich mal die Ausgabe von "vmmap" im Terminal anschauen.
 
Ok, vielen Dank für die Erklärungen.

Dann wird alles so weiterlaufen ohne darüber nachzudenken.
 
Was soll macOS denn machen? Wenn ich ein großes Anonymous Mapping erzeuge, muss Platz dafür da sein.
Sobald beim Taskswitching die Page Table gewechselt werden muss zumindest das File Mapping da sein.
Gerade wenn man noch 32bit Binaries irgendwo hat.

Java Downloader oder Bittorrent Clients die einfach mal ein paar GB virtuellen Speicher mappen reichen da.

Wer Interesse hat kann sich mal die Ausgabe von "vmmap" im Terminal anschauen.

Wozu erzählst du das? Die Pagetables sind doch in der Regel, sofern kein memory leak vorliegt nicht das Problem.

Code:
1001:~> uptime
11:39  up 55 days  1:33,  9 users,  load average: 2,77, 2,39, 2,45
1001:~> free -m
  total  used  free  shared  buffers  cached
Mem:  516475  429034  87440  4122  188  425364
-/+ buffers/cache:  3481  512993
Swap:  16383  1  16382
1001:~> cat /proc/meminfo
MemTotal:  528870404 kB
MemFree:  89538988 kB
MemAvailable:  521847908 kB
Buffers:  193068 kB
Cached:  431225212 kB
SwapCached:  284 kB
Active:  172002752 kB
Inactive:  260899792 kB
Active(anon):  199488 kB
Inactive(anon):  4404032 kB
Active(file):  171803264 kB
Inactive(file): 256495760 kB
Unevictable:  80 kB
Mlocked:  80 kB
SwapTotal:  16777212 kB
SwapFree:  16775700 kB
Dirty:  92 kB
Writeback:  0 kB
AnonPages:  382196 kB
Mapped:  62148 kB
Shmem:  4221360 kB
Slab:  4467248 kB
SReclaimable:  4347780 kB
SUnreclaim:  119468 kB
KernelStack:  4328 kB
PageTables:  13640 kB
NFS_Unstable:  0 kB
Bounce:  0 kB
WritebackTmp:  0 kB
CommitLimit:  281212412 kB
Committed_AS:  4683684 kB
VmallocTotal:  34359738367 kB
VmallocUsed:  0 kB
VmallocChunk:  0 kB
HardwareCorrupted:  4 kB
AnonHugePages:  233472 kB
HugePages_Total:  0
HugePages_Free:  0
HugePages_Rsvd:  0
HugePages_Surp:  0
Hugepagesize:  2048 kB
DirectMap4k:  197340 kB
DirectMap2M:  4468736 kB
DirectMap1G:  533725184 kB
1001:~>

Ich hab hier auf einer Clusternode mit 512GB RAM und 3TB virtuellen Speicher 13MB Pagetable. Ich glaube das kann man getrost vernachlaessigen. Auch auf meinem Desktop sinds <100MB.
 
Wozu erzählst du das? Die Pagetables sind doch in der Regel, sofern kein memory leak vorliegt nicht das Problem.
Hmm. Nein. Das habe ich auch nicht gemeint.
macOS basiert auf BSD. Wenn man da ein PageTable Mapping erzeugt muss es dafür eine Paging Möglichkeit geben.
Bei Dateien, Frameworks und anderen Binaries ist das ja die SSD.
Bei Anonymen Mappings ist das aber das Swapfile.

Also muss das Swapfile so groß sein, wie die in den PageTable Einträgen anonymen Regionen.
Jetzt wirst Du sagen "Nee, stimmt doch gar nicht!!"

Richtig, die Geschichte ist komplizierter.
Natürlich können sich mehrere Prozesse mit den PageTable Einträgen nicht in die Quere kommen weil sie gar nicht so viel Speicher belegen (mappings haben, nicht unbedingt belegen).
Bei diesen Context Switches werden die PageTable Einträge eben nicht weggeworfen und müssen deshalb auch nicht Swap Möglichkeiten haben.

Nur wenn man mehrere Prozesse hat, die große anonyme Regionen gemaped haben, braucht man dafür auch das Equivalent an Swap.
Übrigens unabhängig davon ob tatsächlich ausgelagert wird oder nicht.

Kurz:
- Es geht nur um anonyme mappings
- Es geht nur um große Regionen die beim Context Switch vielleicht weggeworfen werden müssen (die Mappings)
- Das passiert nur wenn ein als "Dirty" getaggtes mapping auch tatsächlich angefasst wird (im pagetable)
 
Ja das Swap-Konzept kommt halt noch aus dem UNIX-Pleistozän. Noch in den 1980ern hieß es mindestens eine Swap-Partition und die etwa 2x so groß wie das RAM. Nunja das hieße heute Partitionen von gut und gern 16-64GB und ist in der Tat humbug. Windows und auch MacOS haben sich daher von den regelrechten Swap-Partitionen verabschiedet. Spätestens mit SSDs machen die auch immer weniger Sinn. Mit Ubuntu wird nun auch das erste LINUX-System sich von der standardmäßig installierten Swap-Partition verabschieden und auf maximal 2GB Swap-File setzen.

Konzepte zum allocieren und deallocieren von Speicher gibt es mehr als genug und jedes OS kocht da eine immer etwas andere Suppe. Die Zeiten der Swap-Partitionen sind jedoch vorbei und über Swaü-Files würde ich mir keine Gedanken machen, wenn es für die eng wird auf dem Datenträger, dann hat man ganz andere Probleme.
 
Zurück
Oben Unten