Wie kann Swapoff so langsam sein?

Irgendwie habe ich zufällig 14 GB Speicher ausgelagert. Nachdem ich den Täter getötet habe, habe ich wieder jede Menge freien Speicherplatz, sodass ich dachte, ich könnte die wichtigen Daten wieder einspielen. Also mit 5 GB von 32 GB und 14 GB Swap-Speicherplatz lief ich swapoff -a... und 4 Stunden später war ungefähr die Hälfte der Arbeit beendet.

Das bedeutet weniger als 1 MB / s, während ich problemlos 200 MB / s kopieren kann. Mein Swap ist verschlüsselt, genauso wie alle normalen Partitionen. Mit aes-ni wird die CPU nicht merklich ausgelastet (und das Ausfüllen des Swap-Speicherplatzes dauerte nur wenige Minuten). Ich sehe, dass es keinen besonderen Grund gibt, zu optimieren swapoff, aber ich frage mich, wie es so langsam werden könnte.

Ich füge nur ein paar Daten hinzu: Mein Hauptspeicher ist 32 GB und ich habe 32 GB Swap-Speicherplatz auf jeder der 4 Festplatten (sicherlich ein Overkill, aber wen interessiert das?). Der gesamte Swap-Bereich kann in weniger als 5 Minuten entschlüsselt und gelesen werden:

time -p sudo sh -c 'for i in /dev/mapper/cryptswap?; do md5sum $i & done; wait'
014a2b7ef300e11094134785e1d882af  /dev/mapper/cryptswap1
a6d8ef09203c1d8d459109ff93b6627c  /dev/mapper/cryptswap4
05aff81f8d276ddf07cf26619726a405  /dev/mapper/cryptswap3
e7f606449327b9a016e88d46049c0c9a  /dev/mapper/cryptswap2
real 264.27

Das Lesen eines Teils einer Partition kann nicht langsamer sein als das Lesen aller Teile. Das Lesen von ungefähr 1/10 dauert jedoch ungefähr 100-mal länger.

Ich beobachtete, dass swapoffsowohl die CPU zum größten Teil im Leerlauf war (vielleicht 10% eines Kerns) als auch die Festplatten ("gemessen" durch die LEDs). Ich habe auch gesehen, dass die Swap-Räume nacheinander abgeschaltet wurden.

Schauen wir uns zunächst an, was Sie von Ihrer Festplatte erwarten können. Ihre Festplatte kann nacheinander 200 MB / s verarbeiten . Wenn Sie Suchzeiten berücksichtigen, kann dies viel langsamer sein. Um ein beliebiges Beispiel auszuwählen, werfen Sie einen Blick auf die technischen Daten einer der modernen 3-TB-Festplatten von Seagate, der ST3000DM001 :

• Max. Dauerhafte Datenrate: 210 MB / s

• Suchdurchschnittslesung: <8,5 ms

• Bytes pro Sektor: 4.096

Wenn Sie nie suchen müssen und sich Ihr Swap in der Nähe des Randes der Festplatte befindet, können Sie mit einer maximalen Rate von 210 MB / s rechnen

Wenn Ihre Swap-Daten jedoch vollständig fragmentiert sind, müssen Sie im schlimmsten Fall nach jedem Sektor suchen, den Sie lesen. Das bedeutet, dass Sie nur alle 8,5 ms 4 KB lesen können, oder 4 KB / 0,0085 = 470 KB / s

Auf Anhieb ist es also nicht unvorstellbar, dass Sie tatsächlich mit Festplattengeschwindigkeiten konfrontiert werden.

Das heißt, es scheint albern, dass swapoffes so langsam laufen würde und Seiten in der falschen Reihenfolge gelesen werden müssten, besonders wenn sie schnell geschrieben würden (was eine falsche Reihenfolge impliziert). Aber vielleicht funktioniert der Kernel so. Ubuntu-Fehlerbericht # 486666 behandelt das gleiche Problem:

The swap is being removed at speed of 0.5 MB/s, while the
hard drive speed is 60 MB/s;
No other programs are using harddrive a lot, system is not under
high load etc.

Ubuntu 9.10 on quad core.

Swap partition is encrypted.
Top (atop) shows near 100% hard drive usage
  DSK | sdc | busy 88% | read 56 | write 0 | avio 9 ms |
but the device transfer is low (kdesysguard)
  0.4 MiB/s on /dev/sdc reads, and 0 on writes

Eine der Antworten war:

It takes a long time to sort out because it has to rearrange and flush the
memory, as well as go through multiple decrypt cycles, etc. This is quite
normal

Der Fehlerbericht wurde ungelöst geschlossen.

Mel Gormans Buch " Den Linux Virtual Memory Manager verstehen " ist etwas veraltet, stimmt jedoch zu, dass dies ein langsamer Vorgang ist:

Die für die Deaktivierung eines Bereichs verantwortliche Funktion wird vorhersehbarerweise aufgerufen sys_swapoff(). Diese Funktion beschäftigt sich hauptsächlich mit der Aktualisierung der swap_info_struct. Die Hauptaufgabe des Seitenwechsels auf jeder ausgelagerten Seite ist die Verantwortung, try_to_unuse()die extrem teuer ist.

Auf der Mailing-Liste für den Linux-Kernel wird ab 2007 etwas mehr darüber diskutiert, was unter dem Thema " Beschleunigung des Swapoffs " zu verstehen ist - obwohl die dort diskutierten Geschwindigkeiten etwas höher sind als die, die Sie sehen.

Es ist eine interessante Frage, die wahrscheinlich im Allgemeinen ignoriert wird, da sie swapoffselten verwendet wird. Ich glaube, wenn Sie es wirklich wollen , ausfindig zu machen , ist der erste Schritt der Festplatte Nutzungsmuster mehr würde versuchen , vorsichtig (mit vielleicht zu beobachten atop, iostatoder noch leistungsfähigere Werkzeugen wie perfoder systemtap). Dinge, nach denen gesucht werden muss, sind möglicherweise übermäßiges Suchen, kleine E / A-Vorgänge, ständiges Umschreiben und Verschieben von Daten usw.

Ich habe das gleiche Problem mit meinem Laptop gehabt, der eine SSD hat, also sollte das Suchen mal kein Problem sein.

Ich habe eine alternative Erklärung gefunden . Hier ist ein Auszug

So wie es jetzt funktioniert, überprüft swapoff jede ausgelagerte Speicherseite in der Swap-Partition und versucht, alle Programme zu finden, die sie verwenden. Wenn sie nicht sofort gefunden werden können, werden die Seitentabellen aller ausgeführten Programme durchsucht, um sie zu finden. Im schlimmsten Fall werden alle Seitentabellen für jede ausgelagerte Seite in der Partition überprüft. Das ist richtig - die gleichen Seitentabellen werden immer wieder überprüft.

Es ist also eher ein Kernelproblem als irgendetwas anderes.

Ja, der swapoffMechanismus ist entsetzlich ineffizient. Die Problemumgehung ist einfach: Iterieren Sie über Prozesse, anstatt über die ausgetauschten Seiten zu iterieren. Verwenden Sie dieses Python-Skript (ich bin nicht verbunden):

git clone https://github.com/wiedemannc/deswappify-auto

Beachten Sie, dass der Daemon-Betriebsmodus nur für Desktops / Laptops gilt, die häufig in den Ruhezustand versetzt werden. Ich würde es nicht als Daemon auf einem Serversystem ausführen - starte es einfach im Vordergrund, warte, bis es meldet, dass es sich um einige Prozesse gekümmert hat, dann stoppe es und versuche:

swapoff /dev/x

Da die meisten Seiten jetzt sowohl im Swap als auch im Memory vorhanden sind, swapoffhat das sehr wenig zu tun und sollte jetzt rasant schnell sein (ich habe Hunderte von MB / s gesehen).

Geschichte Abschnitt voraus

Das oben erwähnte Python-Skript basiert auf dem Rest dieser Antwort, was wiederum meine Verbesserung dieser älteren Antwort war, die von jlong verfasst wurde . Da das Skript viel sicherer ist, empfehle ich, nur den Rest meiner Antwort als letzte Verteidigungslinie zu versuchen :

perl -we 'for(`ps -e -o pid,args`) { if(m/^ *(\d+) *(.{0,40})/) { $pid=$1; $desc=$2; if(open F, "/proc/$pid/smaps") { while(<F>) { if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ $start_adr=$1; $end_adr=$2; }  elsif(m/^Swap:\s*(\d\d+) *kB/s){ print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" }}}}}' | sort -Vr | head

Dies läuft vielleicht 2 Sekunden und wird nicht wirklich etwas tun, listen nur die Top 10 der Speichersegmente (tatsächlich druckt mehr Einzeiler, ja , ich tun Einzeiler lieben, nur die Befehle prüfen, akzeptieren das Risiko, Kopieren und Einfügen in Ihre Muschel; diese wird tatsächlich aus Swap lesen).

...Paste the generated one-liners...
swapoff /your/swap    # much faster now

Der Haupt-Einzeiler ist (für mich) sicher, außer er liest viel / proc.

Die für Ihre manuelle Prüfung vorbereiteten Unterbefehle sind nicht sicher . Jeder Befehl hängt einen Prozess für die Dauer des Lesens eines Speichersegments aus dem Swap. Daher ist es bei Prozessen, die keine Pausen tolerieren, unsicher. Die Übertragungsgeschwindigkeiten, die ich sah, lagen in der Größenordnung von 1 Gigabyte pro Minute. (Das oben erwähnte Python-Skript hat diesen Mangel behoben).

Eine andere Gefahr besteht darin, dass das System zu stark belastet wird. Überprüfen Sie dies mit den üblichen Methoden free -m

Was tut es?

for(`ps -e -o pid,args`) {

  if(m/^ *(\d+) *(.{0,40})/) { 
    $pid=$1; 
    $desc=$2; 

    if(open F, "/proc/$pid/smaps") { 

      while(<F>) { 

        if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ 
          $start_adr=$1; 
          $end_adr=$2; 
        } elsif( m/^Swap:\s*(\d\d+) *kB/s ){
          print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" 
        }
      }
    }
  }
}

Die Ausgabe dieses Perl-Skripts ist eine Reihe von gdbBefehlen, dump memory (range)die ausgelagerte Seiten in den Speicher zurückrufen.

Die Ausgabe beginnt mit der Größe, daher ist es einfach genug, sie | sort -Vr | headzu durchlaufen, um die 10 größten Segmente nach Größe (SSIZE) zu erhalten. Das -Vsteht für versionsnummerngerechte Sortierung, funktioniert aber für meinen Zweck. Ich konnte nicht herausfinden, wie die numerische Sortierung funktioniert.

Wenn während des Auslagerungsvorgangs ein in Verwendung befindlicher Auslagerungsschlitz erkannt wird, wird der Kernel zuerst auf der Seite ausgetauscht. Die Funktion unuse_process () versucht dann, alle Seitentabelleneinträge zu finden, die der gerade ausgelagerten Seite entsprechen, und führt die erforderlichen Aktualisierungen der Seitentabellen durch. Die Suche ist erschöpfend und sehr zeitaufwendig: Sie durchsucht jeden Speicherdeskriptor (des gesamten Systems) und überprüft seine Seitentabelleneinträge nacheinander.

Weitere Informationen finden Sie auf Seite 724 unter "Grundlegendes zum Linux-Kernel 3. Version".