ошибки ipt_netflow в messages

сетка глючит - проверяй dmesg на linkup, linkdown на этой машине и на той, куда шлешь поток

Ну так он же пишет рекомендации:
data loss 509 pkt, 468703 bytes: increase sndbuf!

просмотрите параметры стека TCP/IP:
net.core.rmem_default
net.core.wmem_default

net.core.rmem_max
net.core.wmem_max

net.ipv4.tcp_rmem
net.ipv4.tcp_wmem

net.ipv4.udp_rmem_min
net.ipv4.udp_wmem_min

net.ipv4.tcp_mem
net.ipv4.udp_mem

и откорректируйте их в соответствии с вашими реалиями.
(Параметры приведены в терминологии файла /etc/sysctl.conf,
посмотреть например net.core.rmem_max можно командой:
cat /proc/sys/net/core/rmem_max)
man sysctl
man sysctl.conf

увеличил /proc/sys/net/netflow/sndbuf до 1024000 больше не сыпет

Просмотри и параметры о которых я писал -
система ДОЛЖНА быть сбалансирована.
Default значения стека TCP не расчитаны на большую нагрузку.

а какие цифры рекомендуешь поставть? сервак под гентой, 2 Gb RAM, через него ломится до 3000 юзеров.

net.core.rmem_default = 124928 net.core.wmem_default = 124928 net.core.rmem_max = 131071 net.core.rmem_max = 131071 net.core.wmem_max = 131071 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_wmem = 4096 16384 4194304 net.ipv4.udp_rmem_min = 4096 net.ipv4.udp_wmem_min = 4096 net.ipv4.tcp_mem = 192960 257280 385920 net.ipv4.udp_mem = 192960 257280 385920

Возможно что-то типа:

net.core.rmem_default = 262144
net.core.wmem_default = 262144
#
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
#
net.ipv4.tcp_rmem = 8192 87380 8388608
net.ipv4.tcp_wmem = 8192 65536 8388608
#
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
#
net.ipv4.tcp_mem = 8388608 12582912 16777216
net.ipv4.udp_mem = 8388608 12582912 16777216

хм, отметил для себя

еще вопрос.
можно ли снизить прожорливость ksoftirqd?
по вечерам загружает проц, изза наплыва траффика, кот проходит через сервак.
14 root 15 -5 0 0 0 R 75 0.0 7:24.21 ksoftirqd/5
10 root 15 -5 0 0 0 S 24 0.0 5:30.13 ksoftirqd/3

Нужно сделать меньше правил в iptables/tc/etc и оптимизировать их.

а по 2400 правил в tc для qdisc и class'ов это много?
для вкл. выкл юзеров используется ipset(2900 айпишников)
в iptables ок 30 правил вроде не так уж много?

и еще вечером доходит до 10000 потоков по /proc/net/stat/ipt_netflow
а по conntrack -C ~200000 пакетов.
проц 2хXeon E5402 2.00GHz(4ядра)

2400 фильтров tc много, если вы не использвете хеш таблицы.

netfilter.nf_conntrack_buckets чему равно?

net.netfilter.nf_conntrack_buckets = 16384

сделайте net.netfilter.nf_conntrack_buckets = max(net.netfilter.nf_conntrack_count)

Ну и conntrack_max должен быть больше количества потоков.

Если ната нету, есть смысл выпилить conntrack совсем. Хештаблицы применяются для шейпинга? Сколько трафика/pps ?

да, Хештаблицы применяются.
pps в conntack -C глянуть? в пик до 200000
трафика по вечерам проходит до 500 мбит.

conntrack выгрузил из ядра.

по /proc/net/stat/ipt_netflow pps ща 67000, пик гдет 200000

Если свежее ядро - соберите <kern src dir>/tools/perf и потом смотрите perf top. Когда много юзеров желательно так же не юзать sfq дисциплину, а просто pfifo/bfifo.

Что пишется в ethtool -S eth1/2/n на предмет no_buffer_count? Что делает этот роутер? Только шейпит?

------------------------------------------------------------------------------
PerfTop: 26434 irqs/sec kernel:99.1% [100000 cycles], (all, 8 CPUs)
------------------------------------------------------------------------------

samples pcnt RIP kernel function
______ _______ _____ ________________ _______________

33858.00 - 11.5% - ffffffffa008e80a : u32_classify   [cls_u32]
12225.00 - 4.2% - ffffffff812810e9 : e1000_clean
12009.00 - 4.1% - ffffffff81408916 : _spin_lock
10810.00 - 3.7% - ffffffffa007f3d3 : htb_dequeue   [sch_htb]
8703.00 - 3.0% - ffffffff81388789 : ip_route_input
8584.00 - 2.9% - ffffffff8127f375 : e1000_intr_msi
7839.00 - 2.7% - ffffffffa000108a : ipt_do_table   [ip_tables]
6822.00 - 2.3% - ffffffffa003713a : netflow_target   [ipt_NETFLOW]
5893.00 - 2.0% - ffffffff8127fa47 : e1000_xmit_frame
5849.00 - 2.0% - ffffffffa00878df : sfq_enqueue   [sch_sfq]
5814.00 - 2.0% - ffffffff81283a2b : e1000_clean_rx_irq
4954.00 - 1.7% - ffffffff8118a46c : rb_insert_color
4859.00 - 1.7% - ffffffff8127eead : e1000_clean_tx_irq
4615.00 - 1.6% - ffffffff81360abc : __alloc_skb
4586.00 - 1.6% - ffffffffa007f319 : htb_add_to_wait_tree   [sch_htb]

33858.00 - 11.5% - ffffffffa008e80a : u32_classify [cls_u32] выделено красным
eth0 (в сеть)
rx_no_buffer_count: 80667944
rx_missed_errors: 1177365
tx_deferred_ok: 302894
rx_flow_control_xon: 4262860
rx_flow_control_xoff: 4224592
tx_flow_control_xon: 33205485
tx_flow_control_xoff: 33937212
rx_long_byte_count: 6982673179332
rx_csum_offload_good: 6941107474
rx_csum_offload_errors: 19592
eth1 (в инет)
rx_no_buffer_count: 30188681
rx_missed_errors: 3609815
rx_long_byte_count: 4066461957070
rx_csum_offload_good: 6863145778
rx_csum_offload_errors: 31099

ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:      4096
RX Mini:   0
RX Jumbo:   0
TX:      4096
Current hardware settings:
RX:      256
RX Mini:   0
RX Jumbo:   0
TX:      256

чип сетевки кстати 82573...
на какие значения стоит увеличить буфер шоб _no_buffer_count не росло? попробовать сначала 1024?
сервак только шейпит

Для начала:

ethtool -G eth0 tx 4096
ethtool -G eth0 rx 4096
ethtool -K eth0 tso off
ethtool -K eth0 tso off

«с помощью smp_affinity»
каким образом?

после
ethtool -G eth0 tx 4096
ethtool -G eth0 rx 4096
ethtool -K eth0 tso off
ethtool -K eth0 tso off

линк подниместся сам? или лучше из серверной делать?

Поднимется. Через секунду. Ну если вдруг чего не случиться.

кстати в /proc/interrupts вот что. это значит, шо прерывания например сетевой карты распределяются равномерно по всем ядрам? тк. под каждым из 8 ядер стоит примерно одинаковое значение. мож не стоит тогда приязывать железку к конкретному ядру?
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
30: 243431041 243472399 244951077 244925232 244024910 244026160 244137501 244091975 PCI-MSI-edge eth0
31: 257653977 257612670 256133345 256159087 257059988 257058789 256947564 256992794 PCI-MSI-edge eth1

Если у вас только шейпинг - включайте интрефейсы бриджом, это немного разгрузит от роутинга. Если у вас ядер процессоров больше чем сетевых интерфейсов, желательно юзать сетевые с несколькими очередями, тогда вы сможете нагрузить все ядра без использования RPS. В et стоит 82576 который это умеет. Лучше брать двухпортовые или четырехпортовые карты. Я не слышал о разделении какие сетевухи для каких серверов лучше использовать, в том отношении что обычно дорогая плата (82576) всегда лучше, даже в случае веб серверов, но при малой нагрузки просто не вылазят проблемы.

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

если брать четырехпортовую et2, поддерживает ли она lacp? возможно аггрегировать первые 2 порта как eth0 вторые как eth1?

Это не зависит от сетевухи. Bonding в линуксе можно сделать как угодно.