Tại sao thời gian chờ đợi cho thiết bị đa đường DM cao hơn thiết bị cơ bản?

Chúng tôi có một máy chủ dựa trên CentOS 6.4 được gắn vào bộ lưu trữ Hitachi HNAS 3080 và quan sát hạt nhân tái hiện hệ thống tập tin ở chế độ chỉ đọc:

16 tháng 5 07:31:03 Hạt nhân GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): lỗi: kết nối lại hệ thống tập tin chỉ đọc

Điều này xảy ra sau một số lỗi I / O và tất cả các đường dẫn đến thiết bị được báo cáo là không hoạt động:

16 tháng 5 07:31:03 Đa luồng GNS3-SRV-CMP-001: mpatha: các đường dẫn hoạt động còn lại: 0

Tôi đã xem xét nhật ký sar và có thể thấy vài lần rất lớn (2 giây) đang chờ:

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

Thời lượng trong khoảng thời gian từ 07: 30: 00-07: 40: 00 xảy ra khi hệ thống tập tin được gắn ở chế độ chỉ đọc. Tuy nhiên, ngay cả trong điều kiện bình thường, một quan sát lặp đi lặp lại là thời gian chờ đợi cho các thiết bị cơ bản thấp hơn nhiều so với thiết bị đa đường. Ví dụ:

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 là đĩa cục bộ, trong khi dev8-16 ( /dev/sdb) và dev8-32 ( /dev/sdc) là những đĩa cơ bản cho dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) là một phân vùng duy nhất bao trùm toàn bộ thiết bị đa đường. Đây là đầu ra từ 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

Tại sao thời gian chờ đợi /dev/mapper/mpathap1phải cao hơn rất nhiều so với thời gian /dev/mapper/mpathahoặc thậm chí /dev/sdbhoặc /dev/sdc?

performance iowait device-mapper

— pdp
nguồn

Có vẻ đáng chú ý là rõ ràng có rất nhiều yêu cầu sáp nhập đang diễn ra trên đường từ /dev/mapper/mpathap1đến /dev/mapper/mpatha. Đây cũng là lớp mà hầu hết awaitthời gian dường như được thêm vào. Bạn có thể kiểm tra thang máy nào được sử dụng trong /sys/block/mpathap1/queue/schedulervà /sys/block/mpatha/queue/scheduler, có thể chuyển đổi nó sang deadlinehoặc noopđể so sánh không?

— the-wợi

Bộ lập lịch I / O cho mpatha( /sys/block/dm-0/queue/scheduler) là noopvà cho mpathap1( /sys/block/dm-1/queue/scheduler) là none.

— pdp

Tôi hoàn toàn nghi ngờ rằng thuật toán xếp hàng / hợp nhất của bộ lập lịch chịu trách nhiệm cho sự chậm trễ. Tôi sẽ trao đổi cfq của các thiết bị cơ bản cho noop hoặc hạn chót chỉ để xem liệu nó có thay đổi gì không. Điều này có khả năng sẽ không liên quan đến vấn đề tất cả các con đường của bạn xuống.

— the-wợi

FWIW, tôi đã quan sát loại hành vi tương tự trên các loại thiết bị ánh xạ thiết bị khác - cụ thể là với các nhóm NSS . Việc ghi có khả năng hợp nhất có sự chờ đợi cao hơn (và hàng đợi dài hơn) trên dmthiết bị so với thiết bị vật lý cơ bản trong khi đọc yêu cầu và viết mà không có bất kỳ sự hợp nhất nào được thực hiện chủ yếu không bị ảnh hưởng. Tôi vẫn chưa biết liệu đây có phải chỉ là lỗi trình bày do cách chờ đợi được tính toán hay thời gian phản hồi thực sự kéo dài do bản chất của thuật toán xếp hàng / hợp nhất.

— the-wợi

Một trong các kịch bản IO của Systemtap có thể cung cấp cho bạn cái nhìn sâu sắc hơn về những gì đang diễn ra. io_submit.stp, ioblktime.stp và biolatency-nd.stp có thể là nơi tốt để bắt đầu.

— Kassandry

Như người dùng gợi ý, có sự hợp nhất yêu cầu đang diễn ra. Bạn có thể thấy rằng trong cột avgrq-sz, kích thước yêu cầu trung bình - cho thấy sự gia tăng đáng kể.

Bây giờ 'chờ đợi' là thời gian dành cho hàng đợi cộng với thời gian phục vụ các yêu cầu đó. Nếu một yêu cầu nhỏ, hãy gọi nó là 'x', được hợp nhất với một vài yêu cầu khác (y và z, được phát hành sau x), sau đó x sẽ

chờ trong hàng đợi để được hợp nhất với y
chờ trong hàng đợi tu được hợp nhất với z
chờ cho (x, y, z) hoàn thành

Điều này rõ ràng sẽ có tác động tiêu cực đến thống kê chờ đợi, chủ yếu là do cách chờ đợi được tính toán, mà không thực sự biểu thị một vấn đề trong chính nó.

Bây giờ hãy xem / dev / sdb (dev8-16). Bạn có biết rằng bạn không sử dụng con đường đó? Bạn có hai nhóm ưu tiên trong cấu hình đa đường của bạn, một là

trạng thái = kích hoạt

và trên là

trạng thái = hoạt động

Bạn có thể có

chuyển đổi dự phòng path_grouping_policy

trong cấu hình của bạn (đó là mặc định).

Nếu bạn muốn ngăn lỗi IO trong trường hợp cả hai đường dẫn bị hỏng, bạn có thể thử:

        tính năng "1 queue_if_no_path"

trong bội số của bạn

Bây giờ câu hỏi thực sự vẫn còn, tại sao cả hai con đường đi xuống?

— tâm trí từ xa
nguồn