기본 장치보다 DM 다중 경로 장치의 대기 시간이 더 높은 이유는 무엇입니까?

우리는 Hitachi HNAS 3080 스토리지에 연결된 CentOS 6.4 기반 서버를 가지고 있으며 커널이 파일 시스템을 읽기 전용 모드로 다시 마운트하는 것을 관찰했습니다 :

5 월 16 일 07:31:03 GNS3-SRV-CMP-001 커널 : [1259725.675814] EXT3-fs (dm-1) : 오류 : 읽기 전용 파일 시스템 마운트

이것은 여러 I / O 오류와 장치의 모든 경로가 다운 된 후에 발생했습니다.

5 월 16 일 07:31:03 GNS3-SRV-CMP-001 다중 경로 : mpatha : 잔여 활성 경로 : 0

나는 sar 로그를보고 있었고 매우 큰 (2 초) 대기 시간을 거의 볼 수 없습니다.

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

파일 시스템이 읽기 전용으로 마운트 된 시간은 07 : 30 : 00-07 : 40 : 00입니다. 그러나 정상적인 조건에서도 반복되는 관찰은 기본 장치의 대기 시간이 다중 경로 장치의 대기 시간보다 훨씬 낮다는 것입니다. 예를 들어 :

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은 로컬 디스크 인 반면 dev8-16 ( /dev/sdb) 및 dev8-32 ( /dev/sdc)는 dev252-0 ( )의 기본 디스크 /dev/mapper/mpatha입니다. dev252-1 ( /dev/mapper/mpathap1)은 다중 경로 장치 전체에 걸친 단일 파티션입니다. 출력은 다음과 같습니다 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

왜의 AWAIT 시간이해야 /dev/mapper/mpathap1훨씬 더 높은보다 일 /dev/mapper/mpatha또는 /dev/sdb나 /dev/sdc?

performance iowait device-mapper

— pdp
소스

요청 병합의 분명히 많은의 길에 무슨 일이 일어나고 주목할만한 것 같습니다 /dev/mapper/mpathap1에 /dev/mapper/mpatha. 이것은 또한 대부분의 await시간이 추가되는 것처럼 보이는 계층 입니다. /sys/block/mpathap1/queue/scheduler및 에 사용 된 엘리베이터를 확인 하고 비교 하거나 /sys/block/mpatha/queue/scheduler전환 할 수 있습니까? deadlinenoop

— the-wabbit 2016 년

I / O 스케줄러 에 대한은 mpatha( /sys/block/dm-0/queue/scheduler)입니다 noop및에 그 mpathap1( /sys/block/dm-1/queue/scheduler)이다 none.

— pdp

스케줄러의 대기열 / 병합 알고리즘이 지연을 담당한다고 의심합니다. 기본 장치의 cfq를 noop 또는 데드 라인으로 바꾸면 아무것도 변경되는지 확인합니다. 그러나 이것은 모든 경로 다운 문제와 관련이 없을 것입니다.

— the-wabbit 2016 년

FWIW, 다른 유형의 장치 매퍼 장치 (특히 NSS 풀) 에서 동일한 종류의 동작을 관찰했습니다 . 병합 가능한 쓰기는 dm기본 물리적 장치보다 장치 에서 대기 시간이 길고 대기열이 길지만 병합 요청없이 읽기 요청 및 쓰기는 주로 영향을받지 않습니다. 대기 / 계산 알고리즘의 특성으로 인해 대기 시간이 계산되거나 실제로 응답 시간이 연장되는 방식으로 인해 단순히 프레젠테이션 오류인지 여부는 아직 알 수 없습니다.

— the-wabbit

Systemtap IO 스크립트 중 하나 가 현재 진행중인 작업에 대한 추가 정보를 제공 할 수 있습니다. io_submit.stp, ioblktime.stp 및 biolatency-nd.stp를 시작하는 것이 좋습니다.

— Kassandry

사용자 thewabbit에서 알 수 있듯이 요청 병합이 진행 중입니다. avgrq-sz 열에서 평균 요청 크기-크게 증가한 것을 볼 수 있습니다.

이제 'await'는 대기열에서 보낸 시간과 해당 요청을 처리하는 데 걸린 시간입니다. 작은 요청을 'x'라고 부르고 두 개의 다른 요청 (y와 z, x 다음에 발행)과 병합되면 x는

대기열에서 y와 병합되기를 기다립니다.
대기열에서 대기하여 z와 병합하십시오.
(x, y, z)가 완료 될 때까지 기다리십시오

이것은 실제로 자체적으로 문제를 나타내지 않고 await가 계산되는 방식 때문에 await 통계에 부정적인 영향을 미칩니다.

이제 / dev / sdb (dev8-16)를 보자. 해당 경로를 사용하고 있지 않다는 것을 알고 있습니까? 다중 경로 구성에 두 개의 우선 순위 그룹이 있습니다.

status = 사용

에

status = active

아마도

path_grouping_policy 장애 조치

구성에서 (기본값)

두 경로가 모두 다운 된 경우 IO 오류를 방지하려면 다음을 시도하십시오.

        "1 queue_if_no_path"기능

multipath.conf에

이제 실제 질문이 남아 있습니다. 왜 두 경로가 모두 내려가나요?

— 먼 마음
소스