Frage :Was sind schmutzige Seiten und wozu dienen sie?
Immer wenn ein Anwendungs-/Datenbankprozess eine virtuelle Seite in den physischen Speicher einfügen muss, aber keine freien physischen Seiten übrig sind, muss das Betriebssystem verbleibende alte Seiten löschen.
Wenn die alte Seite überhaupt nicht geschrieben wurde, muss diese nicht gespeichert werden, sondern kann einfach aus der Datendatei wiederhergestellt werden. Wenn die alte Seite jedoch bereits geändert wurde, muss sie irgendwo aufbewahrt werden, damit die Anwendung/Datenbank später wiederverwendet werden kann – dies wird als schmutzige Seite bezeichnet.
Das Betriebssystem speichert solche schmutzigen Seiten in Auslagerungsdateien (damit sie aus dem physischen Speicher entfernt werden können, damit eine weitere "neue" Seite im physischen Speicher gespeichert werden kann). Wenn viele Daten aus dem Seitencache in den schmutzigen Seitenbereich entfernt werden, kann dies zu erheblichen IO führen Engpass, wenn sich das tatsächliche Auslagerungsgerät auf der lokalen Festplatte ( sda ) befindet, und darüber hinaus weitere Probleme verursachen, wenn die lokale Festplatte auch von der lokalen Root-Festplatte (OS) verwendet wird.
Der Seiten-Cache in Linux ist nur ein Festplatten-Cache, der dem Betriebssystem zusätzliche Leistung bringt, was bei intensiven hohen Lese-/Schreibvorgängen auf Dateien hilft.
Als „Unter“-Produkt des Seiten-Cache ist die Dirty Page – was im obigen Beispielfall erklärt wurde. Schmutzige Seiten können auch beobachtet werden, wenn die Anwendung in eine Datei schreibt oder eine Datei erstellt – der erste Schreibvorgang findet im Seiten-Cache-Bereich statt – daher kann das Erstellen einer Datei mit einer Größe von 10 MB sehr schnell sein:
# dd if=/dev/zero of=testfile.txt bs=1M count=100 10+0 records in 10+0 records out 10485760 bytes (100 MB) copied, 0,1121043 s, 866 MB/s
Das liegt daran, dass diese Datei im Speicherbereich und nicht auf der tatsächlichen Festplatte erstellt wird – daher ist die Reaktionszeit sehr schnell. Unter dem Betriebssystem wird so etwas in /proc/meminfo und darüber hinaus in ‘Dirty:
vermerktBevor der obige Befehl ausgeführt wird – notieren Sie sich die /proc/meminfo und die ‘Dirty’-Zeile:
# more /proc/meminfo | grep -i dirty Dirty: 96 kB
Nachdem der Befehl ausgeführt wurde:
# more /proc/meminfo | grep -i dirty Dirty: 102516 kB
In regelmäßigen Abständen initiiert das Betriebssystem oder die Anwendung/Datenbank die Synchronisierung, wodurch die tatsächliche testfile.txt auf die Festplatte geschrieben wird:
# more /proc/meminfo | grep -i dirty Dirty: 76 kB
Jetzt erlaubt beispielsweise die Oracle-Datenbank solche Schreibvorgänge in den Speicherbereich nicht, als ob das Betriebssystem abstürzt oder wenn SAN LUn ausfällt – Daten werden kompromittiert. Aus diesem Grund erfordert Oracle Database, dass Daten „synchron“ sind, daher müssen alle Schreibvorgänge vom Backend wie Disk/Lun bestätigt werden, bevor die Datenbank weitere Schreibanforderungen auslöst.
Normalerweise löschen Datenbanken/Anwendungen regelmäßig den Cache, daher werden schmutzige Seiten in kleinen Blöcken auf die Festplatte geschrieben. In einigen Fällen können schmutzige Seiten an Größe zunehmen, da die Anwendung/Datenbank den Seiten-Cache-Mechanismus möglicherweise nicht richtig konfiguriert hat.
So können schmutzige Seiten in Auslagerungsdateien ( Auslagerungsbereich ), aber auch in spezielle Bereiche auf der Festplatte ( LUN / Dateisystem ) schreiben. Wenn wir beispielsweise eine Auslagerungsdatei mit mehr als 100 MB erstellen, die später aus der Auslagerungsdatei wiederverwendet wird, können wir unnötige E / A-Probleme auf dem Auslagerungsgerät verursachen. Unternehmenssysteme speichern Auslagerungsdateien und Auslagerungsbereich auf dem Betriebssystem unter Solid State Drives ( SSD ) oder dedizierter LUN, daher wird die Leistung der lokalen Festplatte nicht beeinträchtigt (da normalerweise die Auslagerungsregion auf der lokalen Festplatte erstellt wird)
In einigen Fällen kann die Anwendung/Datenbank intern Probleme haben und fehlerhafte Seiten werden als Auslagerungsdateien geschrieben, aber nie wiederverwendet. Dies führt dazu, dass der Auslagerungsbereich wächst und unnötige E / A auf der lokalen Festplatte verursacht und zu einer großen Auslagerungsnutzung unter dem Betriebssystem führt.
Um herauszufinden, in welcher Phase das Betriebssystem versucht, schmutzige Seiten zurück auf die Festplattenebene zu kopieren, lesen Sie bitte die offizielle Kernel-Dokumentation zum virtuellen Speicher hier und suchen Sie nach Einstellungen wie:
vm.dirty_background_ratio vm.dirty_ratio vm.swappiness
und
dirty_background_ratio dirty_ratio dirty_background_bytes dirty_expire_centisecs
Die obigen Einstellungen müssen pro Datenbank-/Anwendungsanforderung angepasst werden, da das Betriebssystem keine „Best Practice“-Einstellung für sie hat – sie werden pro DB/APP-Ladung/Konfiguration angepasst.
Wann immer eine Anwendung/Datenbank Speicherseiten fordert, die im physischen Speicher frei sein müssen – das Betriebssystem neigt dazu, alles im Seitencache zu halten – muss das Betriebssystem daher einige der Seiten neu zuweisen und sie als schmutzig markieren. Dieser Prozess funktioniert gut, wenn das Anwendungs-/Datenbankende richtig abgestimmt und skaliert ist – andernfalls wird es zu einer wirklich aggressiven Auslagerung kommen – da das Betriebssystem alle schmutzigen Seiten zurück auf die Auslagerungsfestplatte schreiben muss – dies kann über die vm.swappiness-Einstellung gesteuert werden.
Wenn die Anwendung/Datenbank eine zustimmende Auslagerung durchführt, kann dies zu ernsthaften E/A-Schreibvorgängen auf dem Auslagerungsgerät und zu ernsthaften Systemstillständen führen – stellen Sie immer sicher, dass die Anwendung/Datenbanken in Bezug auf die Speicherverwaltung richtig konfiguriert sind.
Wie bereits erläutert, werden nicht alle Seiten als fehlerhaft markiert – die meisten unbenutzten Seiten werden verworfen und nicht als fehlerhaft markiert (es hängt alles davon ab, ob bereits zugewiesene Seiten geändert wurden oder nicht)
Um zu überprüfen, welche PIDs den Swap-Bereich verwenden, kann der folgende Befehl verwendet werden:
for file in /proc/*/status
do
awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file
done | sort -k 2 -n -r Das Freigeben von „verbrauchtem“ Auslagerungsspeicher ist wirklich begrenzt. Normalerweise wird der Auslagerungsspeicher zurückgefordert, wenn PID ordnungsgemäß beendet wird oder einfach heruntergefahren wird, aber PID beendet oder wenn es abnormal endet, wie Segfault, kann der Auslagerungsspeicher immer noch verbraucht bleiben. Eine andere Option ist ein Neustart, da das Ausführen von Swapoff- und Swapon-Befehlen ernsthafte Probleme verursachen oder sogar zu einer Systempanik führen kann.