☰

Warum wird Swap verwendet, wenn noch genügend freier Speicher vorhanden ist?

tag-icon • tag-icon linux mysql php
Warum wird Swap verwendet, wenn noch genügend freier Speicher vorhanden ist?

Ich habe einen ziemlich guten Webserver (dedizierter 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 ausreichend freier Speicher verfügbar ist.

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

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

Antwort1

Das ist völlig normal.

Beim Systemstart werden eine Reihe von Diensten gestartet. Diese Dienste initialisieren sich selbst, lesen Konfigurationsdateien ein, erstellen Datenstrukturen und so weiter. Sie beanspruchen etwas Speicher. Viele dieser Dienste werden während der gesamten Systemlaufzeit nie wieder ausgeführt, da Sie sie nicht verwenden. Einige von ihnen können Stunden, Tage oder Wochen lang ausgeführt werden. Doch all diese Daten befinden sich im physischen Speicher.

Natürlich kann das System diese Daten nicht wegwerfen. Es kann nicht beweisen, dass sie buchstäblich nie abgerufen werden. Einer dieser Dienste könnte beispielsweise derjenige sein, der Ihnen Fernzugriff auf die Box ermöglicht. Sie haben ihn vielleicht eine Woche lang nicht verwendet, aber wenn Sie ihn verwenden, sollte er besser funktionieren.

Das System weiß jedoch, dass es den physischen Speicher für Dinge wie einen Festplattencache oder auf andere Weise verwenden möchte, um die Leistung zu verbessern. Daher führt es opportunistisches Swapping durch. Wenn es nichts Besseres zu tun hat, schreibt es Daten, die lange nicht verwendet wurden, unter Verwendung des Swap-Speichers auf die Festplatte. Die Seiten bleiben jedoch weiterhin im physischen Speicher. Auf sie kann also weiterhin zugegriffen werden, ohne dass sie ausgelagert werden müssen.

Wenn das System den physischen Speicher später für etwas anderes benötigt, kann es diese Seiten einfach wegwerfen, da es sie bereits in den Swap-Speicher geschrieben hat. Dadurch erhält das System das Beste aus beiden Welten. Die Daten bleiben im Speicher, sodass auf sie zugegriffen werden kann, ohne dass sie von der Festplatte gelesen werden müssen. Wenn das System den Speicher jedoch für einen anderen Zweck benötigt, muss es ihn nicht zuerst ausschreiben. Ein großer Gewinn für alle.

Antwort2

Dies kann passieren, wenn Sie in der Vergangenheit einmal mehr Speicher benötigt haben, als Ihnen physischer RAM auf dem Rechner zur Verfügung steht. Zu diesem Zeitpunkt wurden einige Daten in den Swap-Speicher geschrieben.

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

Was Ihren MySQL-Prozess betrifft: Dies hängt alles von der Art der Abfragen ab, die Sie ausführen. Theoretisch könnten wahrscheinlich 2 sehr komplexe Abfragen ausreichen, um eine solche Last zu erreichen, unabhängig von Ihrer Benutzeranzahl. Sie könnten das Protokoll für langsame Abfragen aktivieren, um mehr Einblick in die Abfragen zu erhalten, die besonders lastintensiv sind.

Antwort3

Sie können dieses Verhalten auch ändern sysctl -w vm.swappiness=10, indem Sie , wodurch die Verwendung des Swap-Speichers erheblich reduziert wird, bis er tatsächlich benötigt wird.

Was MySQL betrifft, haben Sie zumindest einen Basiskonfigurationstest mit demtuning-primer.shSkript?

Antwort4

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

Kurz gesagt (für ausführliche Einzelheiten lesen Sie bitte den Link oben), ist Folgendes passiert:

  1. Beim Systemstart werden die Prozesse auf alle NUMA-Knoten verteilt und nutzen dabei einen Teil ihres Speichers.
  2. Beim Start reserviert MySQL 4 GB für den InnoDB-Pufferpool, füllt den RAM eines NUMA-Knotens und verwendet etwas RAM auf anderen Knoten.
  3. Dann denkt der Linux-Kernel, der zugewiesenen RAM nicht von einem NUMA-Knoten auf einen anderen verschieben kann, dass es eine gute Idee wäre, Seiten aus dem ausgehungerten Knoten auszulagern (oder Seiten auslagern zu müssen, weil Seiten ausgelagert werden mussten).

Um dies zu vermeiden, ändern Sie die Speicherzuweisung für MySQL, um RAM auf allen Kernen zuzuweisen (weitere Einzelheiten finden Sie unter dem obigen Link).

verwandte Informationen