Перейти к содержимому
Калькуляторы

Идея с бондингом прокатила :) Объединил интерфейсы в бонд, бонд развел на виланы, экспериментально подобраны параметры

 

options bond0 miimon=100 mode=4 xmit_hash_policy=layer3+4

 

В этом случае приходящий на NIC пакет в моем случае всегда будет отправлен через этот же NIC.

 

Нагрузка на процессоры снизилась в 2-2,3 раза. Живем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имею двухядерный Xeon E5502, две встроенных сетевых (одна из которых 82574L с поддержкой MSI-X и отдельных очередей на приём/передачу) и одна двухголовая сетевая на 82571EB.

Сейчас на замену едут два новых четырёхядерных E5606. Сервер дохнет уже при 35-40 kpps, причём настолько, что запросто отваливается userspace и удалённо по шеллу ничего не возможно сделать. С параметрами модуля e1000e ещё не игрался. В изначальной конфигурации в порты двухголовой сетевой заведены два аплинка (100-150 Мбит/с в каждом), отдаётся через встроенную внутрь сети.

С чего начать? Объединять по примеру выше двухголовую сетевую в бонд? Купить что-нибудь другое? Поглядываю на Intel I350T2, отзывов пока особо нету, но характеристики вроде неплохие. Кто что скажет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Intel i350-T2 - это всё тот же чип i82580

у i340 программно обрезаны фичи по сравнению c i350.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

параметрами модуля e1000e ещё не игрался

Модуль нужно брать igb, интеловский.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

параметрами модуля e1000e ещё не игрался

Модуль нужно брать igb, интеловский.

А разница? Они же для разных чипов вроде.

 

Кто что по делу может посоветовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сервер дохнет уже при 35-40 kpps

это очень мало.

проверь, куда подключены сетёвки. если к южному мосту - то плохо. Там между северным и южным мостом тоненький линк, сетёвки нужно переставить в слоты, которые подключены к северному мосту.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

параметрами модуля e1000e ещё не игрался

Модуль нужно брать igb, интеловский.

А разница? Они же для разных чипов вроде.

 

Кто что по делу может посоветовать?

Неа.

Один - ядерный, второй - интеловский.

Интеловский как-то получше себя ведет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

igb собссно и ванильный ядерный и интеловский есть. Как и e1000e. Поддержкой чипов таки отличаются (первый - для чипов без множества RX очередей, типа 82571...574), второй - для чипов с несколькими очередями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу как у нас, так сказать для общей статистики. Железо следующее: 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 ядра практически простаивают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

граждане, а это что за фигня может быть такая?:

--------------------------------------------------------------------------------------------------------------------
  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+шейпер сервер, то есть работает нормально всё, может сутками и месяцами работать, а иногда сваливается в такую вот фигню, из-за этого лаги и тормоза

Изменено пользователем Max P

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну вот, отлегло:

 

--------------------------------------------------------------------------------------------------------
  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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообщем железка - Intel Corporation S5520UR/S5520UR + 2x Xeon5504, 4 гига памяти, основная сетевуха - двухпортовая Intel E1G42ET PCIe:2.5Gb/s:Width x4 чип 82576. В момент начала лага трафик суммарно 800 Мбит/сек на каждом порту (примерно по 130кппс). Из задач - нат и шейпер hfsc+u32. Из тюнинга сетевух - ring-буфер 3096 на каждом порту + каждый вектор на свое ядро с размазыванием примерно поровну по всем ядрам. Загрузка ядер около 45-50%.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Max P,

А какое ядро? Было похожее, помог откат на .35. Новые еще не пробовал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2.6.38-gentoo-r4, накатывал в связи с патчем на багу в nf_conntrack, из-за которой валилось в кернел-паник. Кто по опыту может сказать - есть у железки запас или там процы пора на помойку?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Идея с бондингом прокатила :) Объединил интерфейсы в бонд, бонд развел на виланы, экспериментально подобраны параметры

 

options bond0 miimon=100 mode=4 xmit_hash_policy=layer3+4

 

В этом случае приходящий на NIC пакет в моем случае всегда будет отправлен через этот же NIC.

 

Нагрузка на процессоры снизилась в 2-2,3 раза. Живем.

а со стороны коммутатора как bond настроен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну дело точно не в процессорах, т.к. spin lock - это когда процесс ожидает открытия лока для дальнеших действий, т.е. ожидает используя ресурсы.

 

Я не знаю точно что именно у вас лочит процессор, но обратите внимание на наличия, почти 10% rb_next() в сценарии, когда всё встает и отсутствия его в другой ситуации. Так же посмотрите, нет ли вызовов этой функции ( raw_spin_lock ) из модулей nf_conntrack_find и hfsc_enqueue(). Может у вас флудом ложит роутер. Бывало такое.

 

Ну и пробуйте ставить стабильное ядро. r4 может содержать и куда более неприятные баги. Есть же ванильное уже 2.6.38.8 причем давно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а вообще сколько такая тачка должна выжимать? ну чтобы просто ориентироваться когда ее надо будет на помойку :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

грепнул по сорцам, нашел вот что из интересного:

 

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?

Изменено пользователем Max P

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

намутил 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

Изменено пользователем Max P

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хм, интересно, в perf top не видно ts_kmp, а в опрофайле видно, оказалось у меня там два правила болталось для зарезания utp трафа, снял референс на них - нагрузка упала процентов на 5 на каждом ведре

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Судя по всему у вас много шейперов и ната. Можете показать количество сессий НАТ и количество фильтров у шейпера?

 

Если говорить о емкости то такой и 10Г может потянуть на тупом роутинге наверное. 130 Kpps - это точно не его. 82576 - отличный чип, я его сам юзаю. Уткнутся в его потолок не реально. Я думаю, что у вас либо ядро с багами, либо реально много навесили на роутер. Я вообще рекомендую посмотреть в сторону 2.6.27 ядра, если никакие новые фичи из свежих ядер вам не надо. Из моих наблюдений оно самое быстрое и безпроблемное. Для 1 Гбита его даже напильником ровнять не надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Примерно так:

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 - то нагрузка практически не падает

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как у вас получается при 130 Kpps 100K записей в таблице НАТ? Пакет = запись? Не хорошо. Кроме того вы таймеры для сессий подкрутили? Можете показать какие у вас?

 

Нагрузка от снятия фильтров не может не падать, т.к. у вас минимум 3 функции оттуда в топе: шедулинг пакета, классификация, продвижение по цепочке. Я уже не говорю про то что фильтров 1.5К. Посмотрите профайлер после убирания фильтров. Еще, кстати, iptables выступает не плохо у вас, покажите тоже. Ну и давайте таблицу роутинга по размеру оценим, чтобы понять откуда ip_route_input_common().

 

Ну и в любом случае, на скоростях больше 100 Мбит, иметь 1.5К фильтров на шейпинг - это непозволительная роскош. Хеш таблицы же. Я уже не говорю про интефейс ifb0 который, я так понимаю есть заворачивание входящих пакетов туда? Это тоже не про роутер.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

таймеры коннтрака не крутил, дефолтовые должны быть, ибо раньше не беспокоило, да и сейчас в 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кппс оут, на второй - зеркально тоже самое

Изменено пользователем Max P

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хех, вот наврал то :) оказывается еще давно 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

Изменено пользователем Max P

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.