Dies ist ein alter Beitrag, aber ich würde mir immer noch die Freiheit nehmen, hier meine Gedanken zu äußern.
Ausgehend von Down Under würde Linux zuerst den Speicher in Seiten aufteilen (normalerweise 4 KB pro Seite auf einem x86_64-System). Anschließend wird ein virtueller Speicher erstellt, dessen Zuordnung mit MMU (Memory Management Unit) zum physischen Speicher erfolgt.
Prozessen wird Speicher aus dem virtuellen Speicherbereich zugewiesen. Beachten Sie daher, dass in / proc / meminfo VMalloc * als Details zum virtuellen Speicher angezeigt wird.
Nehmen wir an, Sie haben einen Prozess, der Speicher anfordert (sagen wir 300 MB - ein Webbrowser). Dem Prozess würden 300 MB aus dem virtuellen Speicher zugewiesen, es ist jedoch nicht erforderlich, dass er speicherabgebildet ist (dh dem physischen Speicher zugeordnet ist). Für die Speicherverwaltung gibt es das Konzept "Copy on Write" (Kopieren beim Schreiben). Wenn Ihre Prozesse tatsächlich den vom virtuellen Speicher zugewiesenen Speicher verwenden (dh etwas in den Speicher schreiben), wird dieser nur dem physischen Speicher zugeordnet. Auf diese Weise kann der Kernel in einer Umgebung mit mehreren Prozessen effizient arbeiten.
Was sind Cache?
Ein Großteil des von Prozessen verwendeten Speichers wird gemeinsam genutzt. Nehmen wir an, die glibc-Bibliothek wird von fast allen Prozessen verwendet. Was bringt es, mehrere Kopien von glibc im Speicher zu behalten, wenn jeder Prozess auf denselben Speicherort zugreifen und die Arbeit erledigen kann? Solche häufig verwendeten Ressourcen werden im Cache gespeichert, sodass bei Bedarf von Prozessen auf denselben Speicherort verwiesen werden kann. Dies hilft bei der Beschleunigung von Prozessen, da das erneute Lesen von glibc (etc.) Von der Festplatte zeitaufwändig wäre.
Das obige gilt für gemeinsam genutzte Bibliotheken, ähnlich wie für das Lesen von Dateien. Wenn Sie zum ersten Mal eine große Datei (z. B. 100-200 MB) lesen, würde dies viel Zeit in Anspruch nehmen. Wenn Sie jedoch versuchen, dasselbe erneut zu lesen, ist dies schneller. Die Daten wurden im Speicher zwischengespeichert und nicht für alle Blöcke erneut gelesen.
Was ist Puffer?
Wenn ein Prozess Datei-E / A ausführt, ist er in Bezug auf den Puffer auf den Puffer des Kernels angewiesen, um Daten auf die Festplatte zu schreiben. Der Prozess fordert den Kernel auf, die Aufgabe zu erledigen. Im Auftrag des Prozesses schreibt der Kernel die Daten in seinen "Puffer" und teilt dem Prozess mit, dass der Schreibvorgang abgeschlossen ist. Auf asynchrone Weise synchronisiert der Kernel diese Daten im Puffer weiterhin mit der Festplatte. Auf diese Weise verlassen sich die Prozesse darauf, dass der Kernel den richtigen Zeitpunkt für die Synchronisierung der Daten auf die Festplatte auswählt, und die Prozesse könnten weiterarbeiten. Denken Sie daran, dies ist die allgemeine E / A, die normale Prozesse ausführen. Spezielle Prozesse, die bestätigen müssen, dass die E / A tatsächlich auf dem Datenträger ausgeführt wird, können jedoch andere Mechanismen für die E / A-Ausführung auf dem Datenträger verwenden. Einige der OpenSource-Dienstprogramme sind libaio. Es gibt auch Möglichkeiten, die explizite Synchronisierung mit FDs aufzurufen, die in Ihrem Prozesskontext geöffnet sind.
Was sind dann Seitenfehler?
Betrachten Sie ein Beispiel, wenn Sie einen Prozess starten (beispielsweise einen Webbrowser), dessen Binärdatei ungefähr 300 MB groß ist. Die gesamten 300 MB der Webbrowser-Binärdatei funktionieren jedoch nicht sofort. Der Prozess bewegt sich in seinem Code von Funktionen zu Funktionen. Wie bereits erwähnt, werden 300 MB virtueller Speicher verbraucht, jedoch wird nicht der gesamte Speicher dem physischen Speicher zugeordnet (RSS-residenter Speicher wäre geringer, siehe obere Ausgabe). Wenn die Codeausführung einen Punkt erreicht, für den der Speicher nicht physisch zugeordnet ist, liegt ein Seitenfehler vor. Der Kernel ordnet diesen Speicher physisch zu und ordnet die Speicherseite Ihrem Prozess zu. Ein solcher Seitenfehler wird "Minor Page Faults" genannt. In ähnlicher Weise werden beim Ausführen von Datei-E / A größere Seitenfehler verursacht.
Wann und warum findet ein Swap Out statt?
Situation 1:
Betrachten wir im Einklang mit den obigen Details ein Szenario, in dem die gute Speichermenge in eine Speicherzuordnung umgewandelt wird. Und jetzt startet ein Prozess, der Speicher benötigt. Wie oben besprochen, wird der Kernel einige Speicherzuordnungen vorgenommen haben. Es ist jedoch nicht genügend physischer RAM verfügbar, um den Speicher zuzuordnen. Nun wird der Kernel zuerst in den Cache schauen, er wird einige alte Speicherseiten haben, die nicht benutzt werden. Diese Seiten werden auf eine separate Partition (SWAP) übertragen, einige Seiten werden freigegeben, und die freigegebenen Seiten werden der neuen Anforderung zugeordnet. Da der Schreibvorgang auf der Festplatte viel langsamer ist als im Solid-State-RAM, nimmt dieser Vorgang viel Zeit in Anspruch, weshalb eine Verlangsamung zu beobachten ist.
Situation 2:
Nehmen wir an, Sie sehen viel freien Speicher im System. Sogar dann sieht man, dass eine Menge Swap-Outs stattfinden. Möglicherweise liegt ein Problem mit der Speicherfragmentierung vor. Stellen Sie sich einen Prozess vor, der vom Kernel 50 MB zusammenhängenden Speicher erfordert. (Denken Sie daran, zusammenhängend). Offensichtlich hätte der Kernel Seiten zufällig verschiedenen Prozessen zugewiesen und einige davon freigegeben. Wenn wir jedoch zusammenhängenden Speicher benötigen, muss nach einem Block gesucht werden, der die Anforderungen der Prozesse erfüllt. Wenn es nicht in der Lage ist, einen solchen Speicher abzurufen, muss es einige alte Speicherseiten austauschen und dann zusammenhängende zuweisen. Auch in solchen Fällen würde ein SWAP-Out stattfinden. Ab Kernel 2.6 haben sich solche Fragmentierungsprobleme erheblich verringert. Wenn das System jedoch über einen längeren Zeitraum läuft, können solche Probleme weiterhin auftreten.
Siehe dieses Beispiel ( vmstat-Ausgabe )
2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32 r b swpd free buff cache si so bi bo in cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660 1 8803 12701 4336 37487 14 7 40 38 0
2016-10-30 03:56:34 3 20 2889296 4977580 3345316 12026752 2109 2 8445 14665 4656 36294 12 7 46 34 0
2016-10-30 03:57:04 1 11 3418868 4939716 3347804 11536356 586 4744 2547 9535 3086 24450 6 3 59 33 0 <<<-----
2016-10-30 03:57:34 3 19 3456252 5449884 3348400 11489728 3291 13371 6407 17957 2997 22556 6 4 66 24 0
2016-10-30 03:58:04 7 6 4194500 5663580 3349552 10857424 2407 12240 3824 14560 2295 18237 4 2 65 29 0
2016-10-30 03:58:34 2 16 4203036 5986864 3348908 10838492 4601 16639 7219 18808 2575 21563 6 4 60 31 0
2016-10-30 03:59:04 3 14 4205652 6059196 3348760 10821448 6624 1597 9431 4357 1750 20471 6 2 60 31 0
2016-10-30 03:59:34 2 24 4206968 6053160 3348876 10777216 5221 2067 10106 7377 1731 19161 3 3 62 32 0
2016-10-30 04:00:04 0 13 4205172 6005084 3348932 10785896 6236 1609 10330 6264 1739 20348 4 2 67 26 0
2016-10-30 04:00:34 4 11 4206420 5996396 3348976 10770220 6554 1253 10382 4896 1964 42981 10 5 58 27 0
2016-10-30 04:01:04 6 4 4177176 5878852 3348988 10825840 8682 765 10126 2716 1731 32949 8 4 69 19 0
@ 2016-10-30 03:57:04, wir sehen, dass immer noch genügend freier Arbeitsspeicher verfügbar ist. Allerdings geschah auch dann ein Tausch. Wir haben den Prozessbaum zu diesem Zeitpunkt überprüft und keinen Prozess gefunden, der so viel Speicher benötigt (mehr als freien Speicher). Der offensichtliche Verdacht war die oben beschriebene Situation 2. Wir haben die obigen Protokolle buddyinfo und zoneinfo überprüft (verwenden Sie den echo m> / proc / sysrq-Trigger, um diese zu überprüfen, die Ausgabe erfolgt in syslogs).
Für ein normales System von uns ist dies der Vergleich von Zoneninformationen. Und Grafiken für Cache / Free / Low Mem werden ebenfalls unten erwähnt
Wenn Sie sich die Informationen ansehen, ist klar, dass es eine Speicherfragmentierung in Knoten 0 und Knoten 1 gibt (Knoten ist eine NUMA-basierte Maschine, daher mehrere Knoten (siehe Nummer, um die Informationen für Ihr System zu überprüfen)).
Speicherfragmentierung ist auch ein Grund, warum die Auslagerungsnutzung zunehmen kann, selbst wenn freier Speicher vorhanden ist.
