IMPERATOR Опубликовано 26 ноября, 2010 · Жалоба Добрый день! Знаю что данные вопросы поднимались и уже не раз, много всего перечитал, что то как у меня что то по другому сделано. Но все мои попытки свелись к тому что удалось снизить немного нагрузку на ЦПУ , но проблема все равно остается актуальной. Что имеем: Трафик по вечерам 250-270М / 35-40kpps при этом taskq 80-95% (до того как я начал крутить уже при 250М оно упиралось в 100% и начинались дропы пакетов) Стоит в качестве бордера, Идет щейпинг трафика с помощью NG_car FreeBSD border 7.2-RELEASE FreeBSD 7.2-RELEASE #2: Wed Oct 21 15:38:41 MSD 2009 /BORDER_SMP amd64 Intel® Core2 Quad CPU Q9550 @ 2.83GHz Сеть em0@pci0:4:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em1@pci0:4:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet тоже самое на em.0 border# sysctl dev.em.1 dev.em.1.%desc: Intel® PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000 dev.em.1.%parent: pci4 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 100 dev.em.1.tx_int_delay: 100 dev.em.1.rx_abs_int_delay: 600 dev.em.1.tx_abs_int_delay: 600 dev.em.1.rx_processing_limit: 2048 sysctl net.inet.ip.intr_queue_maxlen=4096 Из того что сделал: В loader.conf добавил: hw.em.rxd=4096 hw.em.txd=4096 Сразу вопрос: нужно ли тут указывать em.1 em.0 или и так все выставится? Больше тут ничего нету Дальше через sysctl поиграл с делеями (выше видно на чем остановился) Что хочется: Допилить систему что бы загрузка была хотябы в районе 50% и было куда расти в дальнейшем на заметку - FastForwarding при включении дает зависание системы через некоторое время (пару часов) Больше вроде ничего не трогал пока, машинка боевая поэтому ребутать, выключать и т.д. крайне не желательно. Что еще можно посмотреть , где поправить, *Nix знаю неочень ;( в sysctl куча параметров непонятного назначения Может еще нужно как то разнести сетевушки по процам что бы они не прыгали, или заставить как то равномерно грузить процы, раскидав очереди, сетевые вроде очень неплохие. Но этого я пока не знаю как сделать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 26 ноября, 2010 · Жалоба У нас так, трафика 200 метров, тоже ng-car: # top -S | grep taskq 38 root 1 -68 - 0K 8K - 0 557.8H 27.39% em0 taskq 43 root 1 -68 - 0K 8K - 7 97.2H 4.30% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel® PRO/1000 Network Connection 6.9.20 dev.em.0.%driver: em dev.em.0.%location: slot=25 function=0 handle=\_SB_.PCI0.ILAN dev.em.0.%pnpinfo: vendor=0x8086 device=0x10ef subvendor=0x8086 subdevice=0x34ec class=0x020000 dev.em.0.%parent: pci0 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.0.wake: 0 # sysctl dev.em.1 dev.em.1.%desc: Intel® PRO/1000 Network Connection 6.9.20 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x020000 dev.em.1.%parent: pci2 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 # Может драйвер обновить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 28 ноября, 2010 · Жалоба Стоит в качестве бордера, Идет щейпинг трафика с помощью NG_carпокажите как. шейпинг или rate-limit ?Intel® Core2 Quad CPU Q9550 @ 2.83GHzСеть em0@pci0:4:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em1@pci0:4:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet железо дурное, может в разы больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IMPERATOR Опубликовано 29 ноября, 2010 · Жалоба Стоит ng_car , На каждого пользователя с подключенным и активным тарифным планом скриптом создается вот такое правило ipfw table 10 delete 109.197.252.164/32 2 ipfw table 11 delete 109.197.252.164/32 5002 ipfw table 10 add 109.197.252.164/32 2 ipfw table 11 add 109.197.252.164/32 5002 `/usr/sbin/ngctl -f- <<-EOF shutdown 2-3: EOF>>` `/usr/sbin/ngctl -f- <<-EOF mkpeer ipfw: car 2 upper name ipfw:2 2-3 connect 2-3: ipfw: lower 5002 msg 2-3: setconf { upstream={ cbs=393216 ebs=393216 cir=3145728 greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=393 216 ebs=393216 cir=3145728 greenAction=1 yellowAction=1 redAction=2 mode=3 } } EOF>>` По поводу железа, да, я почитал темы у кого то на более слабом загрузка в разы меньше даже при большем количестве pps, у меня больше 40к не получается сделать (видно по графикам и netstat -I em1 -w1 ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 29 ноября, 2010 · Жалоба Стоит ng_car , На каждого пользователя с подключенным и активным тарифным планом скриптом создается вот такое правило ipfw table 10 delete 109.197.252.164/32 2 ipfw table 11 delete 109.197.252.164/32 5002 ipfw table 10 add 109.197.252.164/32 2 ipfw table 11 add 109.197.252.164/32 5002 правила покажите, которые заворачивают трафик в таблицы, а лучше полностью все правила `/usr/sbin/ngctl -f- <<-EOF shutdown 2-3: EOF>>` `/usr/sbin/ngctl -f- <<-EOF mkpeer ipfw: car 2 upper name ipfw:2 2-3 connect 2-3: ipfw: lower 5002 msg 2-3: setconf { upstream={ cbs=393216 ebs=393216 cir=3145728 greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=393 216 ebs=393216 cir=3145728 greenAction=1 yellowAction=1 redAction=2 mode=3 } } EOF>>` точно shape, попробуйте mode=2, прошу вас отписаться как изменилась нагрузка Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IMPERATOR Опубликовано 29 ноября, 2010 · Жалоба точно shape, попробуйте mode=2, прошу вас отписаться как изменилась нагрузка mode=2 выставить только на downstream или и на upstream тоже сделать 2 По поводу таблиц, если я правильно понял это ipfw show вывод вот этой команды border# ipfw show 00010 4673162052 3823014152060 netgraph tablearg ip from any to table(10) out via em0 00011 4236268452 2308385966859 netgraph tablearg ip from table(11) to any out via em1 00100 18591303953 12201448914408 allow ip from any to any 65535 0 0 deny ip from any to any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 29 ноября, 2010 · Жалоба точно shape, попробуйте mode=2, прошу вас отписаться как изменилась нагрузка mode=2 выставить только на downstream или и на upstream тоже сделать 2 да, на оба направления По поводу таблиц, если я правильно понял это ipfw show вывод вот этой командыborder# ipfw show 00010 4673162052 3823014152060 netgraph tablearg ip from any to table(10) out via em0 00011 4236268452 2308385966859 netgraph tablearg ip from table(11) to any out via em1 00100 18591303953 12201448914408 allow ip from any to any 65535 0 0 deny ip from any to any прально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IMPERATOR Опубликовано 29 ноября, 2010 · Жалоба Вообщем выставил везде mode=2 . Нагрузка впринцепе не изменилась, или изменилась не кординально top last pid: 96189; load averages: 2.29, 1.95, 1.77 up 2+06:38:38 14:18:47 87 processes: 6 running, 64 sleeping, 1 stopped, 16 waiting CPU 0: 0.0% user, 0.0% nice, 24.7% system, 0.0% interrupt, 75.3% idle CPU 1: 0.0% user, 0.0% nice, 53.6% system, 0.0% interrupt, 46.4% idle CPU 2: 0.0% user, 0.0% nice, 74.9% system, 0.0% interrupt, 25.1% idle CPU 3: 0.0% user, 0.0% nice, 22.5% system, 1.0% interrupt, 76.4% idle Mem: 307M Active, 129M Inact, 514M Wired, 132K Cache, 399M Buf, 6975M Free Swap: 2000M Total, 2000M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 3 46.4H 79.88% idle: cpu3 30 root 1 -68 - 0K 16K CPU2 2 30.5H 77.39% em1 taskq 14 root 1 171 ki31 0K 16K CPU0 0 40.5H 70.46% idle: cpu0 29 root 1 -68 - 0K 16K - 1 26.9H 58.59% em0 taskq 13 root 1 171 ki31 0K 16K RUN 1 27.0H 45.65% idle: cpu1 12 root 1 171 ki31 0K 16K RUN 2 28.2H 27.29% idle: cpu2 2 root 1 -68 - 0K 16K sleep 3 248:01 12.16% ng_queue0 5 root 1 -68 - 0K 16K sleep 3 247:30 11.57% ng_queue3 3 root 1 -68 - 0K 16K sleep 0 248:26 11.47% ng_queue1 4 root 1 -68 - 0K 16K sleep 3 248:15 11.18% ng_queue2 15 root 1 -32 - 0K 16K WAIT 0 97:00 0.68% swi4: clock 20125 root 1 44 0 180M 170M select 0 21:02 0.00% bgpd 97797 root 1 44 0 28336K 10520K select 3 4:22 0.00% snmpd и netstat -I em1 -w1 input (em1) output packets errs bytes packets errs bytes colls 35494 0 31466362 29362 0 13903613 0 34865 0 30426666 29873 0 14295098 0 34473 0 30730186 29410 0 14195186 0 34512 0 31038166 28858 0 13433373 0 34078 0 30188616 29060 0 14330105 0 34848 0 31344037 29456 0 13863636 0 35723 0 32330831 30373 0 14465794 0 border# netstat -I em0 -w1 input (em0) output packets errs bytes packets errs bytes colls 28624 0 14376180 30108 0 25405359 0 29849 0 14942266 31171 0 25459898 0 30370 0 14790080 32062 0 27253210 0 30731 0 15603319 31890 0 26347965 0 30238 0 15398999 31016 0 25664937 0 30587 0 14743566 32480 0 26759334 0 30006 0 15020539 31263 0 24917052 0 еще непонятная разница в 2 раза на входящем и исходящем input (em1) output Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 29 ноября, 2010 · Жалоба отправил вам в личку по поводу яндексовых драйверов. у меня трафик гораздо больше, процессор гораздо хуже - Q6600 а нагрузка на проц примерно такаяже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IMPERATOR Опубликовано 1 декабря, 2010 · Жалоба Вообщем пришел к такому выводу: при dev.em.1.rx_processing_limit: 2048 (и других + значениях) можно добится отсутвия дропов но растет пинг и в конечном итоге проц все равно уходит в 100% Если dev.em.1.rx_processing_limit= -1 то нагрузка значительно падает (со 100% где то до 80) , Пинг хороший. Но появляются дропы пакетов при большой нагрузке. ДУмаю еще попробовать драйвера обновить или яндексовые попробвоать. (чуть позже) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...