Сервер Ubuntu: странные скачки задержки в локальной сети

Мы заменили наш устаревший брандмауэр на этот сервер , работающий под управлением 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%). Есть идеи?

2
задан 13 January 2017 в 18:20
1 ответ

У меня была похожая ситуация, и эта ссылка помогла нам решить наши проблемы!

По сути, вам, вероятно, потребуется настроить максимальный размер буфера приема сокета TCP на от 2 до 4 МБ, может быть, даже меньше, если это не повлияет на вашу службу, так как у вас так много больших всплесков.

Для сравнения проблем:

  • Большое количество здорового трафика с кажущимися случайными, массивными всплесками лагов, которые могут длиться в течение длительного периода времени.
  • Вы подтвердили, что проблема связана с вашим новым брандмауэром.
  • Все ваши данные тестирования говорят вам, что проблемы нет.
  • Это очень случайная, кажущаяся случайной задержка между получением пакета ОС и его обработкой.

Надеюсь, это поможет!

1
ответ дан 3 December 2019 в 12:37

Теги

Похожие вопросы