Wieviel RAM sollte (m)ein Macbook haben?

Kamikaze schrieb:
Äh, da möchte ich mal ein Veto einlegen. Windows Swapt einfach immer, egal wie viel ungenutzter RAM da rum liegt. Swap abschalten war schon seit Win95 eine Möglichkeit Windows auf Trab zu bringen.
Ich in nach wie vor der Meinung, dass der NT-Kernel in Sachen virtueller Speicherverwaltung in guter VMS-Tradition Dinge zum Teil deutlich besser als unixoide Systeme macht. Da ist zum Beispiel der kategorische Verzicht auf jede Form von Overcommit. Sowohl FreeBSD als auch Linux sind per Default noch immer gut mit dabei, man kann es inzwischen aber zumindest deutlich einschränken. Auf der anderen Seite nutzt NT auch in der aktuellen Inkarnation 10.0 (aka Windows 10.0 Technical Preview) überholte Strategien. So versucht es zwanghaft möglichst viel RAM freizuhalten, indem es sehr aggressiv swapt. Das ist genau das von dir beschriebene Verhalten. Außerdem werden viel zu wenig Ressourcen für die Dateisystemcaches genutzt, was Windows im Vergleich zu unixoiden Systemen in Sachen IO gefühlt und tendenziell auch objektiv deutlich langsamer macht.

EDIT: FreeBSD hat Overcommit als Standardeinstellung noch immer eingeschaltet.
 
Yamagi: Laut sysctl -n vm.overcommit verwendet FreeBSD 10.1 amd64 kein overcommit und soweit mir bekannt ist das (schon lange) der default Wert.
 
,Ja, ich meine auch, dass Overcommit ab FreeBSD 8.0 stark eingeschränkt wurde. Wir leben schließlich nicht mehr im Jahr 1985, wo jedes Bit RAM wertvoll war. Nur tuning(7) sagt dazu:
Code:
Setting bit 0 of the vm.overcommit sysctl causes the virtual memory sys-
tem to return failure to the process when allocation of memory causes
vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl enforces
RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this limit.
Bit 2 allows to count most of the physical memory as allocatable, except
wired and free reserved pages (accounted by vm.stats.vm.v_free_target and
vm.stats.vm.v_wire_count sysctls, respectively).
Das der Standardwert "0" ist und damit kein Bit gesetzt schloss ich, dass er volles Overcommit machen müsste. Wenn ich den Code in vm/swap_pager.c:187 nun zwischen Tür und Angel richtig lese, beschränkt das Sysctl lediglich, ob mehr Speicher zugewiesen werden darf, als (in oberster Abstufung per Bit 0) das System an RAM + Swap besitzt. Darüber, wie aggressiv Overcommit angewandt wird, trifft es erst einmal gar keine Aussage. Das deckt sich auch mit der "Doku" dazu: http://people.freebsd.org/~kib/overcommit/

kib@ schrieb:
setting of the bit 0 to 1 denies allocation request if, after request, total reserved swap space will exceed size of configured swap.

Man müsste vm.overcommit also auf binär 001 -> dezimal 1 setzen, damit er nicht mehr Speicher zuweisen kann als durch die Swap abgedeckt wird.
 
Wenn ich das jetzt richtig verstehe : "Overcommit" regelt quasi die Grenze ab wann von RAM in Swap gespeichert wird?
 
Nein, nicht wirklich. Die Idee hinter Overcommit ist, dass man nicht in Zukunft schauen kann und daher aus der Gegenwart den RAM-Verbrauch in der Zukunft nur schlecht interpolieren kann. Außerdem sind die meisten Programmierer recht großzügig, was RAM-Zuweisungen betrifft. Man fordert mehr an, als man tatsächlich braucht. Overcommit versucht beides auszunutzen, indem es mehr RAM zuweist, als physisch vorhanden ist. Am besten schaut man sich ein Beispiel an: Der Computer hat 8G RAM und außerdem 8G Swap. Maximal können also 16G Speicher zugewiesen werden, denn mehr ist nicht vorhanden. Wenn nun z.B. 15G belegt sind und ein Programm fordert 2G an, schlägt die Anforderung ohne Overcommit fehl, da nicht genügend Speicher vorhanden ist. Mit Overcommit gibt das System der Anforderung aber statt und spekuliert darauf, dass das Programm diese 2G nicht ausnutzen wird. Und wenn es das würde, hoffentlich an anderer Stelle schon wieder Speicher frei geworden ist, den man neu zuweisen kann.

Der große Vorteil von Overcommit ist, dass man eine deutlich bessere Speicherausnutzung erreichen kann. Das war vor allem früher wichtig, als RAM teuer und immer knapp war, wodurch die Systeme eh durchgehend tief in der Swap hingen. Der Nachteil ist, dass die Wette auch schief gehen kann. Wenn angeblich zugewiesener Speicher dann doch nicht vorhanden ist, kommt der berüchtigte "Out of Memory"-Killer ins Spiel, der beginnt Prozesse wegzuschießen und so die Lücke zwischen Theorie und Realität schließt.

Traditionell machen die meisten Unix-Abkömmlinge Overcommit, die Frage ist nur wie aggressiv. FreeBSD nutzt es unabhängig von dem sysctl 'vm.overcommit' nur noch wenig, anscheinend umso weniger je mehr RAM vorhanden ist. Linux hingegen geht in Standardeinstellung noch immer die Vollen, eine Speicherzuweisung schlägt dort nur in sehr extremen Situationen fehl. Egal wie viel RAM bereits belegt ist. Windows als geistiger Nachfolger oder (je nach Sichtweise) Klon von VMS nutzt gar kein Overcommit. Jede Speicherzuweisung ist immer durch RAM oder Swap abgedeckt. Wenn man die Swap auf dynamische Größe einstellt, wird Windows die Swap bei jeder weiteren Zuweisung solange vergrößern, wie Speicherplatz vorhanden ist. Erst wenn er keinen Swap-Speicher mehr reserviert bekommt, schlagen Zuweisungen fehl. Das ist eigentlich eine sehr elegante Lösung.
 
@ Yamagi : Vielen Dank für diese sehr ausführliche Erklärung. War bestens verständlich & sehr hilfreich :)
 
Zurück
Oben