Які мережеві навантаження потребують опитування NIC та переривань?

Хтось має якісь дані або основні розрахунки, які можуть відповісти, коли потрібна коалесценція кадру (NAPI) і коли достатньо одного переривання на кадр?

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

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

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

Intel NIC, здається, ніколи не має подібних проблем, але, маючи на увазі факт роботи лопатевої системи та обладнання фіксованої конфігурації, ми начебто застрягли з Broadcoms.

Все вказує на НІК як на головного винуватця. Найкраща ідея, яку я маю зараз, - спробувати зменшити переривання, зберігаючи як затримку низької, так і високу пропускну здатність.

На жаль, bnx2 не підтримує адаптивну-rx або tx.

Відповідь потоку NAPI vs Adaptive Interrupts надає велику оцінку модерації переривань, але не містить конкретної інформації про те, як обчислити оптимальні налаштування з'єднання ettool для даного вирішення. Чи є кращий підхід, аніж спроба та помилка?

Чи потрібне вищезазначене навантаження та конфігурація обладнання навіть NAPI? Або вона повинна жити на одному перериванні за пакет?

Чудове запитання, яке мало мені читати, щоб спробувати це зрозуміти. Хотілося б сказати, що я маю відповідь ... але, можливо, деякі підказки.

Я, принаймні, можу відповісти на ваше запитання, "чи має можливість жити на одному перериванні за пакет". Я думаю, що відповідь "так" на основі дуже зайнятого брандмауера, до якого я маю доступ:

Вихід Сар:

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

Як бачите, деякі дуже високі пакети в секунду рахуються, і на цій машині не було зроблено спеціальних налаштувань ettool. О, хоча чіпсет Intel : \

Єдине, що було зроблено - це ручне балансування irq з / proc / irq / XXX / smp_affinity, на основі інтерфейсу. Я не впевнений, чому вони вирішили піти цим шляхом замість нерівності, але, здається, це спрацює.

Я також думав про математику, необхідну для відповіді на ваше запитання, але я думаю, що існує занадто багато змінних. Отже ... підводячи підсумок, на мою думку, відповідь "ні", я не думаю, що ви можете передбачити результати тут, але, маючи достатній обсяг даних, ви повинні мати можливість налаштувати його на кращий рівень.

Сказавши все це, я відчуваю, що ти тут якось пов'язаний з апаратним забезпеченням ... як у прошивці чи інтегральній помилці.

Безумовно, враховуючи можливості процесора, чіпсета та шини порівняно з таким низьким обсягом трафіку, у вас немає жодної причини для того, щоб ПОТРІБНО будь-яка форма управління перериваннями. У нас є кілька 64-розрядних машин RHEL 5.3 з NIC 10Gbps і їх переривання зовсім не дуже погано, це в 100 разів менше.

Очевидно, у вас фіксована конфігурація (я використовую леза HP, які досить схожі), тому заміна NIC для Intel тепер є простим варіантом, але, що я б сказав, це те, що я починаю помічати ряд подібних проблем на цьому форумі та в інших місцях з цим конкретним Broadcom NIC. Коли-небудь у самих веб-сайтів SE були якісь проблеми з подібною невідповідністю, і заміни на Intel NIC абсолютно допомогли.

Що я б рекомендував, це вибрати один лезо та додати на цю машину адаптер на базі Intel, очевидно, вам доведеться додати з'єднання або все, що IBM викликає їх, щоб отримати сигнал, але спробуйте те саме налаштування програмного забезпечення, але з цим іншим NIC (можливо, вимкніть Broadcom, якщо можете). Перевірте це і подивіться, як ви дістаєтесь, я знаю, що я описав, потрібно кілька біт додаткового обладнання, але я думаю, що ваш представник IBM з радістю позичить вам їх. Це єдиний спосіб точно знати. Будь ласка, повідомте нам, що ви дізнаєтесь, я щиро зацікавлений, якщо є проблеми з цими НІК, навіть якщо це незвичайний край. Як осторонь я зустрічаюся з Intel та Broadcom на наступному тижні, щоб обговорити щось абсолютно не пов’язане, але я, безумовно, обговорюю це з ними і повідомляю, якщо я знайду щось цікаве.

Питання про переривання полягає в тому, як вони впливають на загальну продуктивність системи. Переривання можуть перешкоджати обробці земель користувача та ядра, і, хоча ви не бачите багато використання процесора, відбувається чимало контекстних комутацій, і це є великим хітом продуктивності. Ви можете використовувати vmstatта перевіряти systemстовпчик, csзаголовок на переривання та контекстні комутатори в секунду (переривання включають годинник, тому ви повинні зважити це в), його також варто перевірити.

Коротка пряма відповідь:

Якщо ввімкнути опитування, ви зменшите контекстні комутатори (як правило, через переривання) з будь-якого вони зараз (15кіп у вашому випадку) до заздалегідь визначеного числа (зазвичай від 1 до 2 к).

Якщо у вас поточний трафік вище заздалегідь визначеного числа, вам слід мати кращі часи відгуку, включивши опитування. Зворотна також правда. Я б не сказав, що це "необхідно", якщо контекстні перемикачі не впливають на продуктивність.

Для подальших дій: з вивантаженими модулями NAT і conntrack плюс мінімізованим набором правил iptables ми отримуємо приголомшливі показники. Балансир навантаження IPVS зробив більше 900 Мбіт / 150 кпс. Це поки використовується ті ж набори чіпів Broadcom bnx2.

Отже, підсумовуючи: обробка переривань здається прекрасною, а за замовчуванням для Debian з ядром 2.6.38 / 3.0.x здається, що він працює прийнятно.

Безумовно, я вважаю за краще використовувати Intel NIC, щоб ми могли використовувати стандартні пакети Debian. Боротьба з невільною прошивкою bnx2 - це велика витрата часу.