Drbd sock sendmsg time expired

Aus Wiki Thomas-Krenn.AG
Wechseln zu: Navigation, Suche

Problem

Unter sehr hoher Last (u.a. auch beim VE Checkpointing) kann es beim Thomas Krenn 1HE Cluster zu einem Aussetzen von DRBD kommen. Der Grund dafür ist, dass das Versenden von Datenpaketen am node1 wegen Speichermangel blockiert werden kann. Dies passiert unter hoher Memory-Pressure auf der Seite des aktiven Knotens. Es geht um ein grundsätzliches Linux Problem, Netzwerk-IO im Block-IO Pfad.

Die Fehlermeldung kann wie folgt aussehen, wobei der Wert "ko" laufend heruntergezählt wird:

Apr 27 15:46:45 node2 kernel: drbd0: [kjournald/10662] sock_sendmsg time expired, ko = 4294967295
Apr 27 15:46:48 node2 kernel: drbd0: [kjournald/10662] sock_sendmsg time expired, ko = 4294967294
Apr 27 15:46:51 node2 kernel: drbd0: [kjournald/10662] sock_sendmsg time expired, ko = 4294967293
Apr 27 15:46:54 node2 kernel: drbd0: [kjournald/10662] sock_sendmsg time expired, ko = 4294967292
Apr 27 15:46:57 node2 kernel: drbd0: [kjournald/10662] sock_sendmsg time expired, ko = 4294967291

Der Wert "ko" ist der KO Counter von DRBD, nach dessen Ablauf die DRBD Verbindung zum zweiten Knoten getrennt wird. Per Default ist der "ko-count" Wert in drbd.conf nicht gesetzt, d.h. es erfolgt keine automatische Trennung der DRBD Verbindung.

Lösung

Das Problem tritt vor allem beim Einsatz von DRBD 0.7.x auf. Beim Einsatz von DRBD 8.x ist das Problem sehr unwahrscheinlich und es ist uns kein Fall bekannt.

Folgende Optimierungen werden empfohlen:

# increase "minimum" (and default) tcp buffer
# to increase the chance to make progress in IO via tcp,
# even under memory pressure.
net.ipv4.tcp_rmem = 131072  131072  10485760
net.ipv4.tcp_wmem = 131072  131072  10485760

# reduce watermark levels to start background (and foreground)
# writeback early. reduces the chance of resource starvation.
vm.dirty_ratio = 10
vm.dirty_background_ratio = 4

Wenn der Fehler nur selten auftritt, kann ein setzen des Werts "ko-count" in drbd.conf helfen. In diesem Fall wird die DRBD Verbindung getrennt und man muss die Verbindung manuell wiederherstellen, dafür kommt es zu keinem Hängen des Systems.

Wenn diese Optimierungen alle nicht helfen, muss versucht werden die Last am 1HE Cluster zu reduzieren und in letzter Konsequenz auf ein System mit einer DRBD Version > 0.7.x umgestiegen werden.


Share/Save/Bookmark  Feedback zu diesem Artikel geben
Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Kategorien
Drucken/exportieren
Werkzeuge