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?

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”

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