naguser714 Posted November 22, 2018 Posted November 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} ---------------------- Заранее спасибо! Вставить ник Quote
GrandPr1de Posted November 22, 2018 Posted November 22, 2018 На таких нагрузках забыть про любой bpf на сервере, я думаю. Но если сильно хочется - весьма рекомендую запускать tcpdump без promisc (-p), и посмотреть внимательно с какими ещё ключами запускать на предмет облегчений типо -q, -t. Вставить ник Quote
Ivan_83 Posted November 23, 2018 Posted November 23, 2018 Это не шторм прерываний, это вы в обработчике прерываний дохера делаете. 1. двухпроцовая машина для роутинга/ната зло. 2. эти утилиты не предназначены для таких нагрузок. PS: пора обновляться до 11.2, 12 уже скоро зарелизится. Вставить ник Quote
naguser714 Posted November 23, 2018 Author Posted November 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 Вставить ник Quote
Ivan_83 Posted November 24, 2018 Posted November 24, 2018 19 часов назад, naguser714 сказал: Запуск tcpdump на 10мс для сбора всего 10000 пакетов может привести к локу на 1-2 минуты. И это происходит не всегда, и как заметили только при дампе пакетов с основного интерфейса. При сборе с vlan интерфейсов, проблема не воспроизводится. Потому что: - у тебя параметр 10к пакетов отрабатывается в юзерспейсной проге, а ей ядро нахерачело 1м пакетов куда то и их надо разобрать а потом додуматся что ядру надо указать отключить этот поток - откуда ты взял что там реально 10мс - хз - в влане у тебя видимо трафика меньше, а когда ты с основного забираешь то там трафик всех вланов разгребается на самом деле Если тебе это надо то у тебя два пути: 1. ты сам разбираешься и патчишь себе ядро и софт 2. ты обновляешься хотя бы до 12.0 и пишешь в рассылку и багтрекер Да, чисто маршрутизация видимо не зависит, там схема в которой локи нужны только на запись. А вот всё что со стейтами - тут многопроцовость зло. Вставить ник Quote
naguser714 Posted November 26, 2018 Author Posted November 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 и пишешь в рассылку и багтрекер Так и понял. :) Всем спасибо за участие! Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.