naguser714 Опубликовано 22 ноября, 2018 · Жалоба Здравствуйте, уважаемые эксперты! Не сталкивался кто-нибудь со следующей проблемой. После оптимизации 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} ---------------------- Заранее спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 22 ноября, 2018 · Жалоба На таких нагрузках забыть про любой bpf на сервере, я думаю. Но если сильно хочется - весьма рекомендую запускать tcpdump без promisc (-p), и посмотреть внимательно с какими ещё ключами запускать на предмет облегчений типо -q, -t. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 ноября, 2018 · Жалоба Это не шторм прерываний, это вы в обработчике прерываний дохера делаете. 1. двухпроцовая машина для роутинга/ната зло. 2. эти утилиты не предназначены для таких нагрузок. PS: пора обновляться до 11.2, 12 уже скоро зарелизится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
naguser714 Опубликовано 23 ноября, 2018 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 ноября, 2018 · Жалоба 19 часов назад, naguser714 сказал: Запуск tcpdump на 10мс для сбора всего 10000 пакетов может привести к локу на 1-2 минуты. И это происходит не всегда, и как заметили только при дампе пакетов с основного интерфейса. При сборе с vlan интерфейсов, проблема не воспроизводится. Потому что: - у тебя параметр 10к пакетов отрабатывается в юзерспейсной проге, а ей ядро нахерачело 1м пакетов куда то и их надо разобрать а потом додуматся что ядру надо указать отключить этот поток - откуда ты взял что там реально 10мс - хз - в влане у тебя видимо трафика меньше, а когда ты с основного забираешь то там трафик всех вланов разгребается на самом деле Если тебе это надо то у тебя два пути: 1. ты сам разбираешься и патчишь себе ядро и софт 2. ты обновляешься хотя бы до 12.0 и пишешь в рассылку и багтрекер Да, чисто маршрутизация видимо не зависит, там схема в которой локи нужны только на запись. А вот всё что со стейтами - тут многопроцовость зло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
naguser714 Опубликовано 26 ноября, 2018 · Жалоба 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 и пишешь в рассылку и багтрекер Так и понял. :) Всем спасибо за участие! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...