Warum ist die Wartezeit für DM-Multipath-Geräte länger als für zugrunde liegende Geräte?

Wir haben einen CentOS 6.4-basierten Server an den Hitachi HNAS 3080-Speicher angeschlossen und festgestellt, dass der Kernel das Dateisystem im schreibgeschützten Modus erneut einbindet:

16. Mai 07:31:03 GNS3-SRV-CMP-001-Kernel: [1259725.675814] EXT3-fs (dm-1): Fehler: Remount des Dateisystems schreibgeschützt

Dies geschah nach mehreren E / A-Fehlern und dem Ausfall aller Pfade zum Gerät:

16. Mai 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: verbleibende aktive Pfade: 0

Ich habe mir Sar-Protokolle angesehen und sehe einige sehr große (2 Sekunden) Wartezeiten:

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 Dauer zwischen 07: 30: 00-07: 40: 00 ist der Zeitpunkt, an dem das Dateisystem schreibgeschützt bereitgestellt wurde. Eine wiederholte Beobachtung ist jedoch, dass selbst unter normalen Bedingungen die Wartezeit für zugrunde liegende Geräte viel geringer ist als die des Multipath-Geräts. 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 zufällig die lokale Festplatte, während dev8-16 ( /dev/sdb) und dev8-32 ( /dev/sdc) die zugrunde liegenden für dev252-0 ( /dev/mapper/mpatha) sind. dev252-1 ( /dev/mapper/mpathap1) ist eine einzelne Partition, die sich über das gesamte Multipath-Gerät erstreckt. 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 Wartezeit /dev/mapper/mpathap1so viel höher sein als die von /dev/mapper/mpathaoder sogar /dev/sdboder /dev/sdc?

performance iowait device-mapper

— pdp
quelle

Es scheint bemerkenswert, dass auf dem Weg von /dev/mapper/mpathap1nach anscheinend viele Anfragen zusammengeführt werden /dev/mapper/mpatha. Dies ist auch die Ebene, auf der die meiste awaitZeit hinzugefügt zu werden scheint. Können Sie überprüfen, in welchen Aufzügen welche verwendet werden /sys/block/mpathap1/queue/schedulerund diese /sys/block/mpatha/queue/schedulermöglicherweise auf deadlineoder noopzum Vergleich umstellen?

— the-wabbit

Der I / O-Scheduler für mpatha( /sys/block/dm-0/queue/scheduler) ist noopund der für mpathap1( /sys/block/dm-1/queue/scheduler) ist none.

— pdp

Ich vermute sehr, dass der Warteschlangen- / Zusammenführungsalgorithmus des Schedulers für die Verzögerung verantwortlich ist. Ich würde CFQ der zugrunde liegenden Geräte gegen Noop oder Deadline tauschen, um zu sehen, ob sich etwas ändert. Dies hängt jedoch wahrscheinlich nicht mit Ihrem Problem mit allen Pfaden zusammen.

— the-wabbit

FWIW, ich habe das gleiche Verhalten bei anderen Arten von Device-Mapper-Geräten beobachtet - speziell bei NSS-Pools . Zusammenführbare Schreibvorgänge haben eine höhere Wartezeit (und längere Warteschlangen) auf dem dmGerät als auf dem zugrunde liegenden physischen Gerät, während Leseanforderungen und Schreibvorgänge ohne Zusammenführung größtenteils unberührt bleiben. Ich weiß noch nicht, ob dies einfach ein Darstellungsfehler ist, der auf die Art und Weise, in der die Wartezeiten berechnet werden, oder auf die tatsächlich verlängerten Antwortzeiten aufgrund der Art des Warteschlangen- / Zusammenführungsalgorithmus zurückzuführen ist.

— the-wabbit

Eines der Systemtap-E / A-Skripte bietet möglicherweise zusätzliche Einblicke in die aktuellen Vorgänge . io_submit.stp, ioblktime.stp und biolatency-nd.stp sind möglicherweise gute Ausgangspunkte.

— Kassandry,

Wie der Benutzer "the-wabbit" vorschlägt, werden Anforderungen zusammengeführt. Sie können dies in der Spalte avgrq-sz sehen, der durchschnittlichen Anforderungsgröße, die eine signifikante Zunahme aufweist.

"Warten" ist nun die Zeit, die in der Warteschlange verbracht wurde, plus die Zeit, die für die Bearbeitung dieser Anforderungen aufgewendet wurde. Wenn eine kleine Anforderung, nennen wir sie 'x', mit einigen anderen Anforderungen (y und z, die nach x ausgegeben werden) zusammengeführt wird, wird x

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

Dies wird sich offensichtlich negativ auf die Erwartungsstatistik auswirken, hauptsächlich aufgrund der Art und Weise, wie die Erwartungsstatistik berechnet wird, ohne dass dies ein Problem für sich bedeutet.

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

Status = aktiviert

und weiter ist

Status = aktiv

Sie haben wahrscheinlich

path_grouping_policy Failover

in Ihrer Konfiguration (die die Standardeinstellung ist).

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

        features "1 queue_if_no_path"

in deiner multipath.conf

Nun bleibt die eigentliche Frage: Warum gehen beide Wege?

— entfernter Geist
quelle