Frage Warum wird Swap verwendet, wenn viel freier Speicher übrig ist?


Ich habe einen ziemlich guten (dedizierten) Web-Server mit guten Speicherressourcen:

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)   

Wie Sie sehen, verwendet mein Server Swap, wenn genügend freier Speicher verfügbar ist.

Ist das normal oder stimmt etwas mit der Konfiguration oder der Codierung nicht?

N.B.
Mein MySQL-Prozess verwendet aus irgendeinem Grund über 160% der CPU-Leistung; Ich weiß nicht warum, aber ich habe nicht mehr als 70 gleichzeitige Benutzer ...


34
2017-08-24 12:55


Ursprung


Anwendungen können mehr als 100% der CPU in Linux verwenden? Ähm ... - BlueRaja
@BlueRaja: Ja, weil in Linux CPU-Auslastung relativ zu einer einzelnen CPU gemessen wird, nicht alle CPUs in Ihrem System. In einer Maschine mit 8 CPUs stehen also maximal 800% CPU zur Verfügung. - Daniel Pryden
Welche MySQL-Version verwendest du? - RolandoMySQLDBA
@RolandoMySQLDBA Version 5.5 - user1179459


Antworten:


Das ist völlig normal.

Beim Systemstart starten eine Reihe von Diensten. Diese Dienste initialisieren sich selbst, lesen Konfigurationsdateien ein, erstellen Datenstrukturen und so weiter. Sie benutzen etwas Speicher. Viele dieser Dienste werden für die gesamte Zeit, in der das System läuft, nie wieder ausgeführt, da Sie sie nicht verwenden. Einige von ihnen können in Stunden, Tagen oder Wochen laufen. Aber all diese Daten sind im physischen Gedächtnis.

Natürlich kann das System diese Daten nicht wegwerfen. Es kann nicht beweisen, dass es buchstäblich nie zugänglich ist. Einer dieser Dienste könnte zum Beispiel der sein, der Ihnen Fernzugriff auf die Box bietet. Du hast es vielleicht in einer Woche nicht benutzt, aber wenn du es benutzt, hat es besser funktioniert.

Aber das System weiß, dass es diesen physischen Speicher möglicherweise für Dinge wie einen Festplatten-Cache oder auf andere Weise, die die Leistung verbessern, verwenden möchte. So macht es opportunistische Swapping. Wenn es nichts Besseres zu tun hat, schreibt es Daten, die sehr lange nicht benutzt wurden, mit Swap-Space auf die Festplatte. Die Seiten bleiben jedoch im physischen Speicher erhalten. So können sie immer noch abgerufen werden, ohne sie austauschen zu müssen.

Wenn das System später diesen physischen Speicher für etwas anderes benötigt, kann es diese Seiten einfach wegwerfen, weil es sie bereits zum Tauschen geschrieben hat. Dies gibt dem System das Beste aus beiden Welten. Die Daten werden weiterhin im Speicher gehalten, sodass auf sie zugegriffen werden kann, ohne dass sie von der Festplatte gelesen werden müssen. Aber wenn das System diesen Speicher für einen anderen Zweck benötigt, muss er es nicht zuerst aufschreiben. Großer Gewinn rundum.


61
2017-08-24 13:10



In diesem Fall kannst du bitte erklären, warum manchmal Swap Space überhaupt nicht benutzt wird. Mem: 49554484k insgesamt, 4087592k verwendet, 45466892k frei, 349244k Puffer Swap: 94204k insgesamt, 0k verwendet, 94204k frei, 1113644k zwischengespeichert - ananthan
@Ananthan: Es könnte viele Gründe geben. Am wahrscheinlichsten ist, dass das System selbst aufgrund von gepufferten Schreibvorgängen nie unter irgendeinem Speicherdruck stand, so dass der opportunistische Auslagerungscode möglicherweise nie ausgelöst wurde. Es könnte auch sein, dass jemand dachte, dass eine Swap-Nutzung schlecht ist und das System so falsch eingestellt hat, dass es nicht opportunistisch wechselt (indem es reduziert wird) Swappiness). - David Schwartz


Dies kann passieren, wenn Sie in der Vergangenheit mehr Arbeitsspeicher benötigten als physischer Arbeitsspeicher in der Maschine. Zu diesem Zeitpunkt wurden einige Daten in den Auslagerungsspeicher geschrieben.

Wenn später Speicher freigegeben wird, werden Daten aus Swap nicht automatisch in den RAM zurückgelesen: Dies geschieht nur, wenn die Daten in Swap tatsächlich von einem Prozess benötigt werden. Das ist völlig normal.

Was Ihren mysql-Prozess betrifft: Das hängt von der Art der Abfragen ab, die Sie ausführen. Theoretisch könnten 2 sehr komplexe Abfragen ausreichen, um eine solche Last unabhängig von der Anzahl der Benutzer zu erhalten. Sie könnten das Protokoll für langsame Abfragen aktivieren, um mehr Einblick zu erhalten, welche Abfragen lastintensiv sind.


6
2017-08-24 13:02



Nein - Swap-Nutzung ist keine Hochwassermarke. Wenn ausgelagerte Seiten zurückversetzt werden, werden die Festplattenseiten als nicht verwendet markiert (können aber weiterhin Daten enthalten). - symcbean
Ich habe nur ein Szenario erwähnt, in dem man Swap verwenden kann, aber das ist nicht immer symptomatisch dafür, dass nicht genug physischer Speicher vorhanden ist - wie auch oben von David Schwartz erklärt - brain99


Sie können dieses Verhalten auch ändern nach sysctl -w vm.swappiness=10, was den Einsatz von Swap erheblich reduzieren wird, bis es tatsächlich benötigt wird.

Was MySQL anbelangt, haben Sie zumindest einen Baseline-Konfigurationstest unter Verwendung des tuning-primer.sh Skript?


3
2017-08-24 14:21



Dies wird die Tendenz erhöhen, dass Cache / Puffer zurückgewonnen werden. Leider ist aus der ursprünglichen Frage nicht klar, ob die Zahl von 29,53% Puffer / Cache enthält - wenn dies nicht der Fall ist, wird sich die von Ihnen vorgeschlagene Änderung nachteilig auf die Leistung auswirken. Wenn dieses dbms ausgiebig innodb verwendet, dann ist es wahrscheinlich schlecht konfiguriert (obwohl eine einzelne 8-Core-16-GB-Box für die Verwendung als Webserver eine BAD-Entscheidung von Anfang an ist) - symcbean
Warum sagst du die schlechte Wahl für den Webserver? ich benutze innodb nicht viel ich bevorzuge noch myisam, weil meine liest 70% sind und schreibt nur 30% .... - user1179459


Dies ist wahrscheinlich, wie David erklärte, ein normales Verhalten des Linux - Kernels, aber es kann auch ein Vorkommen des MySQL "Wahnsinn vertauschen" -Problem. In Ihrem Fall (8 CPU, 16 GB RAM insgesamt, 5 GB verwendet), sollte Ihr Computer ein NUMA-System mit 4 Knoten (Sockets) und 4 GB RAM pro Knoten und einem MySQL InnoDB-Pufferpool von 4 sein GB.

Kurz gesagt (Sie sollten den obigen Link für vollständige Details lesen), das ist was passiert:

  1. Wenn Ihr System gestartet wird, werden Prozesse auf allen NUMA-Knoten verteilt, wobei ein Teil ihres Speichers verwendet wird.
  2. Wenn MySQL startet, weist es 4 GB für den InnoDB-Pufferpool zu, füllt den RAM eines NUMA-Knotens und verwendet etwas RAM auf anderen Knoten.
  3. Der Linux-Kernel, der zugewiesenen Arbeitsspeicher nicht von einem NUMA-Knoten zum anderen verschieben kann, hält es für sinnvoll, die Seiten des ausgehungerten Knotens auszutauschen (oder Seiten austauschen zu müssen, weil die Seiten ausgetauscht werden müssen).

Um dies zu vermeiden, ändern Sie die Speicherzuweisung für MySQL, um RAM auf allen Kernen zuzuweisen (siehe den obigen Link für weitere Details).


1
2018-05-23 12:08