☰

Auf einem System mit 64 GB Speicher ist der Linux-Puffer beim Kopieren mit dd nach dev null voll und die E/A wird bis zum manuellen drop_caches gestoppt

tag-icon • tag-icon linux performance dd pagefile disk-cache
Auf einem System mit 64 GB Speicher ist der Linux-Puffer beim Kopieren mit dd nach dev null voll und die E/A wird bis zum manuellen drop_caches gestoppt

Ich betreibe einen Server mit Linux-Software RAID 10. Es handelt sich um ein Dual-CPU-System mit 64 GB RAM. 2x16 GB DIMMs für jede der CPUs. Ich möchte DD zum Sichern von virtuellen KVM-Maschinen verwenden und stoße dabei auf ein ernstes E/A-Problem. Zuerst dachte ich, es hänge mit dem RAID zusammen, aber es ist ein Problem mit der Linux-Speicherverwaltung. Hier ist ein Beispiel:

  1. Der Speicher ist in Ordnung: https://i.stack.imgur.com/NbL60.jpg
  2. Ich starte dd: https://i.stack.imgur.com/kEPN2.jpg
  3. Sie sehen auch, dass nmon den Festplattenzugriff anzeigt: https://i.stack.imgur.com/Njcf5.jpg
  4. Nach einer Weile sind die "Puffer" groß und der Kopiervorgang stoppt https://i.stack.imgur.com/HCefI.jpg
  5. Hier ist Meminfo: https://i.stack.imgur.com/KR0CE.jpg
  6. Hier die dd-Ausgabe: https://i.stack.imgur.com/BHjnR.jpg
  7. Ich kann das Problem vorübergehend manuell beheben und das Löschen des Caches erzwingen: „sync; echo 3 > /proc/sys/vm/drop_caches“
  8. Der Anruf dauert einige Sekunden und unmittelbar danach erreicht die DD-Geschwindigkeit das normale Niveau. Natürlich kann ich jede Minute einen Cronjob oder ähnliches ausführen, aber das ist keine echte Lösung. https://i.stack.imgur.com/zIDRz.jpg https://i.stack.imgur.com/fO8NV.jpg

Hat jemand eine Lösung oder einen Konfigurationstipp? Hier ist auch mein Sysctl, aber alle Werte sind CentOS-Standardwerte: https://i.stack.imgur.com/ZQBNG.jpg

Bearbeiten1

Ich mache einen weiteren Test und mache einen dd auf die Festplatte statt /dev/null. Diesmal auch in einem Befehl ohne pv. Es ist also nur ein Prozess.dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

  1. Es beginnt mit Lesen ohne Schreiben (Ziel ist nicht auf derselben Festplatte) https://i.stack.imgur.com/jJg5x.jpg
  2. Nach einer Weile beginnt das Schreiben und das Lesen wird langsamer https://i.stack.imgur.com/lcgW6.jpg
  3. Danach kommt nur noch die Zeit des Schreibens: https://i.stack.imgur.com/5FhG4.jpg
  4. Jetzt beginnt das Hauptproblem. Der Kopiervorgang verlangsamt sich auf unter 1 MBit/s und nichts passiert: https://i.stack.imgur.com/YfCXc.jpg
  5. Der DD-Prozess benötigt jetzt 100 % CPU-Zeit (1 Kern) https://i.stack.imgur.com/IZn1N.jpg
  6. Und wieder kann ich das Problem manuell vorübergehend beheben und den Cache löschen: sync; echo 3 > /proc/sys/vm/drop_caches. Danach startet das gleiche Spiel erneut ...

Bearbeiten

Für den lokalen DD kann ich mit den Parametern iflag=direct und oflag=direct umgehen. Das ist aber keine universelle Lösung, da es auch andere Dateizugriffe gibt, wie das Kopieren von Dateien auf die lokalen Samba-Freigaben von einer VM aus und da kann ich solche Parameter nicht verwenden. Es muss eine Anpassung der Systemdatei-Cache-Regeln vorgenommen werden, denn es kann nicht normal sein, dass man große Dateien nicht ohne solche Probleme kopieren kann.

Antwort1

Nur eine wilde Vermutung. Ihr Problem könnte ein großes Flushing von schmutzigen Seiten sein. Versuchen Sie, /etc/sysctl.conf wie folgt einzurichten:

# vm.dirty_background_ratio contains 10, which is a percentage of total system memory, the 
# number of pages at which the pdflush background writeback daemon will start writing out 
# dirty data. However, for fast RAID based disk system this may cause large flushes of dirty
# memory pages. If you increase this value from 10 to 20 (a large value) will result into 
# less frequent flushes:
vm.dirty_background_ratio = 1

# The value 40 is a percentage of total system memory, the number of pages at which a process
# which is generating disk writes will itself start writing out dirty data. This is nothing
# but the ratio at which dirty pages created by application disk writes will be flushed out
# to disk. A value of 40 mean that data will be written into system memory until the file 
# system cache has a size of 40% of the server's RAM. So if you've 12GB ram, data will be
# written into system memory until the file system cache has a size of 4.8G. You change the
# dirty ratio as follows:
vm.dirty_ratio = 1

Führen Sie anschließend sysctl -peinen Neuladevorgang durch und löschen Sie den Cache erneut ( echo 3 > /proc/sys/vm/drop_caches).

verwandte Informationen