Justas Опубликовано 7 октября, 2011 · Жалоба Идея с бондингом прокатила :) Объединил интерфейсы в бонд, бонд развел на виланы, экспериментально подобраны параметры options bond0 miimon=100 mode=4 xmit_hash_policy=layer3+4 В этом случае приходящий на NIC пакет в моем случае всегда будет отправлен через этот же NIC. Нагрузка на процессоры снизилась в 2-2,3 раза. Живем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 17 октября, 2011 · Жалоба Имею двухядерный Xeon E5502, две встроенных сетевых (одна из которых 82574L с поддержкой MSI-X и отдельных очередей на приём/передачу) и одна двухголовая сетевая на 82571EB. Сейчас на замену едут два новых четырёхядерных E5606. Сервер дохнет уже при 35-40 kpps, причём настолько, что запросто отваливается userspace и удалённо по шеллу ничего не возможно сделать. С параметрами модуля e1000e ещё не игрался. В изначальной конфигурации в порты двухголовой сетевой заведены два аплинка (100-150 Мбит/с в каждом), отдаётся через встроенную внутрь сети. С чего начать? Объединять по примеру выше двухголовую сетевую в бонд? Купить что-нибудь другое? Поглядываю на Intel I350T2, отзывов пока особо нету, но характеристики вроде неплохие. Кто что скажет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 17 октября, 2011 · Жалоба Intel i350-T2 - это всё тот же чип i82580 у i340 программно обрезаны фичи по сравнению c i350. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 18 октября, 2011 · Жалоба параметрами модуля e1000e ещё не игрался Модуль нужно брать igb, интеловский. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 19 октября, 2011 · Жалоба параметрами модуля e1000e ещё не игрался Модуль нужно брать igb, интеловский. А разница? Они же для разных чипов вроде. Кто что по делу может посоветовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 19 октября, 2011 · Жалоба Сервер дохнет уже при 35-40 kpps это очень мало. проверь, куда подключены сетёвки. если к южному мосту - то плохо. Там между северным и южным мостом тоненький линк, сетёвки нужно переставить в слоты, которые подключены к северному мосту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 октября, 2011 · Жалоба параметрами модуля e1000e ещё не игрался Модуль нужно брать igb, интеловский. А разница? Они же для разных чипов вроде. Кто что по делу может посоветовать? Неа. Один - ядерный, второй - интеловский. Интеловский как-то получше себя ведет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 октября, 2011 · Жалоба igb собссно и ванильный ядерный и интеловский есть. Как и e1000e. Поддержкой чипов таки отличаются (первый - для чипов без множества RX очередей, типа 82571...574), второй - для чипов с несколькими очередями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d1m0n Опубликовано 24 октября, 2011 · Жалоба Опишу как у нас, так сказать для общей статистики. Железо следующее: Xeon X3430 на серверной матери Asus с парой встроенных сетевух 82574L. Функции: бордер, NAT, HTB шейпер, простенький фаервол. Суммарно (up-down) 200-250 Мбит/с переваривает особо не напрягаясь, ядерный драйвер е1000е v. 1.3.10-k2. Замечания: после перехода на 3-ю ветку ядра с версии 2.6.30 заметно снизилась нагрузка на процессор и схема группировки прерываний по типу "rx одного интерфейса с tx другого интерфейса на одном ядре процессора" показала себя с лучшей стороны с сравнении со схемой "rx1 - 1 ядро, tx1 - 2 ядро, rx2 - 3 ядро, tx2 - 4 ядро", но при этом 2 ядра практически простаивают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 30 октября, 2011 (изменено) · Жалоба граждане, а это что за фигня может быть такая?: -------------------------------------------------------------------------------------------------------------------- PerfTop: 6224 irqs/sec kernel:99.9% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) -------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ________________________ ___________________________________________________________ 32919.00 58.8% _raw_spin_lock /lib/modules/2.6.38-gentoo-r4/build/vmlinux 5445.00 9.7% rb_next /lib/modules/2.6.38-gentoo-r4/build/vmlinux 3513.00 6.3% hfsc_dequeue /lib/modules/2.6.38-gentoo-r4/kernel/net/sched/sch_hfsc.ko 998.00 1.8% ____nf_conntrack_find /lib/modules/2.6.38-gentoo-r4/build/vmlinux 786.00 1.4% u32_classify /lib/modules/2.6.38-gentoo-r4/kernel/net/sched/cls_u32.ko 778.00 1.4% hfsc_enqueue /lib/modules/2.6.38-gentoo-r4/kernel/net/sched/sch_hfsc.ko 768.00 1.4% igb_poll /lib/modules/2.6.38-gentoo-r4/kernel/drivers/net/igb/igb.ko 585.00 1.0% ipt_do_table /lib/modules/2.6.38-gentoo-r4/build/vmlinux 546.00 1.0% ip_route_input_common /lib/modules/2.6.38-gentoo-r4/build/vmlinux иногда встает колом nat+шейпер сервер, то есть работает нормально всё, может сутками и месяцами работать, а иногда сваливается в такую вот фигню, из-за этого лаги и тормоза Изменено 30 октября, 2011 пользователем Max P Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 30 октября, 2011 · Жалоба ну вот, отлегло: -------------------------------------------------------------------------------------------------------- PerfTop: 6715 irqs/sec kernel:99.9% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) -------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ________________________ ___________________________________________________________ 2766.00 13.8% _raw_spin_lock /lib/modules/2.6.38-gentoo-r4/build/vmlinux 1620.00 8.1% ____nf_conntrack_find /lib/modules/2.6.38-gentoo-r4/build/vmlinux 1148.00 5.7% hfsc_enqueue /lib/modules/2.6.38-gentoo-r4/kernel/net/sched/sch_hfsc.ko 884.00 4.4% ip_route_input_common /lib/modules/2.6.38-gentoo-r4/build/vmlinux 852.00 4.3% u32_classify /lib/modules/2.6.38-gentoo-r4/kernel/net/sched/cls_u32.ko 703.00 3.5% ipt_do_table /lib/modules/2.6.38-gentoo-r4/build/vmlinux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 30 октября, 2011 · Жалоба Вообщем железка - Intel Corporation S5520UR/S5520UR + 2x Xeon5504, 4 гига памяти, основная сетевуха - двухпортовая Intel E1G42ET PCIe:2.5Gb/s:Width x4 чип 82576. В момент начала лага трафик суммарно 800 Мбит/сек на каждом порту (примерно по 130кппс). Из задач - нат и шейпер hfsc+u32. Из тюнинга сетевух - ring-буфер 3096 на каждом порту + каждый вектор на свое ядро с размазыванием примерно поровну по всем ядрам. Загрузка ядер около 45-50%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 30 октября, 2011 · Жалоба Max P, А какое ядро? Было похожее, помог откат на .35. Новые еще не пробовал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 30 октября, 2011 · Жалоба 2.6.38-gentoo-r4, накатывал в связи с патчем на багу в nf_conntrack, из-за которой валилось в кернел-паник. Кто по опыту может сказать - есть у железки запас или там процы пора на помойку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 · Жалоба Идея с бондингом прокатила :) Объединил интерфейсы в бонд, бонд развел на виланы, экспериментально подобраны параметры options bond0 miimon=100 mode=4 xmit_hash_policy=layer3+4 В этом случае приходящий на NIC пакет в моем случае всегда будет отправлен через этот же NIC. Нагрузка на процессоры снизилась в 2-2,3 раза. Живем. а со стороны коммутатора как bond настроен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 31 октября, 2011 · Жалоба Ну дело точно не в процессорах, т.к. spin lock - это когда процесс ожидает открытия лока для дальнеших действий, т.е. ожидает используя ресурсы. Я не знаю точно что именно у вас лочит процессор, но обратите внимание на наличия, почти 10% rb_next() в сценарии, когда всё встает и отсутствия его в другой ситуации. Так же посмотрите, нет ли вызовов этой функции ( raw_spin_lock ) из модулей nf_conntrack_find и hfsc_enqueue(). Может у вас флудом ложит роутер. Бывало такое. Ну и пробуйте ставить стабильное ядро. r4 может содержать и куда более неприятные баги. Есть же ванильное уже 2.6.38.8 причем давно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 · Жалоба а вообще сколько такая тачка должна выжимать? ну чтобы просто ориентироваться когда ее надо будет на помойку :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 (изменено) · Жалоба грепнул по сорцам, нашел вот что из интересного: drivers/net/igb/igb.mod.c: { 0x6443d74d, "_raw_spin_lock" }, в нфконтраке ничего интересного, в hfsc: net/sched/sch_hfsc.mod.c: { 0x87a45ee9, "_raw_spin_lock_bh" }, Как еще можно отследить эту фигню? А может вообще 3.0.7 запилить и сделать CONFIG_BKL=n? Изменено 31 октября, 2011 пользователем Max P Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 (изменено) · Жалоба намутил oprofile, сейчас выглядит примерно так: nat0 linux # opreport Overflow stats not available CPU: Intel Core/i7, speed 1994.99 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 2377660 60.4641 vmlinux 623544 15.8568 ts_kmp 284603 7.2375 sch_hfsc 185418 4.7152 igb 131025 3.3320 cls_u32 97077 2.4687 ipt_NETFLOW 87187 2.2172 sch_sfq 41262 1.0493 ip_set 18499 0.4704 ifb 12907 0.3282 oprofiled 9678 0.2461 act_mirred 8792 0.2236 ip_set_ipmap 7500 0.1907 xt_string а вот тут внизу видно эти самые -rb* CPU: Intel Core/i7, speed 1994.99 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name app name symbol name 1052114 15.8590 ts_kmp ts_kmp /ts_kmp 479346 7.2254 sch_hfsc sch_hfsc /sch_hfsc 312361 4.7083 igb igb /igb 297534 4.4849 vmlinux vmlinux ____nf_conntrack_find 230518 3.4747 vmlinux vmlinux __netif_receive_skb 221516 3.3390 cls_u32 cls_u32 /cls_u32 217198 3.2739 vmlinux vmlinux ipt_do_table 201562 3.0382 vmlinux vmlinux sch_direct_xmit 196503 2.9620 vmlinux vmlinux ip_route_input_common 163733 2.4680 ipt_NETFLOW ipt_NETFLOW /ipt_NETFLOW 152459 2.2981 vmlinux vmlinux mwait_idle 147339 2.2209 sch_sfq sch_sfq /sch_sfq 140162 2.1127 vmlinux vmlinux dev_queue_xmit 112586 1.6971 vmlinux vmlinux __slab_alloc 89383 1.3473 vmlinux vmlinux apic_timer_interrupt 84317 1.2709 vmlinux vmlinux rb_erase 83787 1.2630 vmlinux vmlinux irq_entries_start 76702 1.1562 vmlinux vmlinux kmem_cache_alloc 69211 1.0432 ip_set ip_set /ip_set 58276 0.8784 vmlinux vmlinux kfree 57737 0.8703 vmlinux vmlinux rb_first 54641 0.8236 vmlinux vmlinux rb_insert_color 53344 0.8041 vmlinux vmlinux kmem_cache_free 47888 0.7218 vmlinux vmlinux __slab_free 46298 0.6979 vmlinux vmlinux rb_last Изменено 31 октября, 2011 пользователем Max P Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 · Жалоба хм, интересно, в perf top не видно ts_kmp, а в опрофайле видно, оказалось у меня там два правила болталось для зарезания utp трафа, снял референс на них - нагрузка упала процентов на 5 на каждом ведре Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 31 октября, 2011 · Жалоба Судя по всему у вас много шейперов и ната. Можете показать количество сессий НАТ и количество фильтров у шейпера? Если говорить о емкости то такой и 10Г может потянуть на тупом роутинге наверное. 130 Kpps - это точно не его. 82576 - отличный чип, я его сам юзаю. Уткнутся в его потолок не реально. Я думаю, что у вас либо ядро с багами, либо реально много навесили на роутер. Я вообще рекомендую посмотреть в сторону 2.6.27 ядра, если никакие новые фичи из свежих ядер вам не надо. Из моих наблюдений оно самое быстрое и безпроблемное. Для 1 Гбита его даже напильником ровнять не надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 · Жалоба Примерно так: 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 - то нагрузка практически не падает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 31 октября, 2011 (изменено) · Жалоба А как у вас получается при 130 Kpps 100K записей в таблице НАТ? Пакет = запись? Не хорошо. Кроме того вы таймеры для сессий подкрутили? Можете показать какие у вас? Нагрузка от снятия фильтров не может не падать, т.к. у вас минимум 3 функции оттуда в топе: шедулинг пакета, классификация, продвижение по цепочке. Я уже не говорю про то что фильтров 1.5К. Посмотрите профайлер после убирания фильтров. Еще, кстати, iptables выступает не плохо у вас, покажите тоже. Ну и давайте таблицу роутинга по размеру оценим, чтобы понять откуда ip_route_input_common(). Ну и в любом случае, на скоростях больше 100 Мбит, иметь 1.5К фильтров на шейпинг - это непозволительная роскош. Хеш таблицы же. Я уже не говорю про интефейс ifb0 который, я так понимаю есть заворачивание входящих пакетов туда? Это тоже не про роутер. Изменено 31 октября, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 (изменено) · Жалоба таймеры коннтрака не крутил, дефолтовые должны быть, ибо раньше не беспокоило, да и сейчас в 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кппс оут, на второй - зеркально тоже самое Изменено 31 октября, 2011 пользователем Max P Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 31 октября, 2011 (изменено) · Жалоба хех, вот наврал то :) оказывается еще давно 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 Изменено 31 октября, 2011 пользователем Max P Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...