Какие нагрузки сети требуют опроса NIC против прерываний?

Есть ли у кого-нибудь какие-либо данные или базовые вычисления, которые могут дать ответ, когда требуется объединение кадров (NAPI) и когда достаточно одного прерывания на кадр?

Мое оборудование: IBM BladeServer HS22, аппаратное обеспечение Broadcom 5709 Gigabit NIC (MSI-X) с двумя четырехъядерными процессорами Xeon E5530. Основное назначение - прокси-сервер Squid. Коммутатор - хорошая серия Cisco 6500.

Наша основная проблема заключается в том, что в периоды пиковой нагрузки (трафик 100 Мбит / с, всего 10 000 ппс) эта задержка и потеря пакетов увеличиваются. Я сделал много настроек и обновил ядро ​​до 2.6.38, и это улучшило потерю пакетов, но задержка все еще мала. Пинги спорадические; прыжки даже до 200 мс в локальной сети Gbps. Средний ответ Squid изменяется с 30 мс до 500 + мс, хотя загрузка процессора / памяти в порядке.

Прерывания достигают примерно 15 000 в секунду во время пика. Ksoftirqd не использует много процессора; Я установил irqbalance для балансировки IRQ (по 8 для eth0 и eth1) по всем ядрам, но это не сильно помогло.

Сетевые адаптеры Intel, похоже, никогда не сталкивались с подобными проблемами, но из-за факта наличия блейд-системы и аппаратного обеспечения с фиксированной конфигурацией мы застряли с Broadcoms.

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

К сожалению, bnx2 не поддерживает adaptive-rx или tx.

NAPI против Адаптивные Прерывания нити ответа обеспечивает отличный вид прерываний умеренности , но нет информации бетонной о том , как рассчитать оптимальный Ethtool COALESCE настройки для данного временного решения. Есть ли лучший подход, чем просто метод проб и ошибок?

Нужна ли вышеупомянутая рабочая нагрузка и конфигурация оборудования даже 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 теперь простой вариант, но я бы сказал, что я начинаю замечать ряд подобных проблем в этом и других форумах. с этим конкретным NIC Broadcom. Когда-либо на самих сайтах SE возникали проблемы с такого рода несоответствиями, и переход на сетевые адаптеры Intel абсолютно помог.

Что я бы порекомендовал, так это выбрать один блейд и добавить адаптер Intel на эту машину, вам, очевидно, придется добавить межсоединение или, как IBM их называет, чтобы получить сигнал, но попробовать ту же настройку программного обеспечения, но с этим другим NIC (возможно, отключите 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 была огромной тратой времени.