> Вообще страннно, что система загибалась на таких скоростях. Я так понимаю
> фильтрации там никакой не было?
> Недавно в списке рассылки freebsd-pf@ был баг-репорт из calomel org, так ребята
> там тестили пропускную способность системы, правда на 10Gb карточках. Фря очень
> неплохо себя показала.
> https://calomel.org/network_performance.html Прочел.. Ребятки тестили на МТУ 9к - что практически в 7 раз снижает натуг для процессоров, мы ж живем в россейской реальности и не везде можно раздуть МТУ до таких величин. как раз дровишки яндекса устраняют недостаток скорости ядра процессора распаралелив обработку прерывания на несколько ядер. Опять же, МТУ в 9к возможен в пределах зоны ответственности одной сети, ежели админ пограничного роутера скажет что работает только с МТУ 1.5к то ничего не останется делать как отменить затею с увеличением МТУ. В реальной задаче имею такое (раннее утро):
bgp# netstat -w 1 -h
input (Total) output
packets errs idrops bytes packets errs bytes colls
83K 0 0 70M 83K 0 70M 0
75K 0 0 60M 76K 0 65M 0
72K 0 0 58M 73K 0 62M 0
86K 0 0 72M 85K 0 72M 0
89K 0 0 77M 91K 0 79M 0
81K 0 0 69M 80K 0 68M 0
вечером в час пик цифры будут на порядок выше.
bgp# ifconfig lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
media: Ethernet autoselect
status: active
laggproto lacp
laggport: em5 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: em4 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: em3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: em2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2600.11-MHz K8-class CPU) пара штук.
bgp# uname -a
FreeBSD bgp.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sat Jan 1 19:48:06 KRAT 2011 root@bgp.local:/usr/src/sys/amd64/compile/bgp_lagg_deb amd64
правда загрузка процессоров в час пик под 80% :)
кусок top -SCH
11 root 171 ki31 0K 64K CPU3 3 406.6H 95.46% {idle: cpu3}
11 root 171 ki31 0K 64K CPU0 0 401.4H 94.78% {idle: cpu0}
11 root 171 ki31 0K 64K RUN 2 398.8H 87.70% {idle: cpu2}
11 root 171 ki31 0K 64K CPU1 1 404.3H 86.77% {idle: cpu1}
0 root 46 0 0K 480K WAIT 3 23.0H 10.69% {em2_rx_1}
0 root 48 0 0K 480K WAIT 3 19.0H 5.37% {em5_rx_0}
0 root 47 0 0K 480K WAIT 1 23.0H 4.98% {em2_rx_2}
0 root 45 0 0K 480K WAIT 1 25.9H 4.88% {em4_rx_1}
0 root 44 0 0K 480K WAIT 0 25.6H 4.59% {em4_rx_3}
12 root -32 - 0K 512K WAIT 0 44:40 3.96% {swi4: clock}
0 root 48 0 0K 480K WAIT 0 18.3H 3.47% {em5_rx_2}
0 root 51 0 0K 480K WAIT 3 23.1H 2.88% {em2_rx_3}
0 root 45 0 0K 480K WAIT 1 872:45 2.20% {em0_rx_1}
0 root 46 0 0K 480K WAIT 1 560:09 1.56% {em1_rx_0}
0 root 51 0 0K 480K WAIT 1 22.9H 0.49% {em2_rx_0}
12 root 16 - 0K 512K WAIT 1 291:03 0.49% {swi16: em2_tx}
0 root 50 0 0K 480K WAIT 1 25.8H 0.39% {em4_rx_0}
помимо всего прочего на этой сервачине крутится ipfw + pf_nat + dummy + ng_netflow. есть желиние попробовать на свич сгрузить нат да сбор статы чтобы оценить ёмкость задачи, да все руки не доходят.
