Есть ли у кого-нибудь данные или базовые вычисления, которые могут ответить, когда требуется объединение кадров (NAPI) и когда достаточно одного прерывания на каждый кадр?
Мое оборудование: IBM BladeServer HS22, оборудование Broadcom 5709 Gigabit NIC (MSI-X) с двумя четырехъядерными процессорами Xeon E5530. Основное назначение - прокси-сервер Squid. Коммутатор неплохой серии Cisco 6500.
Наша основная проблема заключается в том, что в часы пик (трафик 100 Мбит / с, только 10 000 пакетов в секунду) увеличивается задержка и потеря пакетов. Я проделал большую настройку и обновил ядро до 2.6.38, и это улучшило потерю пакетов, но задержка по-прежнему оставляет желать лучшего. Пинги случаются спорадически; прыгает даже до 200 мс в локальной сети Гбит / с. Средний ответ Squid подскакивает с 30 мс до 500 + мс, даже если загрузка процессора / памяти в порядке.
Во время пика количество прерываний увеличивается примерно до 15000 в секунду. Ksoftirqd не использует много CPU; Я установил irqbalance, чтобы сбалансировать IRQ (по 8 для eth0 и eth1) на всех ядрах, но это мало помогло.
Сетевые адаптеры Intel, кажется, никогда не имеют таких проблем, но что касается блейд-системы и аппаратного обеспечения с фиксированной конфигурацией, мы как бы застряли на Broadcom.
Все указывает на сетевую карту как на главного виновника. Лучшая идея, которая у меня есть прямо сейчас, - это попытаться уменьшить количество прерываний, сохраняя при этом низкую задержку и высокую пропускную способность.
К сожалению, bnx2 не поддерживает adaptive-rx или tx.
В NAPI против адаптивных прерываний Ответ в потоке дает отличный обзор модерации прерываний, но не дает конкретной информации о том, как рассчитать оптимальные настройки объединения ethtool для данного обходного пути. Есть ли лучший подход, чем метод проб и ошибок?
Нужен ли NAPI для упомянутой выше рабочей нагрузки и аппаратной конфигурации? Или он должен иметь возможность работать с одним прерыванием на пакет?
Отличный вопрос, заставивший меня почитать, чтобы попытаться понять это. Хотел бы я сказать, что у меня есть ответ ... но, может быть, несколько намеков.
Я могу, по крайней мере, ответить на ваш вопрос: «Должен ли он работать с одним прерыванием на пакет». Я думаю, что да, учитывая очень загруженный межсетевой экран, к которому у меня есть доступ:
Выход Sar:
03:04:53 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
03:04:54 PM lo 93.00 93.00 6.12 6.12 0.00 0.00 0.00
03:04:54 PM eth0 115263.00 134750.00 13280.63 41633.46 0.00 0.00 5.00
03:04:54 PM eth8 70329.00 55480.00 20132.62 6314.51 0.00 0.00 0.00
03:04:54 PM eth9 53907.00 66669.00 5820.42 21123.55 0.00 0.00 0.00
03:04:54 PM eth10 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth11 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth2 146520.00 111904.00 45228.32 12251.48 0.00 0.00 10.00
03:04:54 PM eth3 252.00 23446.00 21.34 4667.20 0.00 0.00 0.00
03:04:54 PM eth4 8.00 10.00 0.68 0.76 0.00 0.00 0.00
03:04:54 PM eth5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth6 3929.00 2088.00 1368.01 183.79 0.00 0.00 1.00
03:04:54 PM eth7 13.00 17.00 1.42 1.19 0.00 0.00 0.00
03:04:54 PM bond0 169170.00 201419.00 19101.04 62757.00 0.00 0.00 5.00
03:04:54 PM bond1 216849.00 167384.00 65360.94 18565.99 0.00 0.00 10.00
Как вы можете видеть, некоторые очень высокие пакеты в секунду считаются, и на этой машине не было сделано никаких специальных настроек ethtool. Ох ... Хотя чипсет Intel. : \
Единственное, что было сделано - это ручная балансировка irq с помощью / proc / irq / XXX / smp_affinity для каждого интерфейса. Я не уверен, почему они решили пойти этим путем вместо irqbalance, но, похоже, это работает.
Я также подумал о математике, необходимой для ответа на ваш вопрос, но я думаю, что существует слишком много переменных. Итак ... резюмируя, на мой взгляд, ответ - нет, я не думаю, что вы можете предсказать здесь результаты, но с достаточным количеством данных вы сможете настроить его на лучший уровень.
Сказав все это, я чувствую, что вы здесь каким-то образом привязаны к оборудованию ... как в прошивке или какой-либо ошибке взаимодействия.
Конечно, учитывая возможности ЦП, набора микросхем и шины по сравнению с таким низким объемом трафика, у вас нет никаких причин НУЖАТЬСЯ в какой-либо форме управления прерываниями. У нас есть несколько 64-битных машин RHEL 5.3 с сетевыми адаптерами 10 Гбит / с, и их прерывания совсем не так уж плохи, это в 100 раз меньше.
Очевидно, у вас фиксированная конфигурация (я использую лезвия HP, которые очень похожи), поэтому замена сетевых адаптеров на Intel теперь является простым вариантом, но я бы сказал, что я начинаю замечать ряд похожих проблем на этом форуме и в других местах. с этой конкретной сетевой картой Broadcom. Когда-либо сами сайты SE имели некоторые проблемы с такого рода несогласованностью, и переход на сетевые карты Intel абсолютно помог.
Я бы порекомендовал выбрать один blade-сервер и добавить адаптер на базе Intel к этой машине, вам, очевидно, придется добавить межсоединение или что-то еще, что IBM называет им, чтобы получить сигнал, но попробуйте ту же настройку программного обеспечения, но с этим другим Сетевая карта (возможно, отключите Broadcom, если сможете). Протестируйте это и посмотрите, как у вас дела. Я знаю, что для того, что я описал, требуется пара дополнительных компонентов, но я полагаю, что ваш представитель IBM с радостью одолжит вам их. Это единственный способ узнать наверняка. Пожалуйста, дайте нам знать, что вы узнали, мне искренне интересно, есть ли проблемы с этими сетевыми картами, даже если это необычный крайний случай. Кстати, на следующей неделе я встречаюсь с Intel и Broadcom, чтобы обсудить что-то совершенно не связанное с этим, но я обязательно обсудю это с ними и дам вам знать, если найду что-нибудь интересное.
Вопрос о прерываниях заключается в том, как они влияют на общую производительность системы. Прерывания могут вытеснить обработку земли пользователем и ядром, и, хотя вы можете не заметить большого использования ЦП, происходит много переключений контекста, что сильно снижает производительность. Ты можешь использовать vmstat и проверьте system столбец cs заголовок для прерываний и переключений контекста в секунду (прерывания включают часы, поэтому вы должны взвесить их), его тоже стоит проверить.
Короткий прямой ответ:
Если вы включите опрос, вы уменьшите переключение контекста (обычно из-за прерываний) с того, что они есть сейчас (15kips в вашем случае) до заранее определенного числа (обычно от 1k до 2k).
Если у вас в настоящее время трафик превышает заранее установленное число, тогда у вас должно быть лучшее время ответа, если включить опрос. Обратное также верно. Я бы не сказал, что это «необходимо», если только переключение контекста не влияет на производительность.
В заключение: с выгруженными модулями NAT и conntrack и минимизированным набором правил iptables мы получаем потрясающую производительность. Балансировщик нагрузки IPVS сделал более 900 Мбит / с / 150 тыс. Пакетов в секунду. Это при том же чипсете Broadcom bnx2.
Итак, в заключение: обработка прерываний кажется прекрасной, и настройки по умолчанию для Debian с ядром 2.6.38 / 3.0.x кажутся приемлемыми.
Определенно, я бы предпочел использовать сетевые карты Intel, чтобы мы могли использовать стандартные пакеты Debian. Борьба с несвободной прошивкой bnx2 была огромной тратой времени.