bondar Опубликовано 1 октября, 2009 · Жалоба Оптимизация фаера, дамминет, и прочего это хорошо. Но все же вопрос, можно ли дамминет расспаралелить например на два ядра или процессора? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 октября, 2009 (изменено) · Жалоба Оптимизация фаера, дамминет, и прочего это хорошо.Но все же вопрос, можно ли дамминет расспаралелить например на два ядра или процессора? В сегодняшнем виде нельзя, т.к. он реализован как один kernel thread, а для параллелизма надо бы по треду на каждый процессор. Да и скорее бы уже от него избавились в пользу ng_car или допиленного ALTQ. Юзают его в основном из-за того, что во FreeBSD массовый шейпинг делать особо нечем, кроме вышеназванного ng_car, а у tc в Linux синтаксис правил сложнее и куча своих проблем. Изменено 1 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 2 октября, 2009 (изменено) · Жалоба так написал же человек что есть временное вполне себе решение. тем более интегрирован в ipfw, придется наверное на него переходить ибо для pf как я понял не будут писать паралелящийся код. и altq и дамминет немного для разных целей лучше использовать. каждый под свое заточен, хоть и в одной области. Изменено 2 октября, 2009 пользователем [GP]Villi Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 2 октября, 2009 · Жалоба А зачем ? Мне вот ни разу не потребовалось dummynet параллелить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 2 октября, 2009 · Жалоба так написал же человек что есть временное вполне себе решение. тем более интегрирован в ipfw, придется наверное на него переходить ибо для pf как я понял не будут писать паралелящийся код. и altq и дамминет немного для разных целей лучше использовать. каждый под свое заточен, хоть и в одной области.Ну почему для разных целей? В ALTQ тоже можно шейпить (дисциплинами CBQ и HFSC), но там нет возможности классифицировать трафик от кучи IP одним правилом, вроде pipe tablearg или по маске. В результате появляются тормоза. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sid1333 Опубликовано 2 октября, 2009 · Жалоба Ну изначально вопрос стоял как распараллелить dummynet из-за того, что нагрузка на него зашкаливала по неведомым причинам, но на данный момент необходимости в этом у меня нет вообще, как и у тов. jab'а - нагрузка на dummynet 0% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 2 октября, 2009 · Жалоба Значит, так и запишем, что там все еще не убраны блокировки, и тред dummynet при миграции с процессора на процессор создавал избыточную нагрузку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 2 октября, 2009 · Жалоба Значит, так и запишем, что там все еще не убраны блокировки, и тред dummynet при миграции с процессора на процессор создавал избыточную нагрузку. Все там убрано давно. Проблема вылезала в районе 7.1-RELEASE, причем не у всех. Я прыгал с 7.0 на 7.2 и благополучно её избежал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 2 ноября, 2009 (изменено) · Жалоба У меня была примерно та же проблема, что и у автора, на 7.2-STABLE. Подкрутил sysctl по методам, описанным в треде, всё пришло в норму. Особенно помогло, похоже, увеличение в два раза int_delay и abs_int_delay - прерывания на em упали с 6-7 тысяч до 500, dummynet тоже перестал занимать 40-50%: last pid: 867; load averages: 0.78, 0.78, 0.80 up 2+17:55:36 21:56:18 91 processes: 5 running, 68 sleeping, 18 waiting CPU: 0.0% user, 0.0% nice, 23.4% system, 0.8% interrupt, 75.8% idle Mem: 19M Active, 1068M Inact, 284M Wired, 296K Cache, 112M Buf, 630M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 8K RUN 0 60.4H 76.76% [idle: cpu0] 10 root 171 ki31 0K 8K RUN 1 62.2H 74.56% [idle: cpu1] 37 root 43 - 0K 8K WAIT 0 9:13 10.99% [em1_rx_kthread_0] 38 root 43 - 0K 8K WAIT 0 9:13 10.89% [em1_rx_kthread_1] 34 root 43 - 0K 8K WAIT 1 8:46 8.69% [em0_rx_kthread_1] 33 root 43 - 0K 8K WAIT 1 8:47 8.50% [em0_rx_kthread_0] 22 root -68 - 0K 8K WAIT 1 212:34 0.59% [irq24: skc0] 13 root -32 - 0K 8K WAIT 1 36:39 0.49% [swi4: clock sio] 23 root -64 - 0K 8K RUN 1 9:12 0.20% [irq16: uhci0] 50 root -68 - 0K 8K - 0 135:11 0.00% [dummynet] Изменено 2 ноября, 2009 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 5 ноября, 2009 (изменено) · Жалоба Кстати, у меня тут очень интересная бага нарисовалась, dummynet висит, потребляя под 40% CPU на сервере с созданными pipe+queue, при отсутствии трафика. Изменял net.isr.direct (1=>0), kern.ipc.nmbclusters(25600=>262144), net.inet.ip.intr_queue_maxlen(3000=>100), kern.timecounter.hardware (ACPI-fast=>HPET), не помогает. Вот как это выглядит: top -aSH last pid: 3579; load averages: 0.10, 0.11, 0.08 up 31+01:40:47 15:13:47 92 processes: 5 running, 68 sleeping, 19 waiting CPU: 0.0% user, 0.0% nice, 10.0% system, 3.6% interrupt, 86.4% idle Mem: 34M Active, 1388M Inact, 243M Wired, 25M Cache, 112M Buf, 312M Free Swap: 2048M Total, 16K Used, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 8K RUN 0 648.0H 99.56% [idle: cpu0] 10 root 171 ki31 0K 8K RUN 1 666.0H 69.29% [idle: cpu1] 44 root -68 - 0K 8K CPU1 1 58.6H 31.49% [dummynet] 12 root -44 - 0K 8K WAIT 0 51.0H 4.30% [swi1: net] 22 root -68 - 0K 8K WAIT 0 26.4H 2.78% [irq24: skc0] 28563 root 46 0 12064K 8868K select 0 25:50 0.98% /usr/local/sbin/snmpd -p /var/run/snmpd.pid 13 root -32 - 0K 8K WAIT 0 527:53 0.29% [swi4: clock sio] ipfw queue list |grep -c -E '^q' 1970 Пример queue: ipfw queue list | tail -n 4 q10026: weight 1 pipe 10026 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 32 ip 10.54.4.11/0 0.0.0.0/0 2954548 1355285097 0 0 77 sysctl net.inet.ip net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 0 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 100 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 39969138 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt: 322918771 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 120323730 net.inet.ip.dummynet.tick_adjustment: 103861513 net.inet.ip.dummynet.tick_delta_sum: 15 net.inet.ip.dummynet.tick_delta: 0 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 322915906 net.inet.ip.dummynet.searches: 322918771 net.inet.ip.dummynet.extract_heap: 240 net.inet.ip.dummynet.ready_heap: 0 net.inet.ip.dummynet.hash_size: 1024 net.inet.ip.fastforwarding: 1 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 50 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 4096 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 400 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.one_pass: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.inet.ip.maxfragpackets: 8192 net.inet.ip.stealth: 1 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 1 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 cat /etc/sysctl.conf kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=1024 kern.maxfiles=20480 #kern.polling.enable=1 #kern.polling.user_frac=25 net.inet.carp.log=6 net.inet.carp.preempt=1 net.inet.ip.dummynet.hash_size=512 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=0 net.inet.ip.intr_queue_maxlen=3000 net.inet.ip.random_id=1 net.inet.ip.redirect=0 net.inet.ip.stealth=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.drop_synfin=1 net.inet.tcp.recvspace=65228 net.inet.tcp.sendspace=65228 net.inet.tcp.syncookies=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65228 net.link.ether.inet.log_arp_wrong_iface=0 # For clear console sysctl -a|grep dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x109a subvendor=0x15d9 subdevice=0x109a class=0x020000 dev.em.1.%parent: pci15 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 Предположения есть, чего это он вдруг? :) P.S. Сервер идентичный с приведённым в сообщении выше, за исключением настройки памяти под ядро и интеловских вместо яндексовских драйверов. Изменено 5 ноября, 2009 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...