Мы заменили устаревший брандмауэр на этот сервер, под управлением Ubuntu 16.04.
Он не делает (почти) ничего, кроме запуска iptables примерно с 900 правилами (вместе с фильтром и натурой).
Устаревший сервер, который он заменил, работал нормально, никаких проблем не было.
Время от времени (это может быть раз в час или каждые 30 секунд) задержка между новым брандмауэром и любым другим хостом в локальной сети увеличивается с 0,1-0,2 мс до 10, 40, 100 и даже 3000 мс в течение нескольких секунд ( иногда это длится даже минуты). Я заметил это с простой задержкой ssh-соединения с хостом в DMZ (не должно быть никаких задержек), а затем протестировал его с помощью простых продолжительных высокоскоростных (-i 0.1) тестов ping для различных хостов.
Я тестировал это как на интерфейсе 10 Гбит / с, так и на одном из интерфейсов 1 Гбит / с. Сервер далеко не приближается к своим сетевым ограничениям (~ 10Kpps, 100-400mbps вверх и вниз вместе). Процессор простаивает на 99%
Во время одного из более длительных "отключений", которые я подключал к брандмауэру из Интернета для его отладки, я заметил, что никаких проблем с любым другим интерфейсом нет, и все они в порядке, без проблем с задержкой.
Чтобы исключить коммутатор из уравнения, я переместил интерфейс 1 Гбит / с на другой коммутатор за пределами нашего стека и добавил еще один сервер к новому коммутатору для тестирования. Проблема все еще сохраняется, я запускаю постоянный пинг на несколько машин, и все они время от времени увеличиваются до 2-3 секунд, включая тот, который находится в «немедленном» переключателе.
dmesg ничего не показывает, ifconfig не показывает ошибок, / proc / interrupts показывает, что все ядра участвуют в обработке nic (хотя я почти уверен, что для такой низкой пропускной способности хватит даже одного ядра ...)
Любые предложения или идеи по отладке такого сценария будут оценены.
Спасибо!
РЕДАКТИРОВАТЬ: добавление вывода ethtool:
Настройки для eno1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
РЕДАКТИРОВАТЬ 2: Возможно, это не имеет значения, но я видел это в одном из (действительно долгих) отключений:
%Cpu(s): 0.1 us, 3.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
KiB Mem : 16326972 total, 14633008 free, 296636 used, 1397328 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 15540780 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29163 root 20 0 0 0 0 S 8.0 0.0 14:08.45 kworker/4:0
31722 root 20 0 0 0 0 S 7.3 0.0 9:39.76 kworker/6:0
11677 root 20 0 0 0 0 S 5.6 0.0 0:04.65 kworker/3:1
149 root 20 0 0 0 0 S 4.0 0.0 27:21.36 kworker/2:1
46 root 20 0 0 0 0 S 0.3 0.0 0:06.93 ksoftirqd/6
Необычно высокая загрузка процессора kworker (обычно около 1%). Любая идея?
У меня была похожая ситуация, и это ссылка на сайт помогли нам решить наши проблемы!
По сути, вам, вероятно, потребуется настроить максимальный размер буфера приема TCP-сокета между 2-4 МБ, может быть, даже меньше, если это не повлияет на вашу службу, поскольку у вас так много больших всплесков.
Чтобы сравнить проблемы:
Надеюсь, это будет полезно!