Diese Ansicht kann in einer Reihe von Fällen aus der Praxis sehr irreführend sein.
Der Kernel liefert jetzt eine Schätzung für den verfügbaren Speicher im MemAvailableFeld. Dieser Wert unterscheidet sich erheblich von MemFree + Cached.
/ proc / meminfo: geschätzten verfügbaren Speicher bereitstellen [Beschreibung der Kerneländerung , 2014]
Viele Programme für Lastausgleich und Workload-Platzierung überprüfen / proc / meminfo, um abzuschätzen, wie viel freier Speicher verfügbar ist. Sie tun dies im Allgemeinen, indem sie "frei" und "zwischengespeichert" addieren, was vor zehn Jahren in Ordnung war, aber heute garantiert falsch ist.
Dies ist falsch, da zwischengespeichert Speicher enthält, der nicht als Seitencache freigegeben werden kann, z. B. gemeinsam genutzte Speichersegmente, tmpfs und ramfs, und keinen wiedergewinnbaren Plattenspeicher enthält, der auf meist inaktiven Systemen mit einen großen Teil des Systemspeichers beanspruchen kann viele Dateien.
Derzeit kann die Menge an Speicher, die für eine neue Arbeitslast verfügbar ist, ohne das System in den Swap zu verschieben, aus MemFree, Active (Datei), Inactive (Datei) und SReclaimable sowie den "niedrigen" Wasserzeichen von / geschätzt werden proc / zoneinfo. Dies kann sich jedoch in Zukunft ändern, und es sollte nicht erwartet werden, dass der Benutzerraum Kernel-Interna kennt, um eine Schätzung für die Menge an freiem Speicher zu erhalten. Es ist bequemer, eine solche Schätzung in / proc / meminfo anzugeben. Wenn sich die Dinge in Zukunft ändern, müssen wir sie nur an einem Ort ändern.
...
Documentation / filesystems / proc.txt:
...
MemAvailable: Eine Schätzung, wie viel Speicher zum Starten neuer Anwendungen ohne Austausch verfügbar ist. Berechnet aus MemFree, SReclaimable, der Größe der LRU-Dateilisten und den niedrigen Wasserzeichen in jeder Zone. Bei der Schätzung wird berücksichtigt, dass das System einen Seiten-Cache benötigt, um gut zu funktionieren, und dass nicht alle wiederverwendbaren Platten aufgrund der verwendeten Elemente zurückgefordert werden können. Die Auswirkungen dieser Faktoren variieren von System zu System.
1. MemAvailable Details
Wie oben erwähnt, können tmpfs und anderer ShmemSpeicher nicht freigegeben, sondern nur zum Auslagern verschoben werden. CachedIn /proc/meminfokann sehr irreführend sein, da dieser austauschbare ShmemSpeicher enthalten ist. Wenn Sie zu viele Dateien in einem tmpfs haben, könnte dies viel Speicherplatz beanspruchen :-). Shmemkann auch einige Grafikspeicherzuordnungen enthalten , die sehr groß sein können.
MemAvailableEnthält absichtlich keinen austauschbaren Speicher. Zu viel Austausch kann zu langen Verzögerungen führen. Möglicherweise haben Sie sich sogar dafür entschieden, ohne Swap Space zu arbeiten, oder nur eine relativ begrenzte Menge zugelassen.
Ich musste noch einmal überprüfen, wie es MemAvailablefunktioniert. Auf den ersten Blick schien der Code diese Unterscheidung nicht zu erwähnen.
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
Ich fand jedoch, dass es korrekt Shmemals "benutzter" Speicher behandelt wird. Ich habe mehrere 1 GB-Dateien in einem tmpfs erstellt. Jede Erhöhung um 1 GB wird um 1 GB Shmemverringert MemAvailable. Die Größe der "Datei-LRU-Listen" enthält also keinen gemeinsam genutzten Speicher oder einen anderen austauschbaren Speicher. (Ich habe festgestellt, dass diese Seitenzahlen auch im Code verwendet werden, der das "Dirty Limit" berechnet .)
Bei dieser MemAvailableBerechnung wird auch davon ausgegangen, dass Sie mindestens genügend Datei-Cache behalten möchten, um dem "niedrigen Wasserzeichen" des Kernels zu entsprechen. Oder die Hälfte des aktuellen Caches - je nachdem, welcher Wert kleiner ist. (Dies gilt auch für wiederverwendbare Platten). Das "niedrige Wasserzeichen" des Kernels kann optimiert werden, beträgt jedoch normalerweise etwa 2% des System-RAM . Wenn Sie also nur eine grobe Schätzung wünschen, können Sie diesen Teil ignorieren :-).
Wenn Sie firefoxmit ca. 100 MB Programmcode im Seitencache arbeiten, möchten Sie diese 100 MB im Allgemeinen im RAM behalten :-). Andernfalls treten im besten Fall Verzögerungen auf, im schlimmsten Fall verbringt das System seine gesamte Zeit damit, zwischen verschiedenen Anwendungen zu wechseln . Erlaubt MemAvailablealso einen kleinen Prozentsatz RAM dafür. Es könnte nicht genug erlauben, oder es könnte zu großzügig sein. "Die Auswirkungen dieser Faktoren variieren von System zu System."
Für viele PC-Workloads ist der Punkt "Viele Dateien" möglicherweise nicht relevant. Trotzdem habe ich derzeit 500 MB wiederverwendbaren Plattenspeicher auf meinem Laptop (von 8 GB RAM). Dies liegt an ext4_inode_cache(über 300.000 Objekten). Es ist passiert, weil ich kürzlich das gesamte Dateisystem scannen musste, um herauszufinden, was meinen Speicherplatz belegt :-). Ich habe den Befehl verwendet df -x / | sort -n, aber z. B. würde Gnome Disk Usage Analyzer dasselbe tun.
2. [Bearbeiten] Speicher in Kontrollgruppen
Sogenannte „Linux - Container“ sind aufgebaut aus namespaces, cgroupsund verschiedene andere Funktionen je nach Geschmack :-). Sie bieten möglicherweise eine Umgebung, die überzeugend genug ist, um so etwas wie ein vollständiges Linux-System auszuführen. Hosting-Services können solche Container erstellen und als "virtuelle Server" verkaufen :-).
Hosting-Server können auch "virtuelle Server" mit Funktionen erstellen, die nicht in Mainline-Linux enthalten sind. OpenVZ- Container datieren Hauptgruppen-Gruppen um zwei Jahre vor und können "Beancounters" verwenden, um den Speicher zu begrenzen. Sie können also nicht genau verstehen, wie diese Speicherbeschränkungen funktionieren, wenn Sie nur Dokumente lesen oder Fragen zum Linux-Kernel stellen. cat /proc/user_beancounterszeigt die aktuelle Nutzung und Grenzen. vzubcpräsentiert es in einem etwas freundlicheren Format. Die Hauptseite von Beancounters dokumentiert die Zeilennamen .
Zu den Kontrollgruppen gehört die Möglichkeit, Speicherbeschränkungen für die darin enthaltenen Prozesse festzulegen. Wenn Sie Ihre Anwendung in einer solchen Gruppe ausführen, steht der Anwendung nicht der gesamte Systemspeicher zur Verfügung :-). Wie können wir in diesem Fall den verfügbaren Speicher sehen?
Die Schnittstelle hierfür unterscheidet sich in vielerlei Hinsicht, je nachdem, ob Sie cgroup-v1 oder cgroup-v2 verwenden .
Meine Laptop-Installation verwendet cgroup-v1. Ich kann laufen cat /sys/fs/cgroup/memory/memory.stat. Die Datei zeigt verschiedene Felder einschließlich total_rss, total_cache, total_shmem. shmem, einschließlich tmpfs, zählt zu den Speichergrenzen. Ich denke, Sie können total_rssals inverses Äquivalent von betrachten MemFree. Und es gibt auch die Datei memory.kmem.usage_in_bytes, die den Kernelspeicher einschließlich der Platten darstellt. (Ich gehe davon aus, dass memory.kmem.auch memory.kmem.tcp.zukünftige Erweiterungen enthalten sind, obwohl dies nicht explizit dokumentiert ist). Es gibt keine separaten Zähler zum Anzeigen des wiedergewinnbaren Plattenspeichers. Wird das Dokument für cgroup-v1 sagt die Speichergrenzen trifft nicht auslösen reclaim jeder Platte Speicher. (Das Dokument enthält außerdem den Haftungsausschluss, dass es "hoffnungslos veraltet" ist und dass Sie den aktuellen Quellcode überprüfen sollten.)
cgroup-v2 ist anders. Ich denke, die Stammgruppe (oberste Ebene) unterstützt keine Speicherabrechnung. cgroup-v2 hat noch eine memory.statDatei. Alle Felder summieren sich über untergeordnete Gruppen, sodass Sie nicht nach total_...Feldern suchen müssen . Es gibt ein fileFeld, was bedeutet, dass dasselbe getan cachewurde. Ärgerlicherweise sehe ich kein Gesamtfeld wie rssinnen memory.stat; Ich denke, Sie müssten einzelne Felder addieren. Es gibt separate Statistiken für wiedergewinnbaren und nicht wiedergewinnbaren Plattenspeicher. Ich denke, eine v2-Gruppe wurde entwickelt, um Platten zurückzugewinnen, wenn der Speicher knapp wird.
Linux-Gruppen gruppieren nicht automatisch /proc/meminfo(oder eine andere Datei in /proc), sodass die Werte für den gesamten Computer angezeigt werden. Dies würde VPS-Kunden verwirren. Es ist jedoch möglich, Namespaces zu verwenden, um sie /proc/meminfodurch eine Datei zu ersetzen, die von der jeweiligen Containersoftware gefälscht wurde . Wie nützlich die gefälschten Werte sind, hängt davon ab, was diese spezielle Software tut.
systemdglaubt, dass cgroup-v1 nicht sicher delegiert werden kann, z. B. an Container. Ich habe in einen systemd-nspawnContainer auf meinem cgroup-v1-System geschaut. Ich kann die cgroup sehen, in der es platziert wurde, und den Speicher, der darauf abrechnet. Andererseits systemdrichtet das Enthaltene nicht die üblichen pro-Service-Gruppen für die Ressourcenabrechnung ein. Wenn die Speicherabrechnung in dieser Gruppe nicht aktiviert wäre, könnte der Container sie vermutlich nicht aktivieren.
Ich nehme an, wenn Sie sich in einem cgroup-v2-Container befinden, sieht dieser anders aus als das Stammverzeichnis eines echten cgroup-v2-Systems, und Sie können sehen, dass der Speicher für die cgroup der obersten Ebene verantwortlich ist. Wenn für die angezeigte cgroup die Speicherabrechnung nicht aktiviert ist, wird Ihnen hoffentlich die Berechtigung delegiert, damit Sie die Speicherabrechnung insystemd (oder einer gleichwertigen Version) aktivieren können .
MemAvailable, es wurde in 3.14 hinzugefügt.