Dlaczego dłuższy czas oczekiwania na urządzenie wielościeżkowe DM niż urządzenie bazowe?

Mamy serwer oparty na CentOS 6.4 podłączony do pamięci Hitachi HNAS 3080 i obserwowaliśmy, jak jądro ponownie instaluje system plików w trybie tylko do odczytu:

16 maja 07:31:03 GNS3-SRV-CMP-001 Jądro: [1259725.675814] EXT3-fs (dm-1): błąd: odmontowanie systemu plików tylko do odczytu

Stało się tak po kilku błędach we / wy i rzekomo zanikających wszystkich ścieżek do urządzenia:

16 maja 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: pozostałe aktywne ścieżki: 0

Patrzyłem na dzienniki sar i widzę kilka bardzo dużych (2 sekund) czasów oczekiwania:

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

Czas między 07: 30: 00-07: 40: 00 zdarza się w momencie, gdy system plików został zamontowany tylko do odczytu. Jednak nawet w normalnych warunkach jedną powtarzaną obserwacją jest to, że czas oczekiwania na urządzenia leżące u podstaw jest znacznie krótszy niż w przypadku urządzenia wielościeżkowego. Na przykład:

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 to dysk lokalny, podczas gdy dev8-16 ( /dev/sdb) i dev8-32 ( /dev/sdc) są tymi, na których bazuje dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) to pojedyncza partycja obejmująca całe urządzenie wielościeżkowe. Oto dane wyjściowe z 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

Dlaczego czas oczekiwania miałby /dev/mapper/mpathap1być o wiele wyższy niż czas, /dev/mapper/mpathaa nawet /dev/sdblub /dev/sdc?

performance iowait device-mapper

— pdp
źródło

Wydaje się godne uwagi, że najwyraźniej wiele żądań łączy się w drodze od /dev/mapper/mpathap1do /dev/mapper/mpatha. Jest to również warstwa, na którą awaitwydaje się dodawać większość czasu. Czy możesz sprawdzić, które windy są używane /sys/block/mpathap1/queue/scheduleri /sys/block/mpatha/queue/schedulerewentualnie przełączając je na deadlinelub noopdla porównania?

— the-wabbit

Program planujący we / wy dla mpatha( /sys/block/dm-0/queue/scheduler) jest noopi dla mpathap1( /sys/block/dm-1/queue/scheduler) jest none.

— pdp

Podejrzewam, że za opóźnienie odpowiada algorytm kolejkowania / scalania programu planującego. Zamieniam cfq bazowych urządzeń na noop lub termin, żeby zobaczyć, czy coś to zmieni. Prawdopodobnie nie będzie to miało związku z problemem wszystkich ścieżek.

— the-wabbit

FWIW, zaobserwowałem takie samo zachowanie na innych typach urządzeń mapujących urządzenia - szczególnie z pulami NSS . Zapisywanie z możliwością scalania ma dłuższy czas oczekiwania (i dłuższe kolejki) na dmurządzeniu niż na podstawowym urządzeniu fizycznym, podczas gdy żądania odczytu i zapisywania bez żadnego scalenia pozostają w dużej mierze niezmienione. Nie wiem jeszcze, czy jest to po prostu błąd prezentacji ze względu na sposób obliczania oczekiwań, czy faktycznie wydłużony czas odpowiedzi z powodu natury algorytmu kolejkowania / scalania.

— the-wabbit

Jeden ze skryptów IO Systemtap może zapewnić ci dodatkowy wgląd w to, co się dzieje. io_submit.stp, ioblktime.stp i biolatency-nd.stp mogą być dobrym miejscem do rozpoczęcia.

— Kassandry,

Jak sugeruje użytkownik the-wabbit, trwa scalanie żądań. Widać to w kolumnie avgrq-sz, średni rozmiar żądania - co pokazuje znaczny wzrost.

Teraz „czekaj” to czas spędzony w kolejce plus czas poświęcony na obsługę tych żądań. Jeśli małe żądanie, nazwijmy go „x”, zostanie połączone z kilkoma innymi żądaniami (y i z, wydanymi po x), to x

poczekaj w kolejce do połączenia z y
poczekaj w kolejce, aby połączyć się z
poczekaj na zakończenie (x, y, z)

Będzie to oczywiście miało negatywny wpływ na statystykę oczekiwania, głównie ze względu na sposób obliczania oczekiwania, bez faktycznego oznaczenia problemu jako takiego.

Teraz spójrzmy na / dev / sdb (dev8-16). Czy wiesz, że nie korzystasz z tej ścieżki? Masz dwie grupy priorytetów w konfiguracji wielościeżkowej, jedna to

status = włączony

i dalej jest

status = aktywny

Prawdopodobnie masz

path_grouping_policy tryb failover

w twojej konfiguracji (która jest domyślna).

Jeśli chcesz zapobiec błędom we / wy w przypadku, gdy obie ścieżki nie działają, możesz spróbować:

        zawiera funkcję „1 kolejka_jeśli_na_ścieżka”

w pliku multipath.conf

Teraz pozostaje pytanie: dlaczego obie ścieżki idą w dół?

— zdalny umysł
źródło