Frischer 16GB RAM Server / nur noch ca 2048M Free

T

testit

Well-Known Member
Hallo,

habe unter einem frisch aufgesetzten Server mit FreeBSD 10.1 mit TOP folgendes Bild:

Code: 
27 processes:  1 running, 26 sleeping
CPU:  0.3% user,  0.0% nice,  0.6% system,  0.2% interrupt, 98.9% idle
Mem: 14M Active, 398M Inact, 14G Wired, 1536K Cache, 1151M Free
ARC: 12G Total, 1854M MFU, 9351M MRU, 16K Anon, 59M Header, 556M Other
Swap: 2048M Total, 2048M Free

Offensichtlich reißt ARC (Cache?) sich den meisten Speicher unter den Nagel.
Ich habe extra von 8GB auf 16GB verdoppelt, um anderen Prozessen/Anwendungen mehr Speicher zu verschaffen, wie bspw. MySQL-Tabellen, PHP-Acceleratoren u.ä.

Was hat es mit dem ARC auf sich?
Wie limitiere ich diesen sinnvoll?

Danke und freundliche Grüße
testit
 
Gar nicht. Ich spekuliere hier das der Back-Pressuring unterstützt und automatisch freigegeben wird, wenn der Speicher knapp wird.
 
Hallo,

abgesehen davon, dass ich zur Zeit noch nicht weiß, was genau ARC ist: Wenn ich bspw. für einen PHP-Cache-Accelerator oder MySQL-Server oder bspw. virtuelle Maschinen XY RAM reservieren will,stellt sich mir die Frage, ob diese RAM-"Bedürfnisse" dann vorrangig behandelt werden und ACR sich anpasst?

Oder MUSS man in der Tat, wie von Rob angegeben, von vornheirein ARC limitieren?


Danke und nette Grüße
testit
 
ARC ist der Adaptive Replacement Cache von ZFS. Also ein Dateisystemcache. Ich würde ihn generell begrenzen, sofern du freien Arbeitsspeicher wirklich benötigst, damit es erst gar nicht zu Wettbewerbssituationen kommt.

Rob
 
Nun ja, ich würde schon gerne vorab wissen, ob bspw. für VMs reservierter RAM des Hostsystems oder bspw, RAM für X-Cache VORGEHT und sich ARC dann anpasst!?

Viele Grüße
testit
 
Wäre ja sonst leicht dämlich, wenn auf _jedem_ Rechner nur 1G RAM frei wäre und ARC immer den Rest fest belegt.
 
FreeBSD hat wie die meisten (alle?) unixoiden Systeme eine Speicherhierarchie, die den zur Verfügung stehenden Physischen Speicher grob gesagt in Klassen teilt. Ganz oben steht von der Hardware genutzter Speicher, also zum Beispiel DMA-Bereiche. Darunter folgen dann verschiedene Typen Kernelspeicher. Bis zu dieser Ebene ist Speicher praktisch nicht antastbar, ist hier kein neuer Speicher mehr zur Verfügung zu stellen, gibt es eine nette Panic. Darunter folgt dann der Speicher, welchen einzelne Prozesse im Userland belegen. Auf unterster Ebene liegen die Caches. Das ist der Namecache, der Buffercache für konvetionelle Dateisysteme und ZFS mit seinem ARC.

Die genaue Algorithmik ist nun sehr komplex, man schaut es sich besser im Code an. Grundsätzlich (und stark vereinfacht!) funktioniert es aber so:

FreeBSD versucht immer eine ausreichende Menge Speicher als sofort verfügbar bereit zu halten. Das ist das "Free" Feld in top. Wie viel Speicher es ist, wird dynamisch anhand einer Reihe Kennzahlen wie gesamter RAM-Menge, Anwendungsprofil und so weiter ermittelt. Meist ist dieser Wert eher niedrig. Dazu kommt eine beliebig große Menge Speicher der "inaktive" ist. Dieser Speicher beinhaltet Daten, die aber derzeit keinem Prozess oder anderem Nutzer zugeordnet sind. Ein Beispiel wäre eine Bibliothek. Derzeit benötigt sie keiner, aber wenn sie wieder aufgerufen wird, liegt sie bereits im Speicher und muss nicht nachgeladen werden. Wenn "Free" zu niedrig wird, weil Speicher angefordert wurde, werden Speicherseiten aus "Inactive" gewaschen und frisch und neu als "Free" bereitgestellt.

Wenn nun aber nicht genügend Speicher "Inactive" ist und der Bedarf an "Free" nicht mehr durch ihn gedeckt werden kann, kommt das System in eine Situation von Speichermangel. In diesem Fall greift die Hierarchie. Im ersten Schritt werden Nutzer auf der Cache-Ebene angewiesen ihre Caches zu leeren. Gemeinhin wird das als "Back Pressuring" bezeichnet. ZFS wird gesagt, dass er Caches freigeben muss. Er baut daraufhin seinen ARC ab, "Inactive" steigt an und kurz darauf kann mehr "Free" bereit gestellt werden. Grundsätzlich gilt hier, dass Swap je nach Situation eine höhere Priorität als das Freiräumen von Caches haben kann. Beispielsweise wird das System lieber lange Zeit ungenutzte ungenutzte Prozesse in die Swap schieben, als einen häufig genutzten Cache aufzugeben.

Wenn alle Caches aufgelöst sind und die Swap gefüllt ist, wird irgendwann die nächste Ebene der Hierarchie dran glauben müssen. Der Kernel wird dann einen Prozess abschießen. Ich glaube es trifft den, der die nicht mehr erfüllbare Anforderung stellt oder bei Speicherbedarf des Kernels den größten Prozess. Im Messagebuffer sieht man dann etwas wie "1345: Killed. Out of swap space". Wenn alle Prozesse getötet sind und der Kernel seinen eigenen Speicherhunger noch immer nicht erfüllen kann, gibt es eine Panic. In der Praxis kommt das heute kaum noch vor, es sei denn man hat ein Speicherleck im Kernel.

Lange Rede kurzer Sinn, meistens weiß das System, was es tut. Probleme gibt es mit Caches eigentlich nur, wenn man dem System in die Parade fährt. Ein Beispiel wäre, dass nach Stunden leichter Tätigkeit auf einen Schlag mehr als Zweidrittel des zur Verfügung stehenden Speichers angefordert werden. Dann ist natürlich erstmal helle Panik und es dauert einen Moment, bis die Speicherbelegung entsprechend umgebaut ist. Aber auch das passiert, das System fängt sich wieder und läuft einwandfrei weiter. Daher sollte man Caches erstmal in Ruhe lassen und erst begrenzen, wenn es praktische Probleme gibt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben