Neden DM çoklu yol cihazı için temel cihazdan daha yüksek bekleme süresi?

Hitachi HNAS 3080 depolama birimine bağlı bir CentOS 6.4 tabanlı sunucumuz var ve çekirdek sistemini yeniden okuma modunda gözlemledi:

16 Mayıs 07:31:03 GNS3-SRV-CMP-001 çekirdeği: [1259725.675814] EXT3-fs (dm-1): hata: dosya sisteminin yeniden okunması için yeniden okuma

Bu, birkaç G / Ç hatası ve cihaza giden tüm yolların düştüğü bildirildi:

16 Mayıs 07:31:03 GNS3-SRV-CMP-001 çoklu yol: mpatha: kalan etkin yollar: 0

Sar günlüklerine bakıyordum ve çok az (2 saniye) birkaç kez bekliyor:

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 arasındaki süre, dosya sisteminin salt okunur olarak bağlandığı zamandır. Bununla birlikte, normal koşullar altında bile, tekrarlanan bir gözlem, altta yatan cihazlar için bekleme süresinin, çok yollu cihazınkinden çok daha düşük olmasıdır. Örneğin:

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 yerel disk olurken, dev8-16 ( /dev/sdb) ve dev8-32 ( /dev/sdc), dev252-0 ( ) için temel olanlardır /dev/mapper/mpatha. dev252-1 ( /dev/mapper/mpathap1), çok yollu cihazın tamamını kapsayan tek bir bölümdür. İşte çıktı 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

Beklemek için neden zaman /dev/mapper/mpathap1, /dev/mapper/mpathaya da hatta /dev/sdbya da bu zamandan çok daha yüksek olsun /dev/sdc?

Wabbit kullanıcısının önerdiği gibi, istek birleştirme devam ediyor. Avgrq-sz sütununda, ortalama istek boyutunun önemli bir artış gösterdiğini görebilirsiniz.

Şimdi 'beklemek' kuyrukta harcanan zaman ve bu isteklere hizmet etmek için harcanan zamandır. Küçük bir istek, 'x' diyelim, birkaç başka istekle (x'den sonra verilen y ve z) birleştirilirse, x

• y ile birleştirilmek için sırada bekle
• sırada bekle tu z ile birleştirilecek
• (x, y, z) 'nin tamamlanmasını bekleyin

Bu, büyük olasılıkla, kendi başına bir problemi belirtmeden, beklemenin hesaplanma şekli nedeniyle, beklenen istatistik üzerinde olumsuz bir etkiye sahip olacaktır.

Şimdi / dev / sdb (dev8-16) 'a bakalım. Bu yolu kullanmadığınızı biliyor muydunuz? Çok yollu yapılandırmanızda iki öncelik grubu var, biri

status = etkin

ve üstünde

Durum, etkin =

Muhtemelen var

path_grouping_policy yük devretme

(varsayılan ayardır).

Her iki yolun da kapalı olması durumunda GÇ hatalarını önlemek istiyorsanız deneyebilirsiniz:

        özellikler "1 queue_if_no_path"

Şimdi asıl soru kalıyor, neden her iki yol da aşağıya iniyor?