Поиск и устранение неисправностей задержки пронзает на хранилищах данных NFS ESXI

Захват за солому здесь, но какой NICs Вы используете в этих серверах? У системных администраторов Переполнения стека были странные сетевые проблемы с Broadcom NICs, который ушел, когда они переключились на Intel NICs: http://blog.serverfault.com/post/broadcom-die-mutha/

Как Ваш 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 тесты снова.

Спасибо, nfsstat выглядит хорошим. Я рассмотрел получение. Ничто не нашли окончательным, но действительно находил что-то интересным. Я фильтровал на tcp.time_delta> 5. То, что я нашел в каждом экземпляре задержки, было точным запуском вызова RPC. Не все новые вызовы RPC были медленными, но все замедление произошло в точном запуске вызова RPC. Кроме того, от получения кажется, что 192.168.250.10 содержит всю задержку. 192.168.250.2 сразу отвечает на все запросы.

Результаты:

• Задержки всегда происходят в первом пакете вызова RPC
• Типы Команды NFS не коррелировались для задержки экземпляров
• Фрагментация = задерживает только первый пакет

Большой Вызов Записи может разбиться на 300 отдельных пакетов TCP, и только первое отложено, но остальные вся муха через. Никогда не делает задержку, происходят в середине. Я не уверен, как размер окна мог произвести начало соединения так решительно.

Следующие шаги: я начал бы настраивать опции NFS как NFSSVC_MAXBLKSIZE вниз, а не окно TCP. Кроме того, я заметил, что 2.6.18 работ, в то время как 2.6.38 не делает. Я знаю, что поддержка была добавлена для драйвера VMXnet3 в течение того периода времени. Какие драйверы NIC Вы используете на хостах? TCP, разгружающий да/нет? Вокруг 95second метка там является больше чем 500 пакетами TCP для единственного вызова Записи NFS. Независимо от того, что отвечает за TCP, и разбивание большого PDU могло быть тем, что блокируется.

Вот другое предположение... Ваш IPv6 включен на хосте EXS? Если да, то попытайтесь выключить его? На основе моего опыта, если Ваша вся сеть правильно не настроена для IPv6 (т.е. RADV, DHCP6, DNS, обратный DNS) это может быть проблема для некоторых сервисов. Кроме того, удостоверьтесь, что это выключено на сервере NFS.

I have what looks like the same issue using ESXi4.1U1 and CentOS VM's. The hosts are Dell R610s, storage is an EMC2 Isilon cluster.

Were you by any chance using VLANS? I found using a VLAN on the VMkernel port for storage caused the 4000-5000ms 'hangs' for all storage traffic on the VMHost. However if I move the VMkernel port off the VLAN so it receives untagged packets I don't see the issue.

The simple setup below will cause the problem on my network:

1)Install ESXi 4.1U1 on a server or workstation (both exhibited the issue when I tried)

2)Add a VMkernel port on a VLAN.

3)Add an NFS Datastore (mine is on the same VLAN, i.e the Isilon receives tagged packets)

4)Install 2 CentOS 5.5 VM's, one with ioping.

5)Boot VM's into single user mode (i.e. no network, minimum services)

6)Run ioping on one machine so it's writing to it's virtual disk

7)Run dd or somesuch on the other machine to write 100MB of data to /tmp or similar

More often than not I see both VM's freezing for 4-5 seconds.

Be really interested to see if anyone else has seen similar.

Две недели назад у нас была точно такая же проблема. ESX41 U1 и Netapp FAS3170 + хранилища данных NFS. Виртуальные машины RHEL5 зависают на 2 или 4 секунды, и мы увидели очень высокие всплески производительности консоли Virtual Center.

Я прошу сетевого специалиста проверить конфигурацию, и проблема была в коммутаторе cisco. У нас есть два канала Ethernet, которые были настроены на Etherchannel на стороне NetApp, а не на стороне cisco. Он создает статический канал Ethechannel на cisco, и теперь он работает нормально. Чтобы определить проблему такого рода, отключите все порты, кроме одного между фильтром и коммутатором. Оставьте только один порт активным и посмотрите, как идут дела.

Второе, что мы сделали, это удалили управление потоком на переключателе и фильтре, потому что мы подозреваем, что он отправляет кадр паузы.