Linux-E / A-Engpass bei Data Movern

Ich habe einen 24-Core-Computer mit 94,6 GB RAM, auf dem Ubuntu Server 10.04 ausgeführt wird. Die Box weist einen hohen Anteil an iowait auf, im Gegensatz zu einem anderen Server (4 Kerne), auf dem dieselben Arten und Mengen von Prozessen ausgeführt werden. Beide Computer sind über 4 FC-Karten mit dem VNX Raid-Dateiserver verbunden, der 24-Core-Computer und der andere über 2 Gigabit-Ethernet-Karten. Die 4-Core-Maschine übertrifft derzeit die 24-Core-Maschine, hat eine höhere CPU-Auslastung und einen geringeren iowait-Anteil.

In 9 Tagen Betriebszeit liegt% iowait im Durchschnitt bei 16% und liegt routinemäßig über 30%. Die CPU-Auslastung ist meistens sehr gering, etwa 5% (aufgrund des hohen iowait). Es gibt genügend freien Speicher.

Eine Sache, die ich nicht verstehe, ist, warum alle Daten scheinbar über das Gerät sdc und nicht direkt über die Data Mover laufen:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

Ein weiteres Puzzleteil ist, dass Aufgaben häufig in den unterbrechungsfreien Schlafmodus (oben) wechseln, wahrscheinlich auch aufgrund des io-Überfalls.

Worauf kann ich achten, um das Problem zu diagnostizieren? Warum gehen alle Daten durch / dev / sdc? Ist das normal?

AKTUALISIEREN:

Die Netzwerkverbindung und die VNX-Lese- / Schreibkapazität wurden als Engpässe ausgeschlossen. Mit den 4 verbundenen NICs (Round-Robin) können wir Geschwindigkeiten von 800 MB / s erreichen. Die Fibre-Channel-Karten werden noch nicht verwendet. Der VNX kann die E / A-Vorgänge gut verarbeiten (RAID6, 30 x 2 TB, 7,2 kRPM-Festplatten pro Pool in zwei Pools (insgesamt 60 Festplatten), ca. 60% gelesen).

Ignorieren Sie oben über dm und sdc, sie sind alle interne Festplatten und nicht Teil des Problems.

Wir glauben, dass das Problem möglicherweise bei den NFS-Mounts oder TCP liegt (wir haben 5 Mounts auf 5 Partitionen auf dem VNX), wissen aber nicht genau, was. Irgendein Rat?

Erstens, wenn Ihre CPUs (und verdammt! Das ist eine Menge 24) Daten schneller fressen als das, was den Datenspeicher bereitstellen kann, dann erhalten Sie iowait. In diesem Fall unterbricht der Kernel einen Prozess während eines blockierenden Io (ein zu langsamer Lesevorgang oder ein Synchronisierungsschreibvorgang).
Überprüfen Sie daher, ob der Speicher genügend Durchsatz für 24 Kerne bietet.

Nehmen wir beispielsweise an, Ihr Speicher kann einen Durchsatz von 500 MB / s liefern. Wenn Sie über eine 2-Gigabit-Ethernet-Leitung (Bond) verbunden sind, begrenzt das Netzwerk den maximalen Durchsatz bereits auf etwa 100 bis 180 MB / s. Wenn Ihr Prozess Daten mit einer Geschwindigkeit von 50 MB / s verarbeitet und Sie 4 Threads auf Ihrem 4-Kern-Computer ausführen: 4 x 50 MB / s = 200 MB / s verbraucht. Wenn das Netzwerk die 180 MB / s aufrechterhalten kann, haben Sie nicht viel Latenz und Ihre CPUs werden geladen. Das Netzwerk hier ist ein kleiner Engpass.
Wenn Sie dies auf 24 Kerne und 24 Threads skalieren, benötigen Sie 1200 MB / s. Selbst wenn Sie die Verkabelung ändern, um einen solchen Durchsatz zu ermöglichen, bietet Ihr Speichersystem nicht mehr als 500 MB / s. Dies wird zu einem Engpass.

Wenn es darum geht zu warten, können Engpässe überall sein. Nicht nur auf den physischen Ebenen, sondern auch in Software- und Kernel-Space-Puffern. Es hängt wirklich von den Nutzungsmustern ab. Da die Software-Engpässe jedoch viel schwerer zu identifizieren sind, ist es normalerweise vorzuziehen, den theoretischen Durchsatz auf der Hardware zu überprüfen, bevor die Software-Stapel untersucht werden.

Wie gesagt, ein iowait tritt auf, wenn ein Prozess einen Lesevorgang durchführt und es einige Zeit dauert, bis die Daten eintreffen, oder wenn ein Synchronisierungsschreibvorgang durchgeführt wird und die Bestätigung der Datenänderung ihre Zeit in Anspruch nimmt. Während eines Synchronisierungsschreibens tritt der Prozess in einen unterbrechungsfreien Ruhezustand ein, damit die Daten nicht beschädigt werden. Es gibt ein praktisches Tool, mit dem Sie feststellen können, durch welchen Aufruf ein Prozess hängen bleibt : latencytop. Es ist nicht das einzige seiner Art, aber Sie können es versuchen.

Hinweis: Zu Ihrer Information steht dm für Device Mapper und nicht für Data Mover.

Zuallererst, heiliges Inferno, das viel Eisen ist! :) :)

Da Ihr Setup sehr komplex klingt, glaube ich leider nicht, dass irgendjemand sofort ein "Da ist Ihr Problem!" Antwort, es sei denn, sie haben etwas mit einem extrem ähnlichen oder identischen Setup gemacht und sind auf dasselbe Problem gestoßen. Während dieser Text von SU als "Antwort" bezeichnet wird, sollten Sie ihn wahrscheinlich eher als "Vorschlag" betrachten. Und ich kann es nicht in die Kommentare aufnehmen, weil es zu viele Wörter sind. : S.

Ohne zu wissen, wie Ihre Hardware den Geräten zugeordnet ist, ist es schwer zu sagen, warum die E / A an einen Ort und nicht an einen anderen gehen. Wie haben Sie die Geräte montiert? Greifen Ihre Programme sd*direkt auf die Geräte zu oder sind alle Ihre Dateisysteme auf den dmGeräten gemountet und alle Dateizugriffe erfolgen dort?

Andere Dinge, nach denen ich fragen muss:

• Was ist das für ein RAID? Wenn Sie Paritätsbits mit RAID5 oder RAID6 berechnen, wird dies hoffentlich von der RAID-Server-Hardware erledigt. Wenn nicht, tun dies die Verarbeitungsserver. Dies ist suboptimal und kann zu E / A-Latenz führen, wenn in Software gemacht.

• Sie haben einen der Hauptunterschiede zwischen den beiden Servern in Ihrer Nachricht isoliert. Einer verwendet Faserkanal und einer Ethernet. Der Fibre Channel sollte eine bessere Latenz und Bandbreite bieten, aber vielleicht ist das auch ein Problem: Wenn er viel Durchsatz bietet, kann der RAID-Server selbst sehr ausgelastet sein ... und eine Überlastung führt dazu, dass Puffer / Caches voll werden erhöht die Latenz, was zu höheren E / A-Wartezeiten führt.

Es ist fast , als ob Sie möglicherweise einen Puffer aufblasen Problem mit Ihrem Disk - Arrays haben - Sie wissen? Hardware-RAID-Controller verfügen normalerweise über viel integrierten Cache, nicht wahr? Wenn also die E / A für die Medien in die Warteschlange gestellt werden und die Caches mit schmutzigen Seiten voll werden, ist das Ganze schließlich gesättigt (wenn der mechanische Speicher nicht mit der Last mithalten kann) und die Latenz segelt durch das Dach ... sicher Mit 24 Kernen + FC können Sie mehr Last erzeugen als mit 4 Kernen + GbE :) Überprüfen Sie den RAID-Server und stellen Sie fest, wie ausgelastet die Festplatten sind ... Viele der "E / A" sind möglicherweise nur Steuerpakete usw. I. Ich bin mir nicht sicher, wie FC funktioniert, aber wenn es etwas wie TCP ist, werden Sie Neuübertragungen sehen, wenn die Latenzen zu hoch sind.

Wenn Sie jemandem telefonisch eine Frage stellen und dieser einige Sekunden lang nicht antwortet, sagen Sie "Hallo?" - Netzwerkprotokolle (und FC ist nur ein Netzwerkprotokoll) machen dasselbe, nur in kürzerer Zeit. Aber natürlich das extra "Hallo?" ist im Zusammenhang mit Netzwerken teuer, da einer bereits überlasteten Pipe noch mehr Daten hinzugefügt werden.

Abschließend ein allgemeiner Tipp:

Messen Sie beim Debuggen von Latenz- / E / A-Warte- / Durchsatzproblemen immer . Überall messen. Messen Sie an der Leitung, messen Sie, was die Programme selbst tun, messen Sie am Verarbeitungsende, messen Sie auf dem RAID-Server usw. Betrachten Sie es nicht nur aus einer Perspektive - versuchen Sie, jede einzelne Komponente des Systems zu betrachten verantwortlich für die Verarbeitung, das Lesen oder das Schreiben von Daten in der Pipeline. Nehmen Sie eine Transaktion oder eine einzelne Arbeitseinheit auseinander und analysieren Sie genau den Pfad, den sie durch Ihre Hardware nimmt, und messen Sie an jeder einzelnen Komponente, ob es Engpässe oder Stellen gibt, an denen eine übermäßige Latenz usw. vorliegt. Ein Freund von mir nannte dies "Peeling" back the onion ", und ich habe den Ausdruck seitdem verwendet, um auf die Aufgabe des Debuggens eines Datenflusses zu verweisen.

Eine kleine Ergänzung. In diesem Fall sollten Sie sich Ihre Tuning- und E / A-Scheduler auf Blockebene ansehen. Ich bin mit Ubuntu nicht so vertraut, aber es gibt eine gute Anzahl von Speicherleistungsknöpfen, die optimiert werden müssen. Dies gilt definitiv für SAN-Speicher und Datenbanken.

• Schauen Sie sich den System-E / A-Planer an . CFQ ist die Standardeinstellung, aber Noop und Deadline sind gängige Optionen für Datenbank-Workloads.
• Unter diesem Link finden Sie einige andere Optimierungsparameter, die möglicherweise hilfreich sind.
• Sie erwähnen NFS und Blockspeicher. Wenn blockieren, welche Dateisysteme werden verwendet? Das Warten auf E / A klingt von hier aus wie eine Situation, in der das Schreiben blockiert wird. Sind Schreibbarrieren aktiviert? Montieren Sie Ihre Dateisysteme erneut mit nobarrier. ( Hinweis für Ubuntu )

Einige relevante Serverfehler-Links ...

Linux - echte Hardware-RAID-Controller-Optimierung (scsi und cciss)

Vielen Dank an alle für die Ideen und Anregungen. Das Problem hing mit einer Kombination aus nicht optimaler Ethernet-Bonding-Konfiguration und einem defekten E / A-Modul am VNX selbst zusammen. Die E / A-Rate liegt jetzt nahe an dem Punkt, an dem wir sie erwarten. Es ist interessant festzustellen, dass Tests zum Schreiben und Lesen von DD-Dateien und Benchmarks der Iozone dies nicht erkennen konnten und fast so schnell wie erwartet lesen und schreiben konnten.

Ich werde bald genug mit weiteren Informationen arbeiten, aber zuerst möchte ich sagen, dass Sie sich von der dm- * Ausgabe von iostat nicht verwirren lassen sollten. Device-Mapper ist genau wie md * (md0, md1 usw.) ein kerninternes Durchgangsgerät, sodass Sie sich wirklich nur um Ihre zugrunde liegenden Geräte kümmern. Alle Daten, die auf Ihre Festplatten übertragen werden, durchlaufen unterwegs dm / md, und die tatsächlichen Summen (Bytes, Sekunden usw.) sind korrekt, aber der Nutzen ist irreführend.

Das ist auch eine sehr große Menge an Speicher. So oft passieren lustige Dinge (ich selbst führe 2x64s und 2x96s aus), besonders wenn ein Prozess mehr als die Hälfte des RAMs beansprucht. Lesen Sie diesen Artikel für weitere Informationen . Der Artikel erwähnt MySQL, aber bitte beachten Sie, dass dies nicht der Fall istMySQL spezifisch. Für jeden Softwareprozess fallen Strafen für den Zugriffsspeicher eines anderen physischen Prozessors an - denken Sie, 48 GB gehören zu einem Prozess, 48 ​​GB zu einem anderen. Der Prozess kann nur zu einem Prozess gehören und um den anderen Prozessspeicher zu erreichen (nachdem seine eigenen 48 GB aufgebraucht sind), muss er entscheiden, entweder einen Teil seiner 48 im Swap zu speichern oder einen hohen Preis zu zahlen, um zum und vom zu gelangen das Gedächtnis eines anderen Prozesses. Der Artikel schlägt vor, einen Befehl numactl auszuführen, um die Software zu zwingen, nicht zu tauschen und stattdessen die Strafe zu zahlen. Ich persönlich habe massive Verbesserungen davon gesehen. Mit anderen Worten - prüfen Sie, ob einige Ihrer E / A-Vorgänge getauscht werden! Verwenden Sie dazu free -m (oder ähnliches). Wenn Sie über viel freien Speicher verfügen, aber nicht trivial viel Swapage (z. B. 10% plus), kann dies sehr wohl Ihr Problem sein.

Haben Sie aus Sicht des Speichers eine Möglichkeit, die SCSI-Latenz zu messen? Die Wartezeit des Betriebssystems umfasst eine Reihe von Dingen, die außerhalb der Kontrolle des Speichers liegen. Wenn ich jedoch in meine Speicherbox gehe und die E / A-Latenz bei 2 ms sehe, weiß ich, dass die scsi-Befehle unabhängig davon beantwortet werden, was der Server intern erhält schnell, und ich kann Speicher als Variable eliminieren.