kayot Опубликовано 28 июня, 2013 (изменено) · Жалоба 1) Очереди сетевок в таком тестировании не работают ибо источник-получатель имеют по 1 mac'у. 2) Ядро для такого железа слишком древнее. Есть вероятность что что-то программно глючит. 3) Сервер похоже в глубоком энергосбережении находится, или опять же какой-то драйвер глючит. Изменено 28 июня, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 29 июня, 2013 · Жалоба ядро 2.6.32 уже давно умерло и плохо пахнет. в 2.6.35 добавили rps, в 2.6.36 - xps. в 2.6.39 выкинули BLK. вообщем, берите свежий(3.9) софт и тестируйте заново. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 1 июля, 2013 · Жалоба ^rage^, спасибо за рекомендацю, поставили самое новое ядро до упора, те же цифры :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 1 июля, 2013 · Жалоба В студию: dmesg после загрузки, perf top где "упирается _spin_lock в perf top", таблицу маршрутизации, arp таблицу. icmp_send выше быть не должно вообще, вы точно все правильно тестируете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 8 октября, 2013 · Жалоба Добрый день, товарищи. Вопрос по оптимизации linux softrouter. В наличии имеется три одинаковых машины "все в одном" (fw+tc+nat+netflow) на базе Sun Ultra 20 (Dual-Core AMD Opteron Processor 1214 @ 1Ghz, 1Gb RAM) с двумя двухголовыми сетевыми картами Intel 82576 (бралось с запасом под bond. по одному линку в каждой карте). Машины работают параллельно, позволяя балансировать нагрузку при помощи next-hop+acl на циске. Суммарно 2к клиентов. Используется htb + ipset, ipt_netflow. Оптимизации текущие: GRUB_CMDLINE_LINUX_DEFAULT="quiet hpet=force clocksource=tsc" ip_conntrack hashsize=387584 net.ipv4.ip_forward=1net.ipv4.netfilter.ip_conntrack_max = 3097152net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200net.netfilter.nf_conntrack_acct=1 для обоих интерфейсов: ethtool -G eth2 rx 4096 tx 4096 ethtool -C eth2 rx-usecs 300 ifconfig eth2 txqueuelen 10000 прерывания прибиты: eth4-rx-0 - cpu0eth4-rx-1 - cpu0eth4-tx-0 - cpu1eth4-tx-1 - cpu1eth2-rx-0 - cpu1eth2-rx-1 - cpu0eth2-tx-0 - cpu0eth2-tx-1 - cpu0 Сейчас вся эта машинерия затыкается примерно на 400Мбит при 50-60kpps из-за роста soft-irq: Вопросы: 0) Что еще можно подкрутить? 1) Имеет ли смысл использовать две отдельных сетевые карты? Или лучше использовать оба порта одной сетевой? 2) Насколько существенным будет прирост производительности, если разделить функции машин на fw+tc и nat+netflow (2+1 в текущей ситуации)? 3) Или уже бросить все и требовать машины с более мощными процами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 октября, 2013 · Жалоба Сервер древний как говно мамонта, больше он ни с какими ужимками не осилит. Требуйте покупку нормальной машины. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 8 октября, 2013 · Жалоба ip_conntrack hashsize=387584 - исходя из чего выбрано? eth4-rx-0 - cpu0, eth4-rx-1 - cpu0 - с чего вы их на оно ядро повешали, смысл тогда от очередей вообще? Ну и interrupt moderation попробовать заюзать, задать фиксированное кол-во прерываний в секунду, скажем, 5000. Dual-Core AMD Opteron™ Processor 1214 @ 1Ghz - с какой радости камни с номиналом 2.2ГГц работают на 1 ГГц? Хотя да, в целом - тазик довольно убогий получается, лучше сменить на какой-то десктопный интел. Даже целерон G1610 резвее будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 8 октября, 2013 (изменено) · Жалоба ip_conntrack hashsize=387584 - исходя из чего выбрано? Где-то вычитал, что оно должно ровняться ip_conntrack_max/8 eth4-rx-0 - cpu0, eth4-rx-1 - cpu0 - с чего вы их на оно ядро повешали, смысл тогда от очередей вообще? То есть лучше будет так: eth4-rx-0 - cpu0eth4-rx-1 - cpu1 eth4-tx-0 - cpu0 eth4-tx-1 - cpu1 eth2-rx-0 - cpu0 eth2-rx-1 - cpu1 eth2-tx-0 - cpu0 eth2-tx-1 - cpu1 ? Ну и interrupt moderation попробовать заюзать, задать фиксированное кол-во прерываний в секунду, скажем, 5000. Спасибо, надо попробовать. Dual-Core AMD Opteron™ Processor 1214 @ 1Ghz - с какой радости камни с номиналом 2.2ГГц работают на 1 ГГц? Странно. надо проверить. Upd: Это частота HT, а так оно 2.2ГГц. Хотя да, в целом - тазик довольно убогий получается, лучше сменить на какой-то десктопный интел. Даже целерон G1610 резвее будет. Эх. Денег бы найти =( Что насчет разделения функций? Изменено 8 октября, 2013 пользователем legioner0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 8 октября, 2013 (изменено) · Жалоба Хотел спросить, как у вас нагрузка с новыми ядрами ? У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Какие сетевухи у Вас стоят? Подтверждаю, причем даже на самых обычных сетевухах с одной очередью стало возможно прокачать 700-900 мегабит трафика/80-100Kpps (проц E7400) Правда нерешённой остаётся трабла с INFO: rcu_preempt detected stalls on CPUs/tasks Особо страшно оно на тех местах где сейчас не 1g или 10g, а 2g bonding из-за этого lacp роняет все нафиг. и куда копать не знаю. dmesg_rcu.txt Изменено 8 октября, 2013 пользователем Tamahome Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 8 октября, 2013 · Жалоба Где-то вычитал, что оно должно ровняться ip_conntrack_max/8 А еще оптимальная производительность достигается тогда, когда хеш-таблица полностью влазит в кеш проца... То есть лучше будет так: Угу. Эх. Денег бы найти =( $100 для вашей фирмы - непосильная сумма? Тогда - да, печально... Что насчет разделения функций? Можете попробовать. Нат - отдельно, все остальное (с отключенным коннтраком) - отдельно. Может и полегчает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 8 октября, 2013 (изменено) · Жалоба Где-то вычитал, что оно должно ровняться ip_conntrack_max/8 А еще оптимальная производительность достигается тогда, когда хеш-таблица полностью влазит в кеш проца... Так куда крутить? Эх. Денег бы найти =( $100 для вашей фирмы - непосильная сумма? Тогда - да, печально... У нас ВУЗ. Не непосильно, а долго и нудно. Что насчет разделения функций? Можете попробовать. Нат - отдельно, все остальное (с отключенным коннтраком) - отдельно. Может и полегчает. Спасибо, попробую как-нибудь. Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями. Изменено 8 октября, 2013 пользователем legioner0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 октября, 2013 · Жалоба Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями. Нет смысла пробовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 8 октября, 2013 · Жалоба Так куда крутить? Попробуйте уменьшить скажем до 32-64к записей. Сколько реально сессий у вас на нем сейчас? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 8 октября, 2013 · Жалоба tc хоть с хеш-таблицами? сколько правил iptables в среднем проходит пакет? - основная нагрузка тут, не в нате. Ну и perf top бы глянуть... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 8 октября, 2013 · Жалоба Господа, подскажите. Есть Intel 82576 и, допустим, 4'ядерный процессор. Сколько очередей лучше делать: RSS=2,2 (по две очереди на кажду голову, и каждую очередь на свое ядро) или RSS=4,4 (по четыре очереди на голову, и тогда по две очереди от разных голов на одно ядро)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 8 октября, 2013 · Жалоба И еще, есть такой документ: http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-82599-ethernet-controllers-interrupts-appl-note.pdf Кто-нибудь делает это и нужно ли вообще: 8. Configure the kernel.a. Start up the configuration menu: make menuconfig b. Make sure you are using the SLUB memory allocator (the unqueued SLAB allocator): General setup -> Choose SLAB allocator -> SLUB allocator (Unqueued Allocator) c. Turn off forced pre-emption: Processor type and features -> Preemption Model -> No Forced Preemption (Server) 7 82575/82576/82598/82599—Assigning Inte rrupts to Processor Cores d. Turn on NUMA memory allocation (for multiple processors): Processor type and features -> Numa Memory Allocation and Scheduler Support = Y e. Lower the interrupt frequency. 100 Hz is a typical choice for servers, SMP and NUMA with most processors might show reduced performance when too many timer interrupts are occurring: Processor type and features -> Timer Frequency -> 100 Hz f. Make sure MSI and MSI-X are enabled: Bus options (PCI etc.) -> Message Signaled Interrupts (MSI and MSI-X) = Y g. Turn off Fair Queueing and QoS: Networking support -> Networking Options -> QoS and/or Fair Queueing = N h. Turn off kernel statistics: Kernel hacking -> Collect kernel timers statistics = N i. If possible: Kernel hacking -> Collect scheduler statistics = N Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 9 октября, 2013 · Жалоба Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями. Нет смысла пробовать. Так скажем результат оказался и не хуже и не лучше, но в результате освобождается одна сетевая карта, которую можно воткнуть в резервный тазик. Так куда крутить? Попробуйте уменьшить скажем до 32-64к записей. Сколько реально сессий у вас на нем сейчас? Надо в пике смотреть. Сейчас при 150Мбит@20kpps: # conntrack -L -nconntrack v1.2.1 (conntrack-tools): 35036 flow entries have been shown. ... tc хоть с хеш-таблицами? сколько правил iptables в среднем проходит пакет? - основная нагрузка тут, не в нате. Ну и perf top бы глянуть... htb+ipset. В цепочке FORWARD 5 правил: 1-2 netflow, 3-4 прямой доступ к двум сетям, 5ое ACCEPT с --match-set В цепочке PREROUTING 3 правила (1-2 REDIRECT ФЗ-139). В POSTROUTING 17 строк SNAT по сетям, номер сработавшего правила зависит от тазика. perf top сейчас 14,68% [kernel] [k] ktime_get 11,52% [cls_u32] [k] u32_classify 4,74% [kernel] [k] tc_classify_compat 3,11% [igb] [k] igb_poll 2,94% [ip_tables] [k] ipt_do_table 2,24% [sch_htb] [k] htb_dequeue 1,98% [kernel] [k] ip_route_input_common 1,81% [kernel] [k] do_raw_spin_lock 1,25% [kernel] [k] hrtimer_interrupt 1,15% [kernel] [k] __alloc_skb 1,10% [ipt_NETFLOW] [k] netflow_target 1,01% [sch_sfq] [k] sfq_enqueue 0,89% [igb] [k] igb_xmit_frame_ring 0,85% [nf_conntrack] [k] nf_ct_tuple_equal 0,85% [kernel] [k] memcmp 0,77% [kernel] [k] irq_entries_start Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 октября, 2013 · Жалоба morfair Лучше 4 очереди. По тюнингу - да в принципе большиство опций так и стоят, отключение QoS - вызывает большие сомнения (не думаю что будет прирост, а вот без шейпера печально если понадобится). legioner0 Смотрите правила tc фильтров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 10 октября, 2013 · Жалоба legioner0 Смотрите правила tc фильтров. Спасибо, покручу. Временно решили установкой 4го тазика, а там глядишь и машинку по-серьезнее купят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 10 октября, 2013 · Жалоба Cервер HP DL380 G6, 2шт X5560. 4 бортовые сетевки BCM5709 включены в бондинги. Машина IPOE BRAS, терминирует vlan-per-user. В принципе занимается тупой маршрутизацией(iptables минимальный, фильтрации нет, NATa нет, conntrack не используется). В итоге при минимальном числе клиентов(500 сессий) и смешном трафике(300/200мбит) получаю высокую загрузку, с вылезанием ksoftirq. Сейчас не час пик, специально посадил прерывания 4ех сетевок на 2 ядра для большей наглядности: [root@ipoe1 sbin]# top top - 11:20:05 up 28 days, 3:57, 2 users, load average: 0.50, 0.25, 0.34 Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 64.3%id, 0.0%wa, 0.0%hi, 35.7%si, 0.0%st Cpu1 : 0.0%us, 1.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 26.3%id, 0.0%wa, 0.0%hi, 73.7%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 1.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8183824k total, 5288676k used, 2895148k free, 271064k buffers Swap: 8191992k total, 0k used, 8191992k free, 1594600k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17 root 20 0 0 0 0 S 42.8 0.0 166:46.39 ksoftirqd/2 3 root 20 0 0 0 0 S 14.9 0.0 143:10.10 ksoftirqd/0 11031 root 20 0 1239m 19m 1932 S 4.0 0.2 1053:37 accel-pppd 13097 named 20 0 658m 141m 3036 S 2.0 1.8 433:05.38 named 1 root 20 0 19276 1544 1244 S 0.0 0.0 0:19.43 init [root@ipoe1 sbin]# perf top 81.05% [kernel] [k] __netif_receive_skb_core 1.02% [kernel] [k] _raw_spin_lock 0.53% [kernel] [k] _raw_spin_lock_irq 0.48% [ip_tables] [k] ipt_do_table На 8ми ядрах ситуация пока не критична, 10-20% загрузка. Но ведь неправильно это, такая же загрузка у меня получается на соседних 4ех ядерных серверах на i5-2500 с трафиком в 2Гбит, огромными фаерволами/редиректами и т.п. Куда копать? Броадкомы выкинуть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 10 октября, 2013 · Жалоба айпишники по dhcp раздаете? покажите cat /proc/net/ptype Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 10 октября, 2013 (изменено) · Жалоба DHCP relay на машине есть. [code][root@ipoe1 ~]# cat /proc/net/ptype Type Device Function ALL vlan_pt_recv [ipoe] 0800 bond1.2024.1151 packet_rcv 0800 bond1.2024.1150 packet_rcv ... 0800 ip_rcv 8863 bond1.2001.1108 packet_rcv 8863 bond1.2008.1163 packet_rcv ... 8863 pppoe_disc_rcv [pppoe] 8864 pppoe_rcv [pppoe] 0806 bond1.2024.1151 packet_rcv 0806 bond1.2024.1150 packet_rcv ... 0806 arp_rcv dada edsa_rcv 001b dsa_rcv 88cc bond1 packet_rcv 88cc bond0 packet_rcv 88cc eth3 packet_rcv 88cc eth2 packet_rcv 88cc eth1 packet_rcv 88cc eth0 packet_rcv 001c trailer_rcv [root@ipoe1 ~]# cat /proc/net/ptype | wc -l 5217 Сейчас еще печальнее стало, этак мы и до 1G не дойдем. [root@ipoe1 ~]# perf top 75.94% [kernel] [k] __netif_receive_skb_core 2.27% [kernel] [k] cpu_idle_loop 1.65% [kernel] [k] _raw_spin_lock 1.28% [cls_u32] [k] u32_classify 0.58% [ip_tables] [k] ipt_do_table top - 17:54:23 up 28 days, 10:31, 1 user, load average: 0.09, 0.19, 0.18 Tasks: 139 total, 1 running, 138 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 84.5%id, 0.0%wa, 0.0%hi, 15.5%si, 0.0%st Cpu1 : 1.2%us, 1.2%sy, 0.0%ni, 96.4%id, 0.0%wa, 0.0%hi, 1.2%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 39.2%id, 0.0%wa, 0.0%hi, 60.8%si, 0.0%st Cpu3 : 0.0%us, 2.0%sy, 0.0%ni, 30.6%id, 0.0%wa, 0.0%hi, 67.3%si, 0.0%st Cpu4 : 0.0%us, 1.7%sy, 0.0%ni, 81.0%id, 0.0%wa, 0.0%hi, 17.2%si, 0.0%st Cpu5 : 0.0%us, 2.0%sy, 0.0%ni, 78.4%id, 0.0%wa, 0.0%hi, 19.6%si, 0.0%st Cpu6 : 0.0%us, 2.7%sy, 0.0%ni, 90.4%id, 0.0%wa, 0.0%hi, 6.8%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni, 76.6%id, 0.0%wa, 0.0%hi, 23.4%si, 0.0%st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21 root 20 0 0 0 0 S 34.8 0.0 13:25.20 ksoftirqd/3 17 root 20 0 0 0 0 S 26.9 0.0 168:33.00 ksoftirqd/2 11031 root 20 0 1239m 19m 1932 S 9.9 0.2 1077:10 accel-pppd 37 root 20 0 0 0 0 S 8.0 0.0 11:03.40 ksoftirqd/7 13097 named 20 0 658m 142m 3036 S 7.0 1.8 444:00.52 named 25 root 20 0 0 0 0 S 5.0 0.0 40:19.95 ksoftirqd/4 29 root 20 0 0 0 0 S 5.0 0.0 8:14.71 ksoftirqd/5 3 root 20 0 0 0 0 S 4.0 0.0 143:33.19 ksoftirqd/0 Изменено 10 октября, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 10 октября, 2013 · Жалоба [root@ipoe1 ~]# cat /proc/net/ptype | wc -l 5217 Коллега 8) http://lkml.org/lkml/2013/6/7/260 Там получается линейный поиск по количеству интерфейсов с DHCP сервером. После того как полечил (самописный) DHCP сервак у меня нагрузка упала на порядок (для 2000 интерфейсов, емнип), картинка в mrtg просто эпичная... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 10 октября, 2013 · Жалоба vitalyb Ясно. А как лечили, поделитесь? В моей ситуации вероятно придется лечить relay-модуль у accel-ppp. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 10 октября, 2013 · Жалоба kayot Как и написано по ссылке - вместо сокета на каждый интерфейс, делается один сокет, который принимает весь трафик (ifindex=0, bpf фильтр для dhcp с исключением аплинка по SKF_AD_IFINDEX), а интерфейс-источник определяется из sockaddr'a в recvfrom()/sendto(). Так в приложение попадает, теоретически, больше лишнего трафика, но экономия просто несравнимая. С помощью fanout'а можно данные раскидывать по нескольким сокетам для балансировки нагрузки на несколько процессов, но тут явно не тот случай - одного мне более чем достаточно. В /proc/net/ptype это выглядит одной строкой: 0800 packet_rcv+0x0/0x34e Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...