Frage Warum sollte die Zeit für ein DM-Multipath-Gerät höher sein als das zu Grunde liegende Gerät?


Wir haben einen CentOS 6.4-basierten Server, der an Hitachi HNAS 3080-Speicher angeschlossen ist, und beobachteten, wie der Kernel das Dateisystem im schreibgeschützten Modus remounted:

16. Mai 07.31.03 GNS3-SRV-CMP-001-Kernel: [1259725.675814] EXT3-fs (dm-1): Fehler: remounting Dateisystem schreibgeschützt

Dies ist passiert, nachdem mehrere E / A-Fehler und alle Pfade zu dem Gerät gemeldet wurden, die angeblich abstürzen:

16. Mai 07.31.03 GNS3-SRV-CMP-001 multipathd: mpatha: verbleibende aktive Pfade: 0

Ich habe sar Protokolle angeschaut und kann einige sehr große (2 Sekunden) Wartezeiten sehen:

07:40:00       dev8-0     17.91    112.04     98.03     11.73      0.00      0.20      0.07      0.12
07:40:00      dev8-16      0.23      1.85      0.00      8.00      0.00      3.71      3.71      0.09
07:40:00      dev8-32     91.50   8338.76   5292.93    148.98      8.38     91.60      9.76     89.35
07:40:00     dev252-0     91.27   8336.91   5292.93    149.34     17.79    194.88      9.79     89.38
07:40:00     dev252-1    674.80   8168.16   5292.93     19.95   1473.53   2183.60      1.32     88.98

Die Zeit zwischen 07: 30: 00-07: 40: 00 findet statt, wenn das Dateisystem schreibgeschützt ist. Eine wiederholte Beobachtung ist jedoch selbst unter normalen Bedingungen, dass die erwartete Zeit für die zugrunde liegenden Geräte viel niedriger ist als die der Mehrwegevorrichtung. Zum Beispiel:

00:00:00          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
00:10:00       dev8-0     19.27    129.41     78.61     10.80      0.01      0.27      0.16      0.32
00:10:00      dev8-16      0.23      1.80      0.00      8.00      0.00      0.86      0.84      0.02
00:10:00      dev8-32     94.88  10285.16   3363.48    143.86      3.39     35.76      6.83     64.82
00:10:00     dev252-0     94.65  10283.34   3363.48    144.18      3.64     38.47      6.86     64.89
00:10:00     dev252-1    435.06  10087.12   3363.48     30.92    118.42    272.21      1.47     64.12

dev8-0 ist die lokale Festplatte, dev8-16 (/dev/sdb) und dev8-32 (/dev/sdc) sind die zugrunde liegenden für dev252-0 (/dev/mapper/mpatha). dev252-1 (/dev/mapper/mpathap1) ist eine einzelne Partition, die das gesamte Multipath-Gerät überspannt. Hier wird ausgegeben von multipath -ll:

mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sdb 8:16 active ready running

Warum sollte die Zeit darauf warten? /dev/mapper/mpathap1 sei so viel höher als das von /dev/mapper/mpatha oder auch /dev/sdb oder /dev/sdc?


20
2018-05-27 10:42


Ursprung


Es scheint bemerkenswert zu sein, dass auf dem Weg dorthin offensichtlich eine Menge an Request-Merging passiert /dev/mapper/mpathap1 zu /dev/mapper/mpatha. Dies ist auch die Schicht, wo die meisten await Zeit scheint hinzugefügt zu werden. Können Sie überprüfen, welche Aufzüge in verwendet werden? /sys/block/mpathap1/queue/scheduler und /sys/block/mpatha/queue/scheduler, möglicherweise umschalten zu deadline oder noop zum Vergleich? - the-wabbit
Das E / A-Planer zum mpatha (/sys/block/dm-0/queue/scheduler) ist noop und das für mpathap1 (/sys/block/dm-1/queue/scheduler) ist none. - pdp
Ich vermute stark, dass der Queuing / Merging-Algorithmus des Schedulers für die Verzögerung verantwortlich ist. Ich würde cfq der zugrunde liegenden Geräte für Noop oder Deadline austauschen, nur um zu sehen, ob es etwas ändert. Dies wird jedoch wahrscheinlich nicht mit Ihrem Problem mit allen Pfaden zusammenhängen. - the-wabbit
FWIW, ich habe die gleiche Art von Verhalten auf anderen Arten von Gerät Mapper-Geräte beobachtet - speziell mit NSS-Pools. Merge-fähige Schreibvorgänge haben eine höhere Wartezeit (und längere Warteschlangen) auf der dm Gerät als auf dem zugrunde liegenden physischen Gerät, während Leseanforderungen und -schreibvorgänge, ohne dass eine Zusammenführung erfolgt, im Wesentlichen nicht betroffen sind. Ich weiß noch nicht, ob dies einfach ein Präsentationsfehler ist, aufgrund der Art und Weise, wie erwartet wird, oder aufgrund der Art des Warteschlangen- / Mischalgorithmus tatsächlich verlängerte Reaktionszeiten. - the-wabbit
Einer der Systemtap IO-Skripte könnte Ihnen möglicherweise zusätzliche Einblicke in das, was vor sich geht, geben. io_submit.stp, ioblktime.stp und biolatency-nd.stp könnten gute Startpunkte sein. - Kassandry


Antworten:


Als Benutzer schlägt the-wabbit vor, es gibt Anfrage-Verschmelzung, die weitergeht. Sie können sehen, dass in der Spalte avgrq-sz, die durchschnittliche Größe der Anfrage - die einen deutlichen Anstieg zeigt.

Jetzt warten Sie auf die Zeit in der Warteschlange und die Zeit, die Sie für die Bearbeitung dieser Anfragen benötigen. Wenn eine kleine Anfrage, nennen wir sie "x", mit einigen anderen Anfragen zusammengeführt wird (y und z, die nach x ausgegeben werden), dann wird x dies tun

  • Warte in der Warteschlange, um mit y zusammengeführt zu werden
  • Warte in der Warteschlange, um mit z zusammengeführt zu werden
  • Warten Sie, bis (x, y, z) abgeschlossen ist

Dies wird sich natürlich negativ auf die Erwartungsstatistik auswirken, vor allem weil die Art und Weise berechnet wird, wie man auf sie wartet, ohne tatsächlich ein Problem zu bedeuten.

Sehen wir uns nun / dev / sdb (dev8-16) an. Wussten Sie, dass Sie diesen Weg nicht benutzen? Sie haben zwei Prioritätsgruppen in Ihrer Multipath-Konfiguration, eine davon ist

Status = aktiviert

und weiter ist

Status = aktiv

Du hast wahrscheinlich

path_grouping_policy Failover

in Ihrer Konfiguration (das ist die Standardeinstellung).

Wenn Sie die E / A-Fehler verhindern möchten, falls beide Pfade nicht aktiv sind, können Sie versuchen:

        Eigenschaften "1 queue_if_no_path"
 in Ihrer multipath.conf

Jetzt bleibt die eigentliche Frage, warum gehen beide Wege nach unten?


2
2018-01-21 20:50