Назад | Перейти на главную страницу

iostat - устройство dm-0 показывает гораздо более высокие задержки, чем sdX

Мы запускаем виртуальные машины linux (Centos 5.x) поверх vmware vsphere 5.5. Я отслеживаю латентность диска с помощью iostat, в частности столбца await, но замечаю странные результаты с устройством сопоставления устройств / LVM по сравнению с «физическими» дисками, поддерживающими LVM.

Ниже представлен набор выходных данных iostat -x 5 на одной из наших довольно активных виртуальных машин. Рассматриваемая виртуальная машина имеет два диска: sda с одним разделом / boot и sdb в качестве основного диска с / на sdb2. В то время как iostat показывает задержки ~ 20-40 мс для await для устройства sdb2 (единственное устройство / раздел, поддерживающее мою volgroup / dm-0), iostat для dm-0 показывает ожидание 100 + мс.

У меня вопрос: какая статистика здесь "правильная", насколько реальные задержки система видит? Видит ли он ~ 20 мс, показанный для "физического" диска sdb, или действительно видит 100 + мс для dm-0, возможно, из-за некоторых проблем с выравниванием / и т.д., возникающих при включении LVM? Это странно, потому что иногда статистика довольно хорошо совпадает, в других - нет - например, в блоке вывода iostat ниже sdb2 показывает 419 операций ввода-вывода в секунду при записи, а dm-0 показывает 39 тыс операций ввода-вывода в секунду при записи.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.78    0.00    8.42   39.07    0.00   46.73

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb              15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2             15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
dm-0              0.00     0.00 761.33 39720.67 64120.00 317765.33     9.43  4933.92  121.88   0.02 100.07

Обновление: я дополнительно прочитал, включая ссылки в ответе Джина ниже. Я знаю, что задействовано множество переменных (виртуализация, блочная файловая система и т. Д.), Но эта часть кажется отсортированной в соответствии с нашими поставщиками и рекомендациями VMware, а производительность на самом деле очень хорошая. Я действительно просто смотрю на это с точки зрения «внутри виртуальной машины».

В связи с этим я подозреваю, что есть проблема с выравниванием нашего раздела + LVM:

GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483647s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End          Size         Type     File system  Flags
 1      63s       4192964s     4192902s     primary  linux-swap   boot
 2      4192965s  2097151999s  2092959035s  primary               lvm

~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb2
  VG Name               VolGroup00
  PV Size               998.00 GB / not usable 477.50 KB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              31936
  Free PE               0
  Allocated PE          31936
  PV UUID               tk873g-uSZA-JaWV-R8yD-swXg-lPvM-dgwPQv

Читая о выравнивании, похоже, что ваш начальный сектор должен делиться на 8, поэтому вы выравниваете по границе 4kb со стандартным размером сектора 512b. Похоже, LVM может автоматически выравниваться, когда вы применяете его ко всему диску, но поскольку мы сначала разделяем диск, а затем делаем наш раздел ie / dev / sdb2 физическим устройством для использования LVM, я не уверен, что в этом случае он сможет рассчитать смещение. За http://linux.die.net/man/5/lvm.conf, параметр data_alignment_offset_detection: «Если установлено в 1, и ваше ядро ​​предоставляет информацию о топологии в sysfs для физического тома, начало выровненной области данных физического тома будет смещено на alignment_offset, представленное в sysfs». Это Centos5, и я не вижу никакой из этой информации, отображаемой в sysfs, только на наших Centos6 и более новых виртуальных машинах, поэтому она может быть не в состоянии правильно выровнять на физическом томе.

Я нашел этот технический документ netapp о выравнивании разделов виртуальных машин http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc=us В частности, в разделе 4.5, с. 29 есть полезная информация о правильном разбиении виртуальной машины на разделы для правильного согласования с LVM. Я буду следить за этим, чтобы наши новые виртуальные машины были правильно выровнены.

Похоже, что это могло вызвать такое поведение, может ли кто-нибудь с большим опытом / знаниями подтвердить это?

На этот вопрос нет простого ответа, поскольку речь идет о виртуализации. У вас есть виртуальный диск, расположенный поверх файловой системы поверх блочного устройства, представленного виртуальному гостю, у которого есть собственный драйвер, представляющий блочное устройство для LVM. Я не знаю наверняка, вызовет ли это такую ​​огромную разницу, но это возможно.

За гранью этого...

LVM добавляет накладные расходы, поэтому разница будет. Если ваш LVM и блочные устройства не выровнены должным образом, это также может быть фактором.

Выравнивание - непростая тема, которую можно раскрыть в такой обстановке. Лучшее, что я могу сделать, это порекомендовать вам пару документов, возможно, вы найдете в них больше ответов: