L2TP termination / mpd5 / CPU usage

Vladimir Yesakov написал(а) к Eugene Grosbein в Mar 15 19:37:47 по местному времени:


Нello Eugene!

03 Mar 15 20:28, I wrote to you:

VY> Я заранее прошу прощения, длинновато получилось...

Дошли у меня наконец-то руки закончить с этим сервером...

VY>>> В идеале хотелось бы получить полные 10G с сервера... ( карточка
VY>>> на 2 порта, в один принимаем l2tp, а в другом Internet )
EG>> Это может быть нетривиально, но пробуй.

Кому лень читать все, то сразу выводы:

1) Фря 9.3 некорректно работает с двумя процессорами. Вынимание одного никак не влияет на общую производительность системы при данном конкретном виде нагрузки. Возможно, что на этой контретной маме (SuperMicro X9DRT). 10.0 у меня на такой же задаче вешалась при 1k сессий (примерно), а 10.1 я не пробовал.

2) Похоже если взять один процессор, но побыстрее и с большим числом ядер, то до 10GB добратся будет можно. Процессор, правда под 2 килобакса, встанет, но Cisco с 10G интерфейсами (подержанная) все равно тянет на $15k.

Теперь детали.

VY> PPS взяты с "netstat -i 1"

Текущие данные (до пика еще 2 часа...)
=== Cut ===
input (Total) output
packets errs idrops bytes packets errs bytes colls
859206 0 0 515649102 1085071 7 1214621518 0
947910 0 0 581993230 1216279 4 1321367893 0
953823 0 0 581299125 1222578 6 1387690664 0
925894 0 0 566564259 1184950 7 1354310104 0
877375 0 0 527778823 1109854 7 1271385911 0
924253 0 0 549384743 1166242 7 1287634128 0
939129 0 0 564925817 1196570 6 1330810876 0
953851 0 0 569204225 1212750 3 1351247171 0
949041 0 0 568973122 1212448 9 1367340259 0
=== Cut ===

Похоже Фря не может эффективно использовать 2 CPU Sockets. Я вынул один процессор и включил НT (чтоб прибивку к ядрам не править, вдруг пришлось бы срочно откатывать на 2 CPU). Картина сильно изменилась по PMCSTAT и практически без изменений по TOP -SНIP:

=== Cut ===
PMC: [INSTRRETIREDANY] Samples: 148752 (100.0%) , 0 unresolved

%SAMP IMAGE FUNCTION CALLERS
5.6 kernel mtx_lock_sleep _mtx_lockflags
4.9 kernel cpusearch_lowest cpu_searchlowest
4.7 kernel mtx_lock_spin wakeup_one:2.5 _sleep:0.9 turnstiletrywait:0.7
4.6 pmcstat _init
4.1 kernel rw_rlock ng_address_hook:1.8 rtalloc1fib:0.8
3.2 kernel rnmatch rtalloc1fib
2.7 kernel rw_runlock ng_address_hook:1.1 arpresolve:0.6 rtalloc1fib:0.5
2.4 kernel inpcblookup_hash_lo in_pcblookuphash
2.1 netgraph.k ngsnd_item ng_applyitem
1.9 libc.so.7 bsearch
1.7 kernel ipoutput ip_forward:0.9 udpsend:0.8
1.7 kernel umazallocarg
1.6 kernel atomicfetchadd_int ng_unref_hook:0.9 ng_unrefnode:0.7
1.4 kernel bzero
1.4 kernel umazfree_arg mfreem
1.3 kernel ixgbexmit ixgbe_mq_startlocked
1.3 kernel ixgberxeof ixgbe_msixque
1.2 kernel spinlock_exit
1.2 kernel mtx_unlockflags ngthread
1.1 kernel criticalexit spinlockexit
1.1 mpd5 _init
=== Cut ===

=== Cut ===
CPU 0: 1.6% user, 0.0% nice, 25.5% system, 48.6% interrupt, 24.3% idle
CPU 1: 0.0% user, 0.0% nice, 19.6% system, 51.0% interrupt, 29.4% idle
CPU 2: 0.4% user, 0.0% nice, 22.0% system, 49.0% interrupt, 28.6% idle
CPU 3: 2.4% user, 0.0% nice, 30.2% system, 41.2% interrupt, 26.3% idle
CPU 4: 0.8% user, 0.0% nice, 24.3% system, 51.0% interrupt, 23.9% idle
CPU 5: 0.8% user, 0.0% nice, 25.9% system, 47.5% interrupt, 25.9% idle
CPU 6: 0.0% user, 0.0% nice, 40.0% system, 26.7% interrupt, 33.3% idle
CPU 7: 0.8% user, 0.0% nice, 35.3% system, 23.5% interrupt, 40.4% idle
CPU 8: 2.0% user, 0.0% nice, 39.6% system, 27.1% interrupt, 31.4% idle
CPU 9: 1.2% user, 0.0% nice, 31.8% system, 32.5% interrupt, 34.5% idle
CPU 10: 0.8% user, 0.0% nice, 43.1% system, 19.6% interrupt, 36.5% idle
CPU 11: 2.4% user, 0.0% nice, 38.4% system, 27.8% interrupt, 31.4% idle
Mem: 3550M Active, 360M Inact, 1889M Wired, 1859M Buf, 9987M Free
Swap: 2897M Total, 2897M Free

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
12 root -92 - 0K 1072K WAIT 0 209:14 51.17% intr{irq282: ix0:que }
12 root -92 - 0K 1072K WAIT 2 192:46 50.00% intr{irq284: ix0:que }
12 root -92 - 0K 1072K WAIT 5 192:21 49.17% intr{irq287: ix0:que }
12 root -92 - 0K 1072K CPU4 4 186:24 49.07% intr{irq286: ix0:que }
12 root -92 - 0K 1072K CPU1 1 200:22 47.85% intr{irq283: ix0:que }
12 root -92 - 0K 1072K CPU3 3 185:22 43.90% intr{irq285: ix0:que }
705 root -16 - 0K 192K sleep 4 143:01 35.06% ngqueue{ngqueue4}
705 root -16 - 0K 192K sleep 1 142:32 35.06% ngqueue{ngqueue3}
705 root -16 - 0K 192K sleep 0 143:00 34.77% ngqueue{ngqueue7}
705 root -16 - 0K 192K CPU5 5 142:39 34.77% ngqueue{ngqueue0}
705 root -16 - 0K 192K sleep 1 142:28 34.77% ngqueue{ngqueue6}
705 root -16 - 0K 192K sleep 5 142:13 34.77% ngqueue{ngqueue5}
705 root -16 - 0K 192K CPU2 2 143:01 34.57% ngqueue{ngqueue10}
705 root -16 - 0K 192K CPU6 6 142:47 34.47% ngqueue{ngqueue1}
705 root -16 - 0K 192K sleep 3 142:27 34.47% ngqueue{ngqueue9}
705 root -16 - 0K 192K sleep 10 141:55 34.47% ngqueue{ngqueue8}
705 root -16 - 0K 192K sleep 0 141:55 34.08% ngqueue{ngqueue11}
705 root -16 - 0K 192K CPU4 4 141:57 33.69% ngqueue{ngqueue2}
11 root 155 ki31 0K 192K CPU10 10 654:42 33.59% idle{idle: cpu10}
11 root 155 ki31 0K 192K CPU9 9 640:42 31.40% idle{idle: cpu9}
11 root 155 ki31 0K 192K RUN 7 654:16 31.05% idle{idle: cpu7}
11 root 155 ki31 0K 192K CPU6 6 638:41 30.27% idle{idle: cpu6}
11 root 155 ki31 0K 192K RUN 8 635:37 29.05% idle{idle: cpu8}
12 root -92 - 0K 1072K WAIT 11 124:46 28.86% intr{irq294: ix1:que }
12 root -92 - 0K 1072K WAIT 8 141:02 27.78% intr{irq291: ix1:que }
12 root -92 - 0K 1072K WAIT 6 134:53 27.20% intr{irq289: ix1:que }
11 root 155 ki31 0K 192K RUN 11 637:22 26.95% idle{idle: cpu11}
12 root -92 - 0K 1072K WAIT 9 135:50 25.88% intr{irq292: ix1:que }
11 root 155 ki31 0K 192K RUN 3 612:49 25.10% idle{idle: cpu3}
12 root -92 - 0K 1072K WAIT 7 109:33 24.66% intr{irq290: ix1:que }
11 root 155 ki31 0K 192K CPU1 1 607:12 24.17% idle{idle: cpu1}
11 root 155 ki31 0K 192K RUN 4 608:57 24.07% idle{idle: cpu4}
11 root 155 ki31 0K 192K RUN 5 609:14 23.68% idle{idle: cpu5}
11 root 155 ki31 0K 192K RUN 0 598:29 23.19% idle{idle: cpu0}
11 root 155 ki31 0K 192K RUN 2 606:10 22.07% idle{idle: cpu2}
701 root 43 0 1007M 269M select 4 225:22 20.26% mpd5{mpd5}
12 root -92 - 0K 1072K WAIT 10 92:41 16.36% intr{irq293: ix1:que }
=== Cut ===

Как мы видим - "sched_idletd" исчез совсем. Больше никто никого не ждет, похоже...

VY> CPU загружен 40% system, 40% interrupt и pmcstat показывает такую
VY> вот фигню:

PMC>: [INSTRRETIREDANY] Samples: 123604 (100.0%) , 1069 unresolved

VY> %SAMP IMAGE FUNCTION CALLERS
VY> 11.9 kernel schedidletd forkexit
VY> 5.1 kernel rw_rlock rtalloc1fib:1.8
VY> ngaddress_hook:1.7 5.1 kernel _mtx_locksleep
VY> mtx_lock_flags 4.3 kernel _mtx_lock_spin wakeupone:1.9
VY> turnstiletrywait:0.9 pmclog_reserve:0.8 sleep:0.6 4.1 kernel
VY> selectcheck_badfd kern_select 2.4 kernel _rwrunlock
VY> ngaddress_hook:0.9 arpresolve:0.5 2.3 kernel rnmatch
VY> rtalloc1fib 2.3 kernel cpu_search_lowest cpu_searchlowest:1.4
VY> schedpickcpu:0.9 2.1 pmcstat init 2.0 kernel
VY> inpcblookup_hash_lo in_pcblookuphash

Один вопрос пока остается.
Как я понимаю дополнительной фрагментации быть не должно. Все виртуальные интерфейсы настроены с MTU 1492, а на другой стороне MTU 1500, без VLAN или какого-либо тунелирования.

VY> трафика примерно одинаково, а PPS в три раза отличается

И кстати прерываний тоже втрое больше.

VY> Я уже подумываю, а не выдернуть ли один CPU и посмотреть что будет?

Выдернул. Получил то, что и ожидал...

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Valentin Davydov написал(а) к Vladimir Yesakov в Mar 15 12:11:35 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Vladimir Yesakov <Vladimir.Yesakov@p202.f58.n461.z2.fidonet.org>
> Date: Thu, 19 Mar 2015 19:37:47 +0300
>
> VY> Я заранее прошу прощения, длинновато получилось...
>
> Дошли у меня наконец-то руки закончить с этим сервером...
>
> VY>>> В идеале хотелось бы получить полные 10G с сервера... ( карточка
> VY>>> на 2 порта, в один принимаем l2tp, а в другом Internet )
> EG>> Это может быть нетривиально, но пробуй.
>
> Кому лень читать все, то сразу выводы:
>
>1) Фря 9.3 некорректно работает с двумя процессорами. Вынимание одного никак не
>влияет на общую производительность системы при данном конкретном виде нагрузки.
>Возможно, что на этой контретной маме (SuperMicro X9DRT). 10.0 у меня на такой
>же задаче вешалась при 1k сессий (примерно), а 10.1 я не пробовал.

Как и говорилось с самого начала. DDR память - штука медленная.

>2) Похоже если взять один процессор, но побыстрее и с большим числом ядер, то
>до 10GB добратся будет можно. Процессор, правда под 2 килобакса, встанет, но

Чтобы добраться до 10 GB, достаточно одноядерного процессора о девятистах
мегагерцах (см. статью Луиджи про netmap). Так что более быстрый процессор
тебе вряд ли поможет, память-то останется та же самая. Надо прежде всего
алгоритмы оптимизировать, в направлении уменьшения числа копирований данных
из памяти в память. Т.е. обрабатывать пакеты прямо в том буфере, куда их
сетевая карта складывает. Как это сделано в том же нетмапе, в bpf с опцией
BPFBUFMODEZEROCOPY и т.д.

Как я понимаю, у тебя ведь просто роутер, то есть полтора килобайта тела
пакета перелопачивать не надо, достаточно поправить несколько полей в
заголовках и отправить пакет дальше, так? В этом случае от zero copy
как раз больше всего толка.

>Cisco с 10G интерфейсами (подержанная) все равно тянет на $15k.

Да ещё и не факт, что циска потянет нагрузку без проблем.

>Теперь детали.
>
> VY> PPS взяты с "netstat -i 1"
>
>Текущие данные (до пика еще 2 часа...)
>=== Cut ===
> input (Total) output
> packets errs idrops bytes packets errs bytes colls
> 859206 0 0 515649102 1085071 7 1214621518 0
> 947910 0 0 581993230 1216279 4 1321367893 0
> 953823 0 0 581299125 1222578 6 1387690664 0
> 925894 0 0 566564259 1184950 7 1354310104 0
> 877375 0 0 527778823 1109854 7 1271385911 0
> 924253 0 0 549384743 1166242 7 1287634128 0
> 939129 0 0 564925817 1196570 6 1330810876 0
> 953851 0 0 569204225 1212750 3 1351247171 0
> 949041 0 0 568973122 1212448 9 1367340259 0
>=== Cut ===
>
>Похоже Фря не может эффективно использовать 2 CPU Sockets. Я вынул один
>процессор и включил НT (чтоб прибивку к ядрам не править, вдруг пришлось бы
>срочно откатывать на 2 CPU). Картина сильно изменилась по PMCSTAT и практически
>без изменений по TOP -SНIP:

Теперь убери пиннинг и выключи гипертрединг. Производительность при этом не
ухудшится, каналы-то останутся теми же самыми, а вот проценты полегчают.

>Как мы видим - "sched_idletd" исчез совсем. Больше никто никого не ждет,
>похоже...

Гипертрединг - это аппаратное ожидание, оно в твоей статистике не
показывается.

>Один вопрос пока остается.
>Как я понимаю дополнительной фрагментации быть не должно. Все виртуальные
>интерфейсы настроены с MTU 1492, а на другой стороне MTU 1500, без VLAN или
>какого-либо тунелирования.

Ежели в обратную сторону пойдёт 1500-байтный пакет - то его таки придётся
либо фрагментировать, либо дропать и слать соответствующий icmp в надежде,
что у отправителя pmtud сработает.

Вал. Дав.

--- ifmail v.2.15dev5.4

Vladimir Yesakov написал(а) к Valentin Davydov в Mar 15 18:41:46 по местному времени:

* Replying to a msg in CARBON.AREA (CARBON.AREA)

Нello Valentin!

20 Mar 15 12:11, you wrote to me:
>> VY>>> В идеале хотелось бы получить полные 10G с сервера... (
>> карточка на 2 порта, в один принимаем l2tp, а в другом Internet )

VD> Как и говорилось с самого начала. DDR память - штука медленная.

>> 2) Похоже если взять один процессор, но побыстрее и с большим
>> числом ядер, то до 10GB добратся будет можно. Процессор, правда под 2
>> килобакса, встанет, но
VD> Чтобы добраться до 10 GB, достаточно одноядерного процессора о
VD> девятистах мегагерцах (см. статью Луиджи про netmap).

Читал. Знатная статья и разработка, но к сожалению далеко не весь софт (mpd5 например) заточен под ntemap-API.

VD> Так что более быстрый процессор тебе вряд ли поможет, память-то
VD> останется та же самая. Надо прежде всего алгоритмы оптимизировать, в
VD> направлении уменьшения числа копирований данных из памяти в память.
VD> Т.е. обрабатывать пакеты прямо в том буфере, куда их сетевая карта
VD> складывает. Как это сделано в том же нетмапе, в bpf с опцией
VD> BPFBUFMODEZEROCOPY и т.д.

Если есть хоть какое-нибудь руководство как к моей ситуации прикрутить netmap, на любом языке, дай ссылку. Я долго и безуспешно искал.

VD> Как я понимаю, у тебя ведь просто роутер, то есть полтора килобайта
VD> тела пакета перелопачивать не надо, достаточно поправить несколько
VD> полей в заголовках и отправить пакет дальше, так? В этом случае от
VD> zero copy как раз больше всего толка.

Мне L2TP разворачивать надо. Т.е. обработка присутствует. Вот где я про другой сервер писал, там да - просто роутер. И проблем с ним нет. За наводку на bpf - ZERO COPY отдельное спасибо. Посмотрю внимательно.

>> Cisco с 10G интерфейсами (подержанная) все равно тянет на $15k.
VD> Да ещё и не факт, что циска потянет нагрузку без проблем.

Заявлено, что должна. Обещают 64k l2tp сессий, 20GB throughput. (ASR1004)

VD> Теперь убери пиннинг и выключи гипертрединг. Производительность при
VD> этом не ухудшится, каналы-то останутся теми же самыми, а вот проценты
VD> полегчают.

До "убрать пиннинг" я сам уже дошел, но по другой причине...

VD> Гипертрединг - это аппаратное ожидание, оно в твоей статистике не
VD> показывается.

Понял, спасибо. И если без пиннинга, то на каждом порту количество очередей должно быть равно количеству ядер ? И для net.isr тоже ?

>> Один вопрос пока остается.
>> Как я понимаю дополнительной фрагментации быть не должно. Все
>> виртуальные интерфейсы настроены с MTU 1492, а на другой стороне MTU
>> 1500, без VLAN или какого-либо тунелирования.

VD> Ежели в обратную сторону пойдёт 1500-байтный пакет - то его таки
VD> придётся либо фрагментировать, либо дропать и слать соответствующий
VD> icmp в надежде, что у отправителя pmtud сработает.

Это верно, но не в 3 раза же! А у меня в три... Опять таки на другом сервере где нет mpd5 такой проблемы тоже нет. Там везде MTU 1500, но нет туннелей.

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Valentin Davydov написал(а) к Vladimir Yesakov в Mar 15 15:15:16 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Vladimir Yesakov <Vladimir.Yesakov@p202.f58.n461.z2.fidonet.org>
> Date: Fri, 20 Mar 2015 18:41:46 +0300
>
> VD> Так что более быстрый процессор тебе вряд ли поможет, память-то
> VD> останется та же самая. Надо прежде всего алгоритмы оптимизировать, в
> VD> направлении уменьшения числа копирований данных из памяти в память.
> VD> Т.е. обрабатывать пакеты прямо в том буфере, куда их сетевая карта
> VD> складывает. Как это сделано в том же нетмапе, в bpf с опцией
> VD> BPFBUFMODEZEROCOPY и т.д.
>
> Если есть хоть какое-нибудь руководство как к моей ситуации прикрутить
>netmap, на любом языке, дай ссылку. Я долго и безуспешно искал.

На l2tp вряд ли. Под FreeBSD единственная более-менее работающая имплементация
это mpd5, а он тесно связан не с нетмапом, а совсем наоборот, с нетграфом,
который каждый пакет шинкует на mbufы, пересобирает их в цепочки, рекурсивно
вызывает функции разных узлов и делает прочие весьма интересные программистам
вещи.

С нуля же переписывать - долго. Разве что найдётся энтузиаст, но это
вряд ли: обычно люди склонны зниматься чем-то более полезным, нежели l2tp.

Вал. Дав.
--- ifmail v.2.15dev5.4