Was steuert der Parameter vm.swappiness wirklich?

Gemäß der Kernel-Dokumentation:

This control is used to define how aggressive the kernel will swap
memory pages.  Higher values will increase aggressiveness, lower values
decrease the amount of swap.

Dies ist jedoch irgendwie vage. Ich versuche genau herauszufinden, was der Parameter letztendlich steuert. Ich weiß, es passt an, wie aggressiv der Kernel versucht, Seiten auszutauschen, aber welchen Entscheidungsprozess im Kernel-Code beeinflusst es?

Passt es an, seit wann auf eine Seite zugegriffen werden muss, bevor der Kernel sie auslagert? Wenn ja, was bedeutet der Standardwert von 60? Und wie viel ändert sich durch ein Inkrement / Dekrement von 1 (eine Formel wäre schön)?
Oder werden Seiten basierend auf ihrer Zugriffshäufigkeit ausgetauscht?
Oder etwas anderes?

Seit der Kernel-Version 2.6.28 verwendet Linux eine LRU-Strategie ( Split Least Recent Used ) zum Ersetzen von Seiten. Seiten mit einer Dateisystemquelle, wie z. B. Programmtext oder gemeinsam genutzte Bibliotheken, gehören zum Dateicache. Seiten ohne Dateisystem-Backup werden als anonyme Seiten bezeichnet und bestehen aus Laufzeitdaten wie dem für Anwendungen usw. reservierten Stapelspeicher. In der Regel ist es billiger, Seiten, die zum Dateicache gehören, aus dem Speicher zu entfernen (da diese bei Bedarf einfach von der Festplatte zurückgelesen werden können). . Da anonyme Seiten keine Dateisystemunterstützung haben, müssen sie so lange im Speicher verbleiben, wie sie von einem Programm benötigt werden, es sei denn, es gibt Auslagerungsspeicher, in dem sie gespeichert werden können.

Die vm.swappinessOption kommt in get_scan_count()defined in ins Spiel mm/vmscan.c. get_scan_count()Legt fest, wie aggressiv die anonymen und Datei-LRU-Listen gescannt werden sollen, wenn nach Seiten gesucht wird, die entfernt werden sollen. Der Wert jedes Falls wird durch den gleitenden Durchschnitt der kürzlich gedrehten und kürzlich gescannten Verhältnisse bestimmt, wobei neuere Verweise mehr Gewicht als ältere haben, um der sich ändernden Arbeitslast des Systems Rechnung zu tragen.

Das vm.swappinessist ein Modifikator, der die Balance zwischen Auslagern Datei Cache - Seiten für anonyme Seiten ändert. vm.swappinessist der Prioritätswert für anonyme Seiten, der standardmäßig auf 60 festgelegt ist . Der Dateicache erhält den Prioritätswert 200, von dem der vm.swappinessModifikator abgezogen wird ( file_prio=200-anon_prio). Dies bedeutet, dass die Prioritätsgewichte standardmäßig moderat zugunsten anonymer Seiten ( anon_prio=60, file_prio=200-60=140) stehen. Befindet sich das System jedoch in der Nähe eines Speichermangels , werden die anonymen und die Datei-LRU-Listen gleichermaßen gescannt, sofern sie nicht vm.swappinessauf Null gesetzt sind.

Wenn vm.swappinessauf 100 gesetzt ist, sind die Prioritäten gleich ( anon_prio=100, file_prio=200-100=100). Das Setzen vm.swappinessauf Null verhindert, dass der Kernel anonyme Seiten zugunsten von Seiten aus dem Dateicache entfernt.

Es gibt eine Formel, mit der berechnet wird, welche Seite ausgetauscht wird. In vmscan.ckönnen Sie diesen Algorithmus sehen:

Swap-Tendenz = mapped_ratio / 2 + Distress + vm_swappiness

Hier können Sie sehen, dass swappiness eine Skala ist, die in einigen Algorithmen hinzugefügt wird, und Sie können mit diesem Parameter steuern, wie sich der Kernel verhält, wenn er austauschen muss. Sie können es als Prozentsatz der Wahrscheinlichkeit berechnen, dass eine Seite mit inaktivem Speicher ausgetauscht wird. Wenn Sie swappiness auf 100 setzen, gibt es keine Wahrscheinlichkeit, aber eine Garantie, dass es swappt. Wenn Sie es auf 0 setzen, wird der Kernel versuchen, überhaupt nicht zu swappen, solange er etwas leeren Speicher hat.

Es wurde gesagt (ich denke Norman 1986), dass oft die "TÜR SCHLIESSEN" -Taste in einem Aufzug entweder kaputt ist oder nie mit irgendetwas in Verbindung stand. Dies macht die Ersatzsteuerung nicht zu einer Möglichkeit, den Aufzug zu manipulieren, sondern den überhasteten Fahrer zu beruhigen.

In ähnlicher Weise hat Swappiness einen Effekt, der nichts mit der genau definierten deterministischen Kontrolle eines Kernel-Prädikats zu tun hat. Wie von @neon_overlord auf askubuntu.com vermerkt

Weil die meisten glauben, dass Tauschen = schlecht ist und dass das System tauschen wird, wenn es nicht wirklich benötigt wird, wenn Sie das Tauschen nicht reduzieren. Keines davon ist wirklich wahr. Leute assoziieren das Tauschen mit Zeiten, in denen ihr System festgefahren ist - es ist jedoch meistens ein Tauschen, weil das System festgefahren ist und nicht umgekehrt. Es ist wahr, dass es bestimmte Zeiten gibt, in denen das Austauschen einen spürbaren Nachteil haben kann, aber die Reduzierung des Austauschs für diesen Fall kann die Gesamtsystemleistung oder -stabilität auf andere Weise verringern, die später spürbar werden können.

Also, was steuert es wirklich ? Eine gültige Antwort - zusätzlich zu den bereits gegebenen guten Antworten - ist, dass Sie damit Ihre Erwartung ändern, dass Sie mehr Kontrolle über Ihr System haben und dass Sie durch Drehen eines Knopfes diese Kontrolle auf sinnvolle Weise ausüben können.