Linux-Seitencache verlangsamt die IO auf einem Dual-CPU-Server mit 64 GB RAM

Question

Ich habe ein massives Problem mit dem Linux-Seitencache, der die IO verlangsamt. Wenn ich beispielsweise eine LVM-Partition mit dd kopiere, speichert Linux die Daten in den Puffern oder Caches (free –m). Das ist nicht das Problem, aber nachdem der Puffer einen bestimmten Wert erreicht hat, stoppt der Kopiervorgang und verlangsamt sich auf einige MBit/s oder sogar KB. Ich habe viele Tests mit dem Schreiben auf die Festplatte oder /dev/null durchgeführt, das Problem hat nichts mit dem Quelllaufwerk oder dem Ziel zu tun.

Im Detail:

• Es gibt zwei nahezu identische Server. Auf beiden läuft CentOS 6.5 mit demselben Kernel. Sie haben dieselben Festplatten, dasselbe Setup, dieselbe sonstige Hardware, sind in jeder Hinsicht gleich. Der einzige Unterschied besteht darin, dass ein Server 2 CPUs und 64 GB RAM hat und der andere 1 CPU und 32 GB RAM.
• Hier auch noch eine Abbildung des folgenden Kopiervorgangs:https://i.stack.imgur.com/tYlym.jpg
• Hier eine neue Version, ebenfalls mit Meminfo. Das Meminfo stammt aus einem anderen Lauf, daher sind die Werte nicht identisch, aber es ist das völlig gleiche Verhalten:https://i.stack.imgur.com/4SIJG.jpg
• Starten Sie den Kopiervorgang mit dd oder einem anderen Dateisystem-Kopierprogramm.
• Puffer oder Cache beginnen sich zu füllen. Alles ist in Ordnung.
• Puffer oder Cache erreicht eine maximale Zahl (auf einem 64 GB RAM-Server ein Wert wie 32 GB oder 17 GB; auf einem 32 GB RAM-Server der gesamte freie Speicher)
• Auf einem Server mit 64 GB RAM stoppt der Kopiervorgang jetzt oder ist auf wenige MBit/s begrenzt. Auf einem Server mit 32 GB RAM ist alles in Ordnung.
• Auf einem 64GB RAM Server kann ich das Problem für einen kurzen Moment lösen, indem ich den Cache mit "sync; echo 3 > /proc/sys/vm/drop_caches" forciere. Aber natürlich beginnt der Puffer sofort wieder zu wachsen und das Problem tritt erneut auf.

Abschluss:

Das Problem hat entweder etwas mit der zweiten CPU oder mit der Gesamtspeichermenge zu tun. Ich habe das „Gefühl“, dass das Problem sein könnte, dass jede CPU ihren eigenen 32 GB RAM hat und der Kopiervorgang nur auf der CPU läuft. Der Kopiervorgang vergrößert also schließlich den Puffer/Cache auf fast 32 GB oder auf den nicht verwendeten Speicher der anderen CPU und dann denkt sich Linux, hey, es ist noch Speicher da, also können wir den Puffer weiter vergrößern, aber die Hardware darunter kann nicht auf den Speicher zugreifen, oder so etwas in der Art.

Hat jemand eine Idee oder Lösung?Natürlich kann ich dd mit dem Direktflag verwenden, aber das löst das Problem nicht, da auch ein externer Zugriff über Samba usw. möglich ist.

BEARBEITEN1:

Hier auch die /proc/zoneinfo vom 64GB RAM Server: 1.http://pastebin.com/uSnpQbeD(bevor dd startet) 2.http://pastebin.com/18YVTfdb(wenn dd nicht mehr funktioniert)

EDIT2:

• VM-Einstellungen:http://pastebin.com/U9E9KkFS
• /proc/sys/vm/zone_reclaim_mode war auf dem 32 GB RAM Server 0 und auf dem 64 GB RAM Server 1. Ich verändere diese Werte nie. Das Installationsprogramm hat sie eingestellt. Ich habe sie vorübergehend auf 0 geändert und den Test erneut versucht. Jetzt wird der gesamte Speicher für Puffer und Cache verwendet. Es sieht also großartig aus und wie der andere Server. Aber dann beginnt es sofort mit voller Geschwindigkeit zu swappen ... Ich habe die Swapiness auf 0 gesetzt. Das hilft, aber es swappt immer noch ein paar MB pro Sekunde. Und es vergrößert die Puffer jede Sekunde. Es swappt also nicht den Puffer, sondern den Speicher der VMs, um mehr Speicher zu bekommen, um die Puffer zu vergrößern ... verrückt. Aber vielleicht ist das normal!?

EDIT3:

/proc/buddyinfo und numactl --hardware: http://pastebin.com/0PmXxxin

ENDERGEBNIS

• /proc/sys/vm/zone_reclaim_mode ist technisch sicherlich der richtige Weg, aber die Maschine funktionierte danach nicht mehr richtig. Beispiel: Wenn ich eine Festplatte kopiere, verwendet Linux jetzt 100 % des freien Speichers zum Puffern (nicht wie vorher nur XGB und dann aufhören). Aber in der Sekunde, in der der letzte freie Speicher zum Puffern verwendet wurde, beginnt Linux mit dem Auslagern des VM-Speichers und erhöht die Gesamtmenge an Puffer und Caches. Der Auslagerungsspeicher wird in meinem System normalerweise nicht benötigt, daher befindet sich der Auslagerungsspeicher auf derselben Festplatte wie einige VMs. Wenn ich also ein Backup dieser VMs mache, schreibt Linux den Auslagerungsspeicher zur selben Zeit, in der ich für das Backup von der Festplatte lese. Es ist also schlecht, die VMs auszutauschen, aber es ist noch schlimmer, dass Linux meine Backup-Lesegeschwindigkeit zerstört... Das Setzen von /proc/sys/vm/zone_reclaim_mode auf 0 löst also nicht das ganze Problem... derzeit führe ich auf einem Bildschirm ein Skript aus, das alle 10 Sekunden den Cache synchronisiert und leert... nicht schön, aber funktioniert für mich viel besser. Ich habe keinen Webserver oder normalen Dateiserver auf dem System. Ich führe nur VMs aus, mache Backups und speichere Backups über Samba. Mir gefällt die Lösung nicht.

Answer 1

Das von Ihnen beobachtete Verhalten ist auf die Art und Weise zurückzuführen, wie Linux auf einem NUMA-System Speicher zuweist.

Ich gehe davon aus (ohne es zu wissen), dass das 32-GB-System kein NUMA ist oder nicht NUMA genug, als dass es Linux interessieren würde.

Das Verhalten im Umgang mit Numa wird durch die /proc/sys/vm/zone_reclaim_modeOption bestimmt. Standardmäßig erkennt Linux, ob Sie ein Numa-System verwenden, und ändert die Reclaim-Flags, wenn es der Meinung ist, dass dies zu einer besseren Leistung führt.

Der Speicher ist in Zonen aufgeteilt. Im Numa-System gibt es eine Zone für den ersten CPU-Sockel und eine Zone für den zweiten. Diese werden als node0und angezeigt node1. Sie können sie sehen, wenn Sie cat verwenden /proc/buddyinfo.

Wenn der Zonenrückgewinnungsmodus auf 1 eingestellt ist, führt die Zuweisung vom ersten CPU-Sockel dazu, dass die Rückgewinnung in der Speicherzone erfolgt, die dieser CPU zugeordnet ist. Dies liegt daran, dass die Rückgewinnung von einem lokalen NUMA-Knoten aus leistungstechnischer Sicht effizienter ist. Rückgewinnung bedeutet in diesem Sinne das Löschen von Seiten, z. B. das Leeren des Caches oder das Auslagern von Inhalten auf diesem Knoten.

Wenn Sie den Wert auf 0 setzen, werden keine Rückforderungen vorgenommen, wenn die Zone voll ist. Stattdessen wird der Speicher den fremden Numa-Zonen zugewiesen. Dies geht auf Kosten einer kurzen Sperrung der anderen CPU, um exklusiven Zugriff auf diese Speicherzone zu erhalten.

Aber dann beginnt es sofort mit dem Swapping! Nach ein paar Sekunden: Mem: 66004536k gesamt, 65733796k genutzt, 270740k frei, 34250384k Puffer Swap: 10239992k gesamt, 1178820k genutzt, 9061172k frei, 91388k zwischengespeichert

Das Auslagerungsverhalten und der Zeitpunkt der Auslagerung werden von mehreren Faktoren bestimmt. Einer davon ist, wie aktiv die Seiten sind, die den Anwendungen zugewiesen wurden. Wenn sie nicht sehr aktiv sind, werden sie zugunsten der arbeitsintensiveren Arbeit im Cache ausgelagert. Ich gehe davon aus, dass die Seiten in Ihren VMs nicht sehr oft aktiviert werden.