Max P

Ну вот ts_kmp убрал - системе сильно полегчало на трафике 700-800мбит, да и покрутив таймауты коннтрака - у меня их число упало в два раза, даже с убитым ts_kmp. А hashsize это где смотреть? чот в sysctl -a не вижу такого

там есть описка да, если ставить через параметры модуля - то они имеют приоритет над rx-usecs ЗЫ. тачку пока ребутить нельзя, буду мониторить еще пару вечеров под пиковой нагрузкой, если вылезут бока - тогда ребут The sequence below sets the InterruptThrottleRate (which is rx-usecs to Ethtool) to 1 (dynamic) как то так

да везде, даже в интеловской доке именно rx-usecs за это и отвечает, поставил пока у себя rx-usecs 325 - проц поменьше кушает и задержек много не добавляет ЗЫ. а интеловский igb у меня не завелся - тупо система падала в кернел паник в момент подъема интерфейсов

а без mvr у вас не получится вынести поток с мультикастового влана на абонентский, в таком случае нужно гнать поток сразу в абонентский влан

у телесина нет mvr? вроде ж было

воткнул 1000, vmstat стал показывать nat0 perf # vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 822216 337732 1957464 0 0 0 0 0 0 0 11 89 0 0 0 0 821968 337732 1957464 0 0 0 0 51497 1575 0 7 93 0 0 0 0 822092 337732 1957464 0 0 0 32 50128 1411 0 7 93 0 0 0 0 822092 337732 1957464 0 0 0 0 48953 1371 0 7 93 0 0 0 0 822216 337732 1957464 0 0 0 44 50463 1507 0 8 92 0 0 0 0 822224 337732 1957464 0 0 0 0 49571 1366 0 11 90 0 но при этом если смотреть top - то нагрузка стала сильно неравномерной и скачет от 4 до 40% по разным ядрам

поставил rx-usecs 125, один фиг: PerfTop: 303142 irqs/sec kernel:99.3% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 8 CPUs)

хех, нашел тут же в теме: ethtool -C eth2 rx-usecs XXX где XXX=1000000/кол-во прерываний. Если мне нужно ITR ставить 1000, то делить на 1000 или все таки суммарно на 8000 (ибо 8 ядер)?

Ну собственно да, в одной пдфке наткнулся что именно rx-usecs за это и отвечает, у меня стоит 3 это dynamic conservative, не совсем только понятно можно ли туда запихать например 1000 или нет. Dark_Angle, можете посмотреть у себя что покажет ethtool -c на сетевуху?

у меня ядерный igb driver: igb version: 2.1.0-k2 ридми ядерный к нему шибко куцый в котором инфы ноль

угу, скорее всего как то через это: nat0 perf # ethtool -c eth2 Coalesce parameters for eth2: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 3 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0

хех, поставил на time_wait и syn_sent таймаут 30: nat0 etc # conntrack -C 70702 упало почти в два раза) значит таки торренты тупо забивали таблицу, ибо частенько на раздачах пиры мертвые nat0 etc # vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 758672 337464 1958264 0 0 0 0 0 0 0 11 89 0 0 0 0 758788 337464 1958264 0 0 0 16 113775 3840 0 20 80 0 0 0 0 758788 337464 1958264 0 0 0 8 116173 4055 0 20 80 0 0 0 0 758788 337464 1958264 0 0 0 0 115043 3958 0 19 81 0 0 0 0 758788 337464 1958264 0 0 0 0 113100 3788 0 20 80 0 0 0 0 758788 337464 1958264 0 0 0 76 113168 3782 0 20 80 0 0 0 0 758788 337464 1958264 0 0 0 24 114366 3874 0 20 80 0 да вот с ITR собсна пока не могу определиться, кто чего советует, оставил дефолтное драйверное, кстати а можно как то глянуть текущее значение?

да вот резать то как раз и не хотелось бы ЗЫ. а это нормально что перф топ мне показывает 300000 irq? загрузка по ядрам при этом в районе 20% на каждом PerfTop: 302087 irqs/sec kernel:99.2% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 8 CPUs)

вот кстате без ts_kmp сильно полегчало похоже, сейчас было 750мбит суммарно, 113кппс, загрузка по ядрам 22-25% максимум, обычно было уже далеко за 30%

да посмотрел траф одного из топа - очень похоже на торрент - коннекты на всякие там динамические домашние хосты с пакетами по 1460 байт - явно похоже раздачи идут возникает вопрос - а как резать? в sfq насколько я помню дефолтом 1024, как же они больше то забирают? посмотрел еще раз внимательно на conntrack -L - много SYN_SENT и TIME_WAIT, может имеет смысл еще укоротить net.netfilter.nf_conntrack_tcp_timeout_syn_sent и net.netfilter.nf_conntrack_tcp_timeout_time_wait ?

вместе с udp там вообще за 1600 на абона вылезает

понял, щаз вот пока накидал на коленке скрипт, дергает число tcp-потоков из conntrack -L для src, топ 5: src=10.19.32.87 - 1374 src=10.18.48.2 - 1070 src=10.19.33.152 - 924 src=10.19.17.155 - 763 src=10.19.33.219 - 703 1374 для одного абона это нормально? :)

да судя по oprofile он далеко не в топе, вот его стата: at0 etc # cat /proc/net/stat/ipt_netflow Flows: active 116200 (peak 142110 reached 0d22h42m ago), mem 9985K Hash: size 65535 (mem 511K), metric 2.4, 1.8, 1.0, 1.0. MemTraf: 4938350 pkt, 4317937 K (pdu 20, 1238). Timeout: active 120, inactive 15. Maxflows 2000000 Rate: 651015210 bits/sec, 99045 packets/sec; Avg 1 min: 661741075 bps, 100055 pps; 5 min: 638055253 bps, 97281 pps cpu# stat: <search found new, trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 576143028774 653136257270 42122413491, 0 0 0 0, sock: 1404076576 0 123, 2007390729 K, traffic: 695258670761, 548551217 MB, drop: 0, 0 K cpu0 stat: 38948119733 42310407071 3379367557, 0 0 0 0, sock: 0 0 123, 0 K, traffic: 45689774628, 40635257 MB, drop: 0, 0 K cpu1 stat: 8383372740 8027998477 463943110, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 8491941587, 6745511 MB, drop: 0, 0 K cpu2 stat: 40388794018 46024874431 2308853908, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 48333728339, 34089225 MB, drop: 0, 0 K cpu3 stat: 38949471234 44849572757 2222163785, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 47071736542, 33057254 MB, drop: 0, 0 K cpu4 stat: 105507401634 120996800346 7275524894, 0 0 0 0, sock: 1404076576 0 0, 2007390729 K, traffic: 128272325240, 97384926 MB, drop: 0, 0 K cpu5 stat: 135095365483 154874397618 10046211032, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 164920608650, 130281811 MB, drop: 0, 0 K cpu6 stat: 139534879722 158854424146 10168370693, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 169022794839, 132542176 MB, drop: 0, 0 K cpu7 stat: 69335624216 77197782427 6257978512, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 83455760939, 73815053 MB, drop: 0, 0 K sock0: 10.0.16.10:4444, sndbuf 16777216, filled 1, peak 5281; err: sndbuf reached 0, other 0 aggr#0 port: ports 1024-65535 replace 65535 а всё, понял насчет netflow :) да мне для него фильтры дольше городить чем conntrack -L обработать :) ибо он далеко и слишком жирный

мда, щаз ____nf_conntrack_find висит вторым в топе примерно так же как и sch_hfsc жрет

nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "TIME_WAIT" {count=count+1} END {print count}' conntrack v0.9.14 (conntrack-tools): 109922 flow entries have been shown. 33092 nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "FIN_WAIT" {count=count+1} END {print count}' conntrack v0.9.14 (conntrack-tools): 109783 flow entries have been shown. 30 nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "SYN_SENT" {count=count+1} END {print count}' conntrack v0.9.14 (conntrack-tools): 109912 flow entries have been shown. 31874 вот еще пара показателей, ща еще ресетну oprofile и еще раз стату соберу сортировать по flow - это conntrack -L отсортированный по src-адресам?

да вот кстате раньше в районе 40к крутилось, откуда 100к ща берется - непонятно, буду рыть ща да кстати, > У вас в профайлере написано "CPU: Intel Core/i7, speed 1994.99 MHz (estimated)" так и должно быть, разве ксеон не определяется как ксеон? Xeon 5504 это ядро i7, а oprofile берет описалово из ядра: Performance Events: PEBS fmt1+, Nehalem events, Intel PMU driver. Вот видимо из за nehalem и вылезает i7

ts_kmp это не шейпер :) я его грохнул уже, выше отписался что сняло примерно 5% с каждого ядра (это два правила на выпил utp болталось в форвардинге иптаблеса)

хех, вот наврал то :) оказывается еще давно conntrack малость подкрутил в sysctl.conf: net.ipv4.tcp_window_scaling = 1 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.netfilter.nf_conntrack_max = 262144 net.netfilter.nf_conntrack_generic_timeout = 180 net.netfilter.nf_conntrack_icmp_timeout = 10 net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_udp_timeout = 10 net.netfilter.nf_conntrack_udp_timeout_stream = 60 net.netfilter.nf_conntrack_tcp_be_liberal = 1

таймеры коннтрака не крутил, дефолтовые должны быть, ибо раньше не беспокоило, да и сейчас в dmesg нет ругани ядра что таблица забита в tc там хэш таблицы, каждый пакет по моим подсчетам максимум 5-6 правил там пролетает (не получается пока меньше сделать из-за серой адресации) net.netfilter.nf_conntrack_generic_timeout = 180 net.netfilter.nf_conntrack_udplite_timeout = 30 net.netfilter.nf_conntrack_udplite_timeout_stream = 180 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 net.netfilter.nf_conntrack_tcp_loose = 1 net.netfilter.nf_conntrack_tcp_be_liberal = 1 net.netfilter.nf_conntrack_tcp_max_retrans = 3 net.netfilter.nf_conntrack_udp_timeout = 10 net.netfilter.nf_conntrack_udp_timeout_stream = 60 net.netfilter.nf_conntrack_icmp_timeout = 10 net.netfilter.nf_conntrack_acct = 0 net.netfilter.nf_conntrack_max = 262144 net.netfilter.nf_conntrack_count = 104897 net.netfilter.nf_conntrack_buckets = 16384 net.netfilter.nf_conntrack_checksum = 1 net.netfilter.nf_conntrack_log_invalid = 0 net.netfilter.nf_conntrack_expect_max = 256 net.ipv4.netfilter.ip_conntrack_generic_timeout = 180 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1800 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300 net.ipv4.netfilter.ip_conntrack_tcp_loose = 1 net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3 net.ipv4.netfilter.ip_conntrack_udp_timeout = 10 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 60 net.ipv4.netfilter.ip_conntrack_icmp_timeout = 10 net.ipv4.netfilter.ip_conntrack_max = 262144 net.ipv4.netfilter.ip_conntrack_count = 104895 net.ipv4.netfilter.ip_conntrack_buckets = 16384 net.ipv4.netfilter.ip_conntrack_checksum = 1 net.ipv4.netfilter.ip_conntrack_log_invalid = 0 net.nf_conntrack_max = 262144 роуты - по бгп стягиваются с бордера маршруты с пиринговым стыком, там по realm идет отдельный tc filter, убирание тоже собсна ни на что не влияет nat0 iptables # ip r l|wc -l 413 в iptables мало чего есть, тупо доступ для ipset-сеток + набор snat для подсетей (не на каждого абона) Chain FORWARD (policy DROP 242K packets, 17M bytes) pkts bytes target prot opt in out source destination 808G 566T NETFLOW all -- eth2 eth3 0.0.0.0/0 0.0.0.0/0 NETFLOW 657G 619T NETFLOW all -- eth3 eth2 0.0.0.0/0 0.0.0.0/0 NETFLOW 702G 648T FWD-IN all -- eth3 * 0.0.0.0/0 0.0.0.0/0 857G 594T FWD-OUT all -- * eth3 0.0.0.0/0 0.0.0.0/0 Chain FWD-IN (1 references) pkts bytes target prot opt in out source destination 6043M 6256G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg178 dst 865M 394G ACCEPT all -- * * 0.0.0.0/0 10.0.0.0/16 695G 642T ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain FWD-OUT (1 references) pkts bytes target prot opt in out source destination 25M 1199M DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 match-set spammers src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg22 src 839M 452G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg21 src 113G 79T ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg20 src 605G 425T ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg19 src 126G 86T ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg18 src 684M 552G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg17 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg16 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg15 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg14 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg13 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg12 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg11 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg10 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg9 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg8 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg7 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg6 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg5 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg4 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg3 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg2 src 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg1 src 7081M 1630G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seg178 src 871M 84G ACCEPT all -- * * 10.0.0.0/16 0.0.0.0/0 INPUT я думаю тут считать особо смысла нет, ибо трафа на него напрямую практически нет, всё основное - форвард, в nat-таблице в построутинге 16 правил, всё да кстати, это показатели не на 130 кппс, снимаю сейчас в онлайне, на сетевухе 46кппс ин 44кппс оут, на второй - зеркально тоже самое

Примерно так: nat0 iptables # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "ESTABLISHED" {count=count+1} END {print count}' conntrack v0.9.14 (conntrack-tools): 99946 flow entries have been shown. 8035 nat0 iptables # conntrack -L conntrack|wc -l conntrack v0.9.14 (conntrack-tools): 100467 flow entries have been shown. 100467 nat0 iptables # cat /proc/sys/net/netfilter/nf_conntrack_count 101516 nat0 iptables # tc -p filter show dev eth2|awk '$4 ~ "/32" {count=count+1} END {print count}' 1438 nat0 iptables # tc -p filter show dev ifb0|awk '$4 ~ "/32" {count=count+1} END {print count}' 1438 в шейпере еще с десяток служебных фильтров (костяк для u32). Кстати, если сношу юзерские фильтры в tc - то нагрузка практически не падает