tcpdump збільшує продуктивність udp

Я виконую набір тестів навантаження, щоб визначити продуктивність наступних налаштувань:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

Коротше кажучи, тестовий набір node.js надсилає задану кількість метрик кожні x секунд екземпляру StatsD, який знаходиться на іншому сервері. StatsD потім по черзі розмиває показники щосекунди до екземпляра Graphite, розташованого на одному сервері. Потім я розглядаю, скільки метрик насправді було надіслано тестовим набором і скільки отримано графітом для визначення втрат пакету між тестовим набором та графітом.

Однак я помітив, що інколи отримую дуже великі показники падіння пакетів (зауважте, що він надсилається за допомогою протоколу UDP), коливаючись від 20-50%. Тож саме тоді я почав розбиратися, куди скидають ці пакети, бачачи, що це може бути певна проблема з програмою StatsD. Тож я почав фіксувати показники в кожній частині системи, щоб відстежувати, де відбулася ця крапля. І ось тут речі стають дивними.

Я використовую tcpdump для створення файлу захоплення, який я перевіряю після запуску тесту. Але щоразу, коли я запускаю тести із запуском tcpdump, втрата пакету майже не існує! Схоже, tcpdump якось збільшує ефективність моїх тестів, і я не можу зрозуміти, чому і як це робиться. Я виконую наступну команду для реєстрації tcpdump повідомлень на сервері та клієнті:

tcpdump -i any -n port 8125 -w test.cap

В одному конкретному тестовому випадку я надсилаю 40000 метрик / с. Тест під час роботи tcpdump втрачає пакет близько 4%, а той, що не має втрати пакета, становить близько 20%

Обидві системи працюють як Xen VM із наступною установкою:

• Intel Xeon E5-2630 v2 при 2,60 ГГц
• 2 Гб оперативної пам’яті
• Ubuntu 14.04 x86_64

Речі, які я вже перевірив на потенційні причини:

• Збільшення розміру прийому / відправки буфера UDP.
• Навантаження процесора, що впливає на тест. (максимальне завантаження 40-50%, як для клієнта, так і для сервера)
• Запуск tcpdump на конкретних інтерфейсах замість "any".
• Запуск tcpdump з '-p' для відключення розбещеного режиму.
• Запуск tcpdump тільки на сервері. Це призвело до втрати пакетів на 20%, і, здається, це не впливає на тести.
• Запуск tcpdump тільки на клієнті. Це призвело до підвищення продуктивності.
• Збільшення netdev_max_backlog та netdev_budget до 2 ^ 32-1. Це не мало значення.
• Спробував усі можливі налаштування безладного режиму на кожній нік (сервер увімкнено та клієнт вимкнено, сервер вимкнено та клієнт увімкнено, обидва увімкнено, обидва вимкнено). Це не мало значення.

Коли tcpdump працює, він буде досить швидко під час читання у вхідних кадрах. Моя гіпотеза полягає в тому, що параметри буфера кільцевих пакетів NIC можуть бути трохи невеликими; коли запускається tcpdump, він видаляється більш своєчасно.

Якщо ви абонент Red Hat, то ця стаття підтримки дуже корисна Огляд прийому пакетів . У ньому є деякі речі, які, я думаю, ви ще не вважали.

Поміркуйте, як ваша система поводиться з IRQ; розглянути можливість збільшення 'dev_weight' мережевого інтерфейсу (мається на увазі більше пакетів, прочитаних з NIC в просторі користувача); подивіться, як часто програма читає сокет (чи може він використовувати виділений потік, чи відомі проблеми / рішення щодо масштабованості).

Збільшити буфер кадру NIC (за допомогою ethtoolкоманди - подивіться --set-ringаргументи тощо).

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

Цікаво, чи tcpdump робить щось круте, наприклад використання підтримки ядра для буферних пакетів для кільця . Це допоможе пояснити поведінку, яку ви бачите.

Який губернатор влади ви використовуєте? Я бачив подібну поведінку з "вимогою" або "консервативним" губернатором.

Спробуйте скористатися регулятором "продуктивності" та відключити будь-які функції збереження енергії в BIOS сервера.

Це щось змінює?

Інший спосіб - ip_conntarckмодуль. Ви впевнені, що ваш linux-box може прийняти нове з'єднання? тест через:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

Ви повинні пройти тестування

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

якщо max == кількість, максимальне з'єднання повна, і ваш linux-box не може прийняти нове з'єднання.
Якщо у вас немає ip_conntrack, ви можете легко завантажуватися черезmodprobe ip_conntrack

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

1. використання tcpdump на клієнті зменшує випали пакети: tcpdump уповільнює клієнт, і тому сервер бачить набагато нижчу швидкість пакета, з якою він все ще може частково обробляти. Ви повинні мати змогу підтвердити цю гіпотезу, перевіривши лічильники пакетів RX / TX як на клієнті, так і на сервері

2. Ви згадали, що збільшили розмір прийому / відправки буфера UDP, чи можете ви детально розказати, як? Важливо, щоб на сервері ви змінили і rmem_max, і rmem_default, наприклад: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

Тестування налаштувань

Зупиніть statsd і додаток для вузла, а потім у режимі очікування використовуйте iperf для тестування швидкості пакетів, з якою може працювати мережа / ядро. Якщо ви можете передавати 40K пакетів / s за допомогою iperf, але не можете зі статистикою statsd, тоді слід зосередити свої зусилля на налаштуванні statsd.

Інші зміна

Також не забудьте налаштувати net.core.netdev_max_backlog : максимальна кількість пакетів, дозволених до черги, коли певний інтерфейс отримує пакети швидше, ніж ядро ​​може обробити їх.