[naguser714]

Здравствуйте, уважаемые эксперты!

Не сталкивался кто-нибудь со следующей проблемой. После оптимизации ipfw правил, переодически начали получать блокировку сервера (FreeBSD 10.3) на 1-2 минуты при попытке запуска диагностических утилит iftop/tcpdump. Запуск top в фоне показал, что сервер захлёбывается сетевыми прерываниями в это время:

---------------

last pid:  2317;  load averages: 50.31, 25.49, 12.85  up 9+10:50:12    16:35:25
261 processes: 31 running, 139 sleeping, 91 waiting
CPU:  0.0% user,  0.0% nice,  0.0% system, 99.8% interrupt,  0.1% idle
Mem: 13M Active, 7367M Inact, 1453M Wired, 1949M Buf, 7023M Free
Swap: 32G Total, 32G Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
   12 root          -92    -     0K  1552K WAIT    6  37.8H 100.00% intr{irq309: ix0:q6}
   12 root          -92    -     0K  1552K CPU5    5  37.4H 100.00% intr{irq308: ix0:q5}
   12 root          -92    -     0K  1552K WAIT    4  36.9H 100.00% intr{irq307: ix0:q4}
   12 root          -92    -     0K  1552K WAIT    3  36.8H 100.00% intr{irq306: ix0:q3}
   12 root          -92    -     0K  1552K WAIT    1  36.5H 100.00% intr{irq304: ix0:q1}
   12 root          -92    -     0K  1552K WAIT    7  36.2H 100.00% intr{irq310: ix0:q7}
   12 root          -92    -     0K  1552K CPU8    8  36.0H 100.00% intr{irq311: ix0:q8}
   12 root          -92    -     0K  1552K WAIT    2  35.9H 100.00% intr{irq305: ix0:q2}
   12 root          -92    -     0K  1552K CPU9    9  35.8H 100.00% intr{irq312: ix0:q9}
   12 root          -92    -     0K  1552K WAIT   10  35.7H 100.00% intr{irq313: ix0:q10}
   12 root          -92    -     0K  1552K CPU13  13  35.7H 100.00% intr{irq316: ix0:q13}
   12 root          -92    -     0K  1552K WAIT   15  35.5H 100.00% intr{irq318: ix0:q15}
   12 root          -92    -     0K  1552K CPU12  12  35.5H 100.00% intr{irq315: ix0:q12}
   12 root          -92    -     0K  1552K WAIT   11  35.4H 100.00% intr{irq314: ix0:q11}
   12 root          -92    -     0K  1552K WAIT   14  35.3H 100.00% intr{irq317: ix0:q14}
   12 root          -92    -     0K  1552K WAIT    0  36.5H  99.27% intr{irq303: ix0:q0}
    0 root          -92    -     0K  1232K -       3 570:16   2.59% kernel{dummynet}
5034 root           21    0 36092K  6088K CPU6    6   1:08   0.78% zebra
-------------------

 

Сервер используется для маршрутизации ~3Гбит трафика (вход + выход), скорость пересылки достигает ~1Mpps (вход + выход). До оптимизации ipfw, нагрузка на процессор в ЧНН достигала 70-80%, после упала на 20%, но начались вышеописанные проблемы. К примеру, следующие команды могут залочить сервер:

iftop -n -i ix0 -f 'host 8.8.8.8'

tcpdump -n -i ix0 -c 10000 -w /tmp/test.pcap

 

По железу, стоит двухпроцессорная система по 8 реальных ядер на каждом (HT отключен) и сетевая 10Г карта Intel 82599ES.

Как я понимаю, проводя меньше времени в ipfw коде, пакеты больше подвержены каким-то локам. Либо, после оптимизации поднялся PPS и проблема начала проявляться. В ЧНН нагрузка на процессор следующая:

--------------
last pid: 96942;  load averages:  2.54,  2.78,  2.86                                                                          up 1+08:41:17  13:37:09
247 processes: 19 running, 133 sleeping, 95 waiting
CPU:  0.0% user,  0.0% nice,  0.5% system, 18.4% interrupt, 81.1% idle
Mem: 8244K Active, 67M Inact, 1079M Wired, 5344K Cache, 1722M Buf, 14G Free
Swap: 32G Total, 32G Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
   12 root          -92    -     0K  1552K WAIT    1 319:33  18.90% intr{irq304: ix0:q1}
   12 root          -92    -     0K  1552K WAIT    2 321:07  18.80% intr{irq305: ix0:q2}
   12 root          -92    -     0K  1552K WAIT   10 307:41  18.80% intr{irq313: ix0:q10}
   12 root          -92    -     0K  1552K WAIT   13 317:14  18.65% intr{irq316: ix0:q13}
   12 root          -92    -     0K  1552K WAIT    8 306:12  18.16% intr{irq311: ix0:q8}
   12 root          -92    -     0K  1552K CPU14  14 308:14  17.29% intr{irq317: ix0:q14}
   12 root          -92    -     0K  1552K WAIT    0 320:28  17.09% intr{irq303: ix0:q0}
   12 root          -92    -     0K  1552K WAIT    3 307:38  17.09% intr{irq306: ix0:q3}
   12 root          -92    -     0K  1552K WAIT    7 301:48  17.09% intr{irq310: ix0:q7}
   12 root          -92    -     0K  1552K WAIT    5 318:14  16.99% intr{irq308: ix0:q5}
   12 root          -92    -     0K  1552K WAIT    6 314:38  16.99% intr{irq309: ix0:q6}
   12 root          -92    -     0K  1552K WAIT   12 299:17  16.99% intr{irq315: ix0:q12}
   12 root          -92    -     0K  1552K WAIT   11 300:40  16.80% intr{irq314: ix0:q11}
   12 root          -92    -     0K  1552K WAIT    9 296:23  16.80% intr{irq312: ix0:q9}
   12 root          -92    -     0K  1552K WAIT   15 307:43  16.46% intr{irq318: ix0:q15}
   12 root          -92    -     0K  1552K CPU4    4 316:50  15.19% intr{irq307: ix0:q4}
----------------------

 

 

Заранее спасибо!

[GrandPr1de]

На таких нагрузках забыть про любой bpf на сервере, я думаю.

Но если сильно хочется - весьма рекомендую запускать tcpdump без promisc (-p), и посмотреть внимательно с какими ещё ключами запускать на предмет облегчений типо -q, -t.

[Ivan_83]

Это не шторм прерываний, это вы в обработчике прерываний дохера делаете.

1. двухпроцовая машина для роутинга/ната зло.

2. эти утилиты не предназначены для таких нагрузок.

 

PS: пора обновляться до 11.2, 12 уже скоро зарелизится.

[naguser714]

5 hours ago, Ivan_83 said:

Это не шторм прерываний, это вы в обработчике прерываний дохера делаете.

Запуск tcpdump на 10мс для сбора всего 10000 пакетов может привести к локу на 1-2 минуты. И это происходит не всегда, и как заметили только при дампе пакетов с основного интерфейса. При сборе с vlan интерфейсов, проблема не воспроизводится.

 

 

6 hours ago, Ivan_83 said:

1. двухпроцовая машина для роутинга/ната зло.

По нату не скажу, но второй процессор не снижает производительность маршрутизации. Имею в виду, что если отключить второй процессор, то производительность не поднимется, но произойдёт обратное. Это подтверждается в свежем отчёте (пункт I) по маршрутизации FreeBSD [1]

 

 

6 hours ago, Ivan_83 said:

PS: пора обновляться до 11.2, 12 уже скоро зарелизится.

Да, понимаю. Есть пара сдерживающих факторов.

 

 

[1] https://people.freebsd.org/~olivier/talks/2018_AsiaBSDCon_Tuning_FreeBSD_for_routing_and_firewalling-Paper.pdf

[Ivan_83]

19 часов назад, naguser714 сказал:

Запуск tcpdump на 10мс для сбора всего 10000 пакетов может привести к локу на 1-2 минуты. И это происходит не всегда, и как заметили только при дампе пакетов с основного интерфейса. При сборе с vlan интерфейсов, проблема не воспроизводится.

Потому что:

- у тебя параметр 10к пакетов отрабатывается в юзерспейсной проге, а ей ядро нахерачело 1м пакетов куда то и их надо разобрать а потом додуматся что ядру надо указать отключить этот поток

- откуда ты взял что там реально 10мс - хз

- в влане у тебя видимо трафика меньше, а когда ты с основного забираешь то там трафик всех вланов разгребается на самом деле

 

Если тебе это надо то у тебя два пути:

1. ты сам разбираешься и патчишь себе ядро и софт

2. ты обновляешься хотя бы до 12.0 и пишешь в рассылку и багтрекер

 

Да, чисто маршрутизация видимо не зависит, там схема в которой локи нужны только на запись. А вот всё что со стейтами - тут многопроцовость зло.

[naguser714]

On 11/24/2018 at 7:26 AM, Ivan_83 said:

Потому что:

- у тебя параметр 10к пакетов отрабатывается в юзерспейсной проге, а ей ядро нахерачело 1м пакетов куда то и их надо разобрать а потом додуматся что ядру надо указать отключить этот поток

- откуда ты взял что там реально 10мс - хз

- в влане у тебя видимо трафика меньше, а когда ты с основного забираешь то там трафик всех вланов разгребается на самом деле

Проблема проявляется не постоянно, 1 раз из 5-10. Обычно, сбор 10к пакетов у меня занимает 10мс из расчёта 1Mpps (вход + выход).

 

 

On 11/24/2018 at 7:26 AM, Ivan_83 said:

Если тебе это надо то у тебя два пути:

1. ты сам разбираешься и патчишь себе ядро и софт

2. ты обновляешься хотя бы до 12.0 и пишешь в рассылку и багтрекер

Так и понял. :)

 

Всем спасибо за участие!