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

VMXNET3 размер буфера приема и использование памяти

Задний план

У нас был инцидент, когда отказоустойчивый кластер Windows перестал работать. Вскрытие показало, что узел был «удален», как описано в этой статье.

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

Связанная статья базы знаний VMware об этом говорит об увеличении Small Rx Buffers и Rx Ring #1 настройки, но предупреждает, что их слишком большое увеличение может значительно увеличить накладные расходы памяти на хосте.

После проверки Network Interface\Packets Received Discarded счетчики производительности для наших ~ 150 виртуальных машин Windows, 22 виртуальных сетевых карт на 16 гостевых системах имели некоторые отброшенные пакеты.

Достаточно небольшая сумма, чтобы я не беспокоился о том, чтобы облагать хосты дополнительным использованием памяти, но я хочу понять, как память используется для этих настроек и откуда она берется.

Вопросы

  1. Какая связь между количеством буферов и размером кольца?
  2. Как рассчитать объем памяти, используемый для заданных значений этих настроек?
  3. Поскольку эти настройки находятся на самой сетевой карте в гостевой ОС, я предполагаю, что это настройки драйвера. Это заставляет меня думать, что используемая оперативная память может быть выгружаемым или невыгружаемым пулом.
    1. Это верно?
    2. Если да, стоит ли мне об этом беспокоиться?
  4. Есть ли опасения, которые я здесь не принимаю во внимание?

Мы пытаемся определить, есть ли недостаток в установке максимальных значений на затронутых виртуальных машинах, кроме использования памяти хоста VMware. Если мы, например, увеличиваем риск исчерпания памяти пула в гостевой системе, мы более склонны начинать с малого.

Некоторые (возможно, все) из этих вопросов могут не относиться к VMware или виртуализации.

Какая связь между количеством буферов и размером кольца?

Они связаны, но независимы. «Кольцо» rx относится к набору буферов в памяти, которые используются в качестве очереди для передачи входящих сетевых пакетов от хоста (гипервизора) к гостевой (Windows VM). Память резервируется в гостевой системе сетевым драйвером и отображается в память хоста.

Когда на хост поступают новые сетевые пакеты, они помещаются в следующий доступный буфер в кольце. Затем хост запускает IRQ в гостевой системе, на которую гостевой драйвер отвечает, снимая пакет с кольца и отправляя его в сетевой стек гостевой ОС, которая предположительно отправляет его гостевому приложению, желая принять его. Предполагая, что пакеты поступают достаточно медленно, а гостевой драйвер обрабатывает их достаточно быстро, всегда должен быть свободный слот в кольце. Однако, если пакеты поступают слишком быстро или гость обрабатывает их слишком медленно, кольцо может заполниться, и пакеты могут быть отброшены (как вы видели в своей ситуации).

Увеличение размера кольца может помочь решить эту проблему. Если вы увеличите его, на ринге будет доступно больше слотов за раз. Это переходит ко второму параметру «Small Rx Buffers», который представляет собой общее количество доступных буферов, которые можно использовать для заполнения слотов в кольце. Буферов должно быть не меньше, чем слотов в кольце. Обычно хочется большего. Когда гость снимает буфер с кольца для передачи в стек гостевой сети, он не всегда может быть немедленно возвращен обратно драйверу. Если это произойдет, наличие запасных буферов для заполнения кольца означает, что вы можете работать дольше, не отбрасывая пакеты.

Rx Ring # 1 / Small Rx Buffers используются для не-jumbo-кадров. Если у вас есть конфигурация NIC по умолчанию, это единственное кольцо, которое будет использоваться.

Как рассчитать объем памяти, используемый для заданных значений этих настроек?

Предполагая, что вы говорите о кадрах без большого размера, каждый буфер должен быть достаточно большим, чтобы хранить весь сетевой пакет, примерно 1,5 КБ. Итак, если у вас есть 8192 буфера, это займет 12 МБ. Кольцо большего размера также будет использовать больше памяти, но дескрипторы имеют небольшой размер (байты), поэтому вам действительно нужно беспокоиться о буферах.

Поскольку эти настройки находятся на самой сетевой карте в гостевой ОС, я предполагаю, что это настройки драйвера. Это заставляет меня думать, что используемая оперативная память может быть выгружаемым или невыгружаемым пулом.

Да, это невыгружаемый пул. Если кольцевые буферы были выгружены, это, вероятно, привело бы к отбрасыванию пакетов, пока буферы возвращались обратно.

Есть ли опасения, которые я здесь не принимаю во внимание?

Я не уверен, что это имеет отношение к вашей ситуации, но, возможно, стоит отметить, что более крупное кольцо увеличит объем кеш-памяти сетевого rx-пути. В микробенчмарках вы увидите, что кольцо большего размера обычно снижает производительность. Тем не менее, в реальных приложениях, если пакет теряется, это обычно больше, чем небольшой прирост производительности при всплеске скорости.

Источник: я работал в VMware.

У меня нет ответа на пункты 1-2-3, но вы можете уточнить у своего виртуального инженера конфигурацию хоста Vmware. Если он VCP, он все поймет :)

Вам действительно нужно проверить свой хост, потому что проблемы с Windows могут быть на хосте, а не в гостевой.

Есть много аппаратных функций, которые могут объяснить ваши проблемы, directpath io, rss, vcpu, схемы управления питанием ...

Я могу дать вам ссылку, которая поможет вашей виртуальной команде или вам :)

Эта ссылка посвящена настройке хоста http://buildvirtual.net/tuning-esxi-host-networking-configuration/

А этот толстый pdf:

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

А это о rss:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925

Я не в состоянии полностью искать и указывать вам на нужные страницы: поэтому я прошу вас поискать детали самостоятельно ... (извините)

В отказоустойчивом кластере есть 4 настройки, которые можно изменить; и они не будут влиять на буферы, выгружаемые или невыгружаемые ... Это меняет способ, которым отказоустойчивый кластер принимает решение считать узел "удаленным". Вот эти настройки:

SameSubnetDelay SameSubnetThreshold CrossSubnetDelay CrossSubnetThreshold

Возможно, они не решат вашу проблему, но их настройка может помочь вам в данный момент ...

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

HTH, Эдвин.