У меня задержка fsync около пять секунд в хранилищах данных NFS в ESXi, запускаемых определенными виртуальными машинами. Я подозреваю, что это может быть вызвано виртуальными машинами, использующими NCQ / TCQ, поскольку этого не происходит с виртуальными дисками IDE.
Это можно воспроизвести с помощью fsync-тестер (Тед Тсо) и иопинг. Например, используя живую систему Grml с диском 8 ГБ:
Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]
Это 5 секунд, а не миллисекунды. Это даже создает задержки ввода-вывода на другой виртуальной машине, работающей на том же хосте и в хранилище данных.:
root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms
Когда я перемещаю первую виртуальную машину в локальное хранилище, она выглядит совершенно нормально:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]
То, что я пробовал, но без разницы:
Гостевая ОС протестирована, обнаружены проблемы:
Мне не удалось воспроизвести эту проблему на виртуальных машинах Linux 2.6.18.
Другой обходной путь - использовать виртуальные диски IDE (по сравнению с SCSI / SAS), но это ограничивает производительность и количество дисков на виртуальную машину.
Обновление 2011-06-30:
Скачки задержки, кажется, случаются чаще, если приложение записывает несколько небольших блоков перед fsync. Например, fsync-tester делает это (вывод strace):
pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3) = 0
ioping делает это при подготовке файла:
[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3) = 0
Фаза настройки ioping почти всегда зависает, а fsync-tester иногда работает нормально. Может ли кто-нибудь обновить fsync-tester для записи нескольких небольших блоков? Мои навыки Си - отстой;)
Обновление 2011-07-02:
Эта проблема не возникает с iSCSI. Я пробовал это с сервером OpenIndiana COMSTAR iSCSI. Но iSCSI не дает вам легкий доступ к файлам VMDK, поэтому вы можете перемещать их между хостами с помощью моментальных снимков и rsync.
Обновление 2011-07-06:
Это часть захвата wirehark, захваченного третьей виртуальной машиной на том же vSwitch. Все это происходит на одном хосте, без участия физической сети.
Я начал ioping около 20 часов. Пакеты не отправлялись, пока не закончилась пятисекундная задержка:
No. Time Source Destination Protocol Info
1082 16.164096 192.168.250.10 192.168.250.20 NFS V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112 192.168.250.10 192.168.250.20 NFS V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060 192.168.250.20 192.168.250.10 TCP nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678 192.168.250.20 192.168.250.10 NFS V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280 192.168.250.20 192.168.250.10 NFS V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417 192.168.250.10 192.168.250.20 TCP iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028 192.168.250.10 192.168.250.20 NFS V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541 192.168.250.20 192.168.250.10 NFS V3 GETATTR Reply (Call In 1088) Directory mode:0777 uid:0 gid:0
1090 23.274252 192.168.250.10 192.168.250.20 TCP iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188 192.168.250.10 192.168.250.20 RPC Continuation
1092 24.924210 192.168.250.10 192.168.250.20 RPC Continuation
1093 24.924216 192.168.250.10 192.168.250.20 RPC Continuation
1094 24.924225 192.168.250.10 192.168.250.20 RPC Continuation
1095 24.924555 192.168.250.20 192.168.250.10 TCP nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626 192.168.250.10 192.168.250.20 RPC Continuation
1097 24.924635 192.168.250.10 192.168.250.20 RPC Continuation
1098 24.924643 192.168.250.10 192.168.250.20 RPC Continuation
1099 24.924649 192.168.250.10 192.168.250.20 RPC Continuation
1100 24.924653 192.168.250.10 192.168.250.20 RPC Continuation
2-е обновление 2011-07-06:
Кажется, есть некоторое влияние на размеры окон TCP. Мне не удалось воспроизвести эту проблему, используя FreeNAS (на основе FreeBSD) в качестве сервера NFS. Захваты wirehark показали обновления окна TCP до 29127 байт через равные промежутки времени. Я не видел их в OpenIndiana, где по умолчанию используются окна большего размера.
Я больше не смогу воспроизвести эту проблему, если установлю следующие параметры в OpenIndiana и перезапущу сервер NFS:
ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576
Но это убивает производительность: запись из / dev / zero в файл с помощью dd_rescue идет со 170 МБ / с до 80 МБ / с.
Обновление 2011-07-07:
Я загрузил это захват tcpdump (можно проанализировать с помощью wirehark). В этом случае 192.168.250.2 - это сервер NFS (OpenIndiana b148), а 192.168.250.10 - это хост ESXi.
Вещи, которые я тестировал во время этого захвата:
Запустил "ioping -w 5 -i 0.2." в момент 30, 5 секунд зависает в настройке, завершается в момент 40.
Запустил "ioping -w 5 -i 0.2." в момент времени 60, настройка зависает на 5 секунд, завершается в момент времени 70.
Запуск "fsync-tester" в момент времени 90 со следующим выводом, остановленный в момент времени 120:
fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209
2-е обновление 2011-07-07:
Протестировал другую виртуальную машину сервера NFS, на этот раз NexentaStor 3.0.5 Community Edition: показывает те же проблемы.
Обновление 2011-07-31:
Я также могу воспроизвести эту проблему в новой сборке ESXi 4.1.0.433742.
Эта проблема, похоже, исправлена в ESXi 5. Я успешно протестировал сборку 469512.
Спасибо, nfsstat выглядит хорошо. Я просмотрел захват. Не нашел ничего убедительного, но нашел кое-что интересное. Я отфильтровал tcp.time_delta> 5. Что я нашел в каждый Экземпляр задержки был точным началом вызова RPC. Не все новые вызовы RPC были медленными, но все замедления происходили в точном начале вызова RPC. Кроме того, из захвата видно, что 192.168.250.10 содержит всю задержку. 192.168.250.2 немедленно отвечает на все запросы.
Выводы:
Большой вызов записи может разбиться на 300 отдельных TCP-пакетов, и только первый задерживается, а все остальные проходят. Никогда задержка не происходит посередине. Я не уверен, как размер окна может повлиять на начало связи так резко.
Следующие шаги: я бы начал настраивать параметры NFS, такие как NFSSVC_MAXBLKSIZE, вниз, а не окно TCP. Также я заметил, что 2.6.18 работает, а 2.6.38 - нет. Я знаю, что за это время была добавлена поддержка драйвера VMXnet3. Какие драйверы NIC вы используете на хостах? Разгрузка TCP да / нет? Примерно на отметке 95 секунд имеется более 500 пакетов TCP для одного вызова записи NFS. То, что отвечает за TCP, и разделение большого PDU может быть тем, что блокирует.
У меня такая же проблема с виртуальными машинами ESXi4.1U1 и CentOS. Хосты - Dell R610s, хранилище - кластер EMC2 Isilon.
Вы случайно не использовали VLANS? Я обнаружил, что использование VLAN на порту VMkernel для хранилища вызывает «зависания» 4000-5000 мс для всего трафика хранилища на VMHost. Однако, если я перемещаю порт VMkernel из VLAN, чтобы он получал немаркированные пакеты, я не вижу проблемы.
Приведенная ниже простая настройка вызовет проблему в моей сети:
1) Установите ESXi 4.1U1 на сервер или рабочую станцию (у обоих возникла проблема, когда я попытался)
2) Добавьте порт VMkernel в VLAN.
3) Добавьте хранилище данных NFS (мой находится в той же VLAN, т.е. Isilon принимает тегированные пакеты)
4) Установите 2 виртуальные машины CentOS 5.5, одну с ioping.
5) Загрузите виртуальные машины в однопользовательский режим (т.е. без сети, минимум услуг)
6) Запустите ioping на одной машине, чтобы она записывала на виртуальный диск
7) Запустите dd или что-то подобное на другом компьютере, чтобы записать 100 МБ данных в / tmp или аналогичный
Чаще всего я вижу зависание обеих ВМ на 4-5 секунд.
По-настоящему интересно, видел ли кто-нибудь подобное.
Две недели назад у нас была точно такая же проблема. ESX41 U1 и NetApp FAS3170 + хранилища данных NFS. Виртуальные машины RHEL5 зависают на 2 или 4 секунды, и мы видели очень высокие всплески производительности консоли Virtual Center.
Я прошу специалиста по сети проверить конфигурацию, и проблема была в коммутаторе cisco. У нас есть два соединения Ethernet, которые были настроены на Etherchannel на стороне Netapp, а не на стороне cisco. Он создает статический Ethechannel на cisco, и теперь он работает нормально. Чтобы выявить проблему такого рода, отключите все порты, кроме одного между фильтром и коммутатором. Оставьте в живых только один порт и посмотрите, как идут дела.
Второе, что мы сделали, - удалили Flow Control на переключателе и фильтре, потому что мы подозреваем, что он отправляет кадр паузы.
Как выглядит ваш DNS? Ваш /etc/resolv.conf верный? Тайм-аут по умолчанию составляет 5 секунд.
Из man resolv.conf
timeout:n
sets the amount of time the resolver will wait for a
response from a remote name server before retrying the
query via a different name server. Measured in seconds,
the default is RES_TIMEOUT (currently 5, see <resolv.h>).
Попробуйте добавить timeout:3 на ваш /etc/resolv.conf а затем снова запустите тесты fsync.
Хватаемся за соломинку, но какие сетевые адаптеры вы используете на этих серверах? У системных администраторов Stack Overflow были странные сетевые проблемы с сетевыми адаптерами Broadcom, которые исчезли при переходе на сетевые адаптеры Intel: http://blog.serverfault.com/post/broadcom-die-mutha/
Вот еще одна догадка ... Включен ли ваш IPv6 на хосте EXS? Если да, то попробовать выключить? По моему опыту, если вся ваша сеть неправильно настроена для IPv6 (например, RADV, DHCP6, DNS, обратный DNS), это может быть проблемой для некоторых служб. Также убедитесь, что он выключен на сервере NFS.