Mengapa waktu tunggu yang lebih tinggi untuk perangkat DM multipath daripada perangkat yang mendasarinya?

Kami memiliki server berbasis CentOS 6.4 yang terhubung dengan penyimpanan Hitachi HNAS 3080 dan mengamati kernel yang melakukan remount sistem file dalam mode read-only:

16 Mei 07:31:03 Kernel GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): error: remounting filesystem read-only

Ini terjadi setelah beberapa kesalahan I / O dan semua jalur ke perangkat dilaporkan turun:

16 Mei 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: jalur aktif yang tersisa: 0

Saya telah melihat log sar dan dapat melihat beberapa sangat besar (2 detik) menunggu waktu:

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

Durasi antara 07: 30: 00-07: 40: 00 tidak terjadi pada saat filesystem dimount read-only. Namun, bahkan dalam kondisi normal, satu pengamatan berulang adalah bahwa waktu tunggu untuk perangkat yang mendasarinya jauh lebih rendah daripada perangkat multipath. Contohnya:

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 adalah disk lokal, sementara dev8-16 ( /dev/sdb) dan dev8-32 ( /dev/sdc) adalah yang mendasarinya untuk dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) adalah partisi tunggal yang mencakup seluruh perangkat multipath. Ini adalah output dari 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

Mengapa waktu menunggu /dev/mapper/mpathap1harus jauh lebih tinggi daripada /dev/mapper/mpathaatau bahkan /dev/sdbatau /dev/sdc?

performance iowait device-mapper

— pdp
sumber

Tampaknya patut dicatat bahwa ternyata banyak permintaan penggabungan yang terjadi dalam perjalanan dari /dev/mapper/mpathap1ke /dev/mapper/mpatha. Ini juga merupakan lapisan di mana sebagian besar awaitwaktu tampaknya ditambahkan. Bisakah Anda memeriksa elevator mana yang digunakan /sys/block/mpathap1/queue/schedulerdan /sys/block/mpatha/queue/scheduler, mungkin mengubahnya ke deadlineatau noopuntuk perbandingan?

— the-wabbit

The I / O scheduler untuk mpatha( /sys/block/dm-0/queue/scheduler) adalah noopdan bahwa untuk mpathap1( /sys/block/dm-1/queue/scheduler) adalah none.

— pdp

Saya sangat curiga bahwa algoritma antrian / penggabungan penjadwal bertanggung jawab atas keterlambatan tersebut. Saya akan menukar cfq dari perangkat yang mendasari untuk noop atau tenggat waktu hanya untuk melihat apakah itu mengubah apa pun. Namun, ini kemungkinan tidak akan terkait dengan semua jalur Anda.

— the-wabbit

FWIW, saya telah mengamati perilaku yang sama pada jenis perangkat perangkat mapper lainnya - khususnya dengan kumpulan NSS . Menulis gabungan dapat memiliki menunggu lebih tinggi (dan antrian lebih lama) pada dmperangkat daripada pada perangkat fisik yang mendasari saat membaca permintaan dan menulis tanpa penggabungan yang dilakukan pada umumnya tidak terpengaruh. Saya belum tahu apakah ini hanyalah kesalahan presentasi karena cara menunggu dihitung atau sebenarnya waktu respons yang lama karena sifat dari algoritma antrian / penggabungan.

— the-wabbit

Salah satu skrip Systemtap IO mungkin bisa memberi Anda wawasan tambahan tentang apa yang sedang terjadi. io_submit.stp, ioblktime.stp, dan biolatency-nd.stp mungkin tempat yang baik untuk memulai.

— Kassandry

Seperti yang disarankan oleh pengguna-wabbit, ada penggabungan permintaan yang terjadi. Anda dapat melihat bahwa di kolom avgrq-sz, ukuran permintaan rata-rata - yang menunjukkan peningkatan yang signifikan.

Sekarang 'menunggu' adalah waktu yang dihabiskan dalam antrian ditambah waktu yang dihabiskan untuk melayani permintaan tersebut. Jika permintaan kecil, sebut saja 'x', digabung dengan beberapa permintaan lainnya (y dan z, dikeluarkan setelah x), maka x akan

tunggu dalam antrian untuk digabung dengan y
tunggu di antrian tu digabung dengan z
menunggu (x, y, z) selesai

Ini jelas akan memiliki dampak negatif pada statistik menunggu, terutama karena cara menunggu dihitung, tanpa benar-benar menandakan masalah itu sendiri.

Sekarang mari kita lihat / dev / sdb (dev8-16). Tahukah Anda bahwa Anda tidak menggunakan jalur itu? Anda memiliki dua grup prioritas dalam konfigurasi multipath Anda, satu adalah

status = diaktifkan

dan ini

status = aktif

Anda mungkin punya

failover path_grouping_policy

dalam konfigurasi Anda (yang merupakan default).

Jika Anda ingin mencegah kesalahan IO jika kedua jalur turun, Anda dapat mencoba:

        fitur "1 queue_if_no_path"

di multipath.conf Anda

Sekarang pertanyaan sebenarnya tetap ada, mengapa kedua jalur itu turun?

— pikiran yang jauh
sumber