Мы заменили наш устаревший брандмауэр на этот сервер , работающий под управлением Ubuntu 16.04.
Он не делает (почти) ничего, кроме запуска iptables с примерно 900 правилами (вместе filter и nat).
устаревший сервер, который он заменил, работал нормально, и никаких проблем не возникало.
Время от времени (это может быть раз в час или каждые 30 секунд) задержка между новым брандмауэром и любым другим хостом в локальной сети увеличивается с 0,1 до От 0,2 мс до 10, 40, 100 и даже 3000 мс в течение нескольких секунд (иногда даже минут). Я заметил это с простой задержкой ssh-соединения с хостом в DMZ (не должно быть никаких задержек), а затем протестировал его с помощью простых продолжительных высокоскоростных (-i 0.1) тестов ping для различных хостов.
Я тестировал это как на интерфейсе 10 Гбит / с, так и на одном из интерфейсов 1 Гбит / с. Сервер далеко не рядом ' s сетевые ограничения (~ 10Kpps, 100-400mbps вместе взятые). Процессор простаивает на 99%
Во время одного из более длительных «отключений», когда я подключался к брандмауэру из Интернета для его отладки, я заметил, что никаких проблем с любым другим интерфейсом нет, и все они в порядке, без проблем с задержкой .
Чтобы исключить коммутатор из уравнения, я переместил интерфейс 1 Гбит / с на другой коммутатор за пределами нашего стека и добавил еще один сервер к новому коммутатору для тестирования. Проблема все еще сохраняется, я запускаю постоянный пинг на несколько машин, и все они время от времени увеличиваются до 2-3 секунд, включая тот, который находится в переключателе «немедленный».
dmesg ничего не показывает, ifconfig не показывает ошибок, Возможно, это не имеет значения, но я видел это в одном из (действительно долгих) простоев:
%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 МБ, может быть, даже меньше, если это не повлияет на вашу службу, так как у вас так много больших всплесков.
Для сравнения проблем:
Надеюсь, это поможет!