John_obn Опубликовано 29 марта, 2013 · Жалоба После переделки скриптов и использования ipfw nat все стало гораздо красивее. Но теперь уперлись в еще одно узкое место: bpf. Причем большая нагрузка от него идет от trafd. Мы им до сих считаем трафик и нам его хватает. Судя по ссылке, можно либо пропатчить bpf часть во FreeBSD, либо отказаться от bpf - правда tcpdump все равно будет изредка использоваться. По поводу замены trafd: пошерстив форум и гугл, самое менее ресурсопожирающее - это ng_netflow с коллектором на другой машине. Подтвердите или опровергните мое предположение, пожалуйста? Или же делать на коммутаторе mirror и держать еще одну машину с 10G интерфейсом и на ней уже весь трафик считать любыми средствами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 20 мая, 2013 (изменено) · Жалоба Коллеги помогите разобраться. Имеется сервер в качестве NAT (Использую PF NAT). До этого был сервер c Intel® Xeon® CPU E31240 @ 3.30GHz 4 ядра. Натил 2.2 Гбит на вход и 800 мбит на выход. PPS 300K.Проблем таких не было. Траффик растет и решил сменить железку. Заменил на Сервер 668815-421 HP ProLiant DL360e Gen8 2 проца Intel® Xeon® E5-2430. ПРоблема возникает после 1 Гбит трафика, причем в геометрической прогрессии выростют прерывания до 100 проце и LA до 30. Использую PF_NAT root@gate_rnet:/root # uname -a FreeBSD gate_rnet.123.ru 9.1-STABLE FreeBSD 9.1-STABLE #14 r244955M: Sun Mar 17 00:59:44 KRAT 2013 root@gate_rnet.rutvn.ru:/usr/obj/usr/src/sys/GENERIC.ok amd64 Карта 82599EB 10-Gigabit SFI/SFP+ loader.conf #Bucket kern.ipc.nmbclusters=262144 # Maximum number of mbuf clusters allowed // netstat -m kern.ipc.nmbjumbop=262144 # Maximum number of mbuf page size jumbo clusters allowed. pagesize(4k/8k) kern.ipc.nmbjumbo9=262144 # Maximum number of mbuf 9k jumbo clusters allowed kern.ipc.nmbjumbo16=262144 # Maximum number of mbuf 16k jumbo clusters allowed #for MC kern.maxfiles="25000" net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 kern.ipc.nsfbufs=10240 hw.intr_storm_threshold=9000 net.inet.tcp.tcbhashsize=5000 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_max=16777216 hw.ix.rxd=4096 hw.ix.txd=4096 Результат 950 мбит PPS 170K last pid: 24589; load averages: 5.14, 8.20, 8.25 up 0+05:35:19 15:20:57 248 processes: 24 running, 156 sleeping, 68 waiting CPU 0: 0.0% user, 0.0% nice, 3.5% system, 40.6% interrupt, 55.9% idle CPU 1: 0.4% user, 0.0% nice, 3.1% system, 41.3% interrupt, 55.1% idle CPU 2: 0.0% user, 0.0% nice, 3.9% system, 45.3% interrupt, 50.8% idle CPU 3: 0.0% user, 0.0% nice, 4.7% system, 37.4% interrupt, 57.9% idle CPU 4: 0.0% user, 0.0% nice, 5.1% system, 39.0% interrupt, 55.9% idle CPU 5: 0.0% user, 0.0% nice, 2.8% system, 44.1% interrupt, 53.1% idle CPU 6: 0.0% user, 0.0% nice, 2.4% system, 37.0% interrupt, 60.6% idle CPU 7: 0.0% user, 0.0% nice, 5.1% system, 38.2% interrupt, 56.7% idle CPU 8: 0.0% user, 0.0% nice, 0.8% system, 41.7% interrupt, 57.5% idle CPU 9: 0.0% user, 0.0% nice, 4.7% system, 53.1% interrupt, 42.1% idle CPU 10: 0.8% user, 0.0% nice, 2.8% system, 53.5% interrupt, 42.9% idle CPU 11: 0.0% user, 0.0% nice, 0.8% system, 52.0% interrupt, 47.2% idle Mem: 88M Active, 48M Inact, 1116M Wired, 48K Cache, 40M Buf, 22G Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 192K CPU7 7 264:17 72.85% idle{idle: cpu7} 11 root 155 ki31 0K 192K RUN 4 261:19 68.80% idle{idle: cpu4} 11 root 155 ki31 0K 192K CPU0 0 259:43 67.38% idle{idle: cpu0} 11 root 155 ki31 0K 192K RUN 3 262:26 66.36% idle{idle: cpu3} 11 root 155 ki31 0K 192K RUN 5 260:00 66.36% idle{idle: cpu5} 11 root 155 ki31 0K 192K RUN 6 265:57 65.67% idle{idle: cpu6} 11 root 155 ki31 0K 192K CPU2 2 260:27 64.06% idle{idle: cpu2} 11 root 155 ki31 0K 192K RUN 1 259:08 63.38% idle{idle: cpu1} 11 root 155 ki31 0K 192K RUN 8 239:32 61.38% idle{idle: cpu8} 11 root 155 ki31 0K 192K RUN 11 239:21 59.96% idle{idle: cpu11} 11 root 155 ki31 0K 192K CPU9 9 238:41 57.28% idle{idle: cpu9} 11 root 155 ki31 0K 192K RUN 10 239:33 54.98% idle{idle: cpu10} 12 root -92 - 0K 1248K CPU1 1 69:03 36.96% intr{irq265: ix0:que } 12 root -92 - 0K 1248K CPU2 2 67:24 35.99% intr{irq266: ix0:que } 12 root -92 - 0K 1248K CPU5 5 67:56 34.18% intr{irq269: ix0:que } 12 root -92 - 0K 1248K CPU0 0 66:44 33.25% intr{irq264: ix0:que } 12 root -92 - 0K 1248K CPU6 6 62:29 31.69% intr{irq270: ix0:que } 12 root -92 - 0K 1248K WAIT 4 66:26 29.30% intr{irq268: ix0:que } 12 root -92 - 0K 1248K WAIT 3 64:59 29.05% intr{irq267: ix0:que } 12 root -92 - 0K 1248K WAIT 7 63:59 26.07% intr{irq271: ix0:que } 12 root -92 - 0K 1248K RUN 10 47:19 23.10% intr{irq278: ix1:que } 12 root -92 - 0K 1248K WAIT 9 45:55 21.78% intr{irq276: ix1:que } 12 root -92 - 0K 1248K CPU10 10 45:42 21.48% intr{irq277: ix1:que } 12 root -92 - 0K 1248K CPU11 11 46:21 21.19% intr{irq279: ix1:que } 12 root -92 - 0K 1248K WAIT 8 45:14 21.09% intr{irq273: ix1:que } 12 root -92 - 0K 1248K WAIT 9 48:08 20.65% intr{irq275: ix1:que } 1.1 Гбит PPS 200K last pid: 26815; load averages: 30.10, 27.16, 20.69 up 0+06:09:24 15:55:02 238 processes: 35 running, 139 sleeping, 64 waiting CPU 0: 0.0% user, 0.0% nice, 50.8% system, 49.2% interrupt, 0.0% idle CPU 1: 0.0% user, 0.0% nice, 21.5% system, 76.9% interrupt, 1.5% idle CPU 2: 0.0% user, 0.0% nice, 53.8% system, 46.2% interrupt, 0.0% idle CPU 3: 0.0% user, 0.0% nice, 50.8% system, 49.2% interrupt, 0.0% idle CPU 4: 0.0% user, 0.0% nice, 44.6% system, 55.4% interrupt, 0.0% idle CPU 5: 1.5% user, 0.0% nice, 38.5% system, 60.0% interrupt, 0.0% idle CPU 6: 0.0% user, 0.0% nice, 30.8% system, 69.2% interrupt, 0.0% idle CPU 7: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle CPU 8: 0.0% user, 0.0% nice, 15.4% system, 84.6% interrupt, 0.0% idle CPU 9: 0.0% user, 0.0% nice, 0.0% system, 100% interrupt, 0.0% idle CPU 10: 0.0% user, 0.0% nice, 16.9% system, 83.1% interrupt, 0.0% idle CPU 11: 0.0% user, 0.0% nice, 3.1% system, 96.9% interrupt, 0.0% idle Mem: 87M Active, 49M Inact, 1130M Wired, 48K Cache, 40M Buf, 22G Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -92 - 0K 1248K CPU3 3 80:09 60.35% intr{irq267: ix0:que } 12 root -92 - 0K 1248K RUN 5 82:51 58.69% intr{irq269: ix0:que } 0 root -92 0 0K 944K CPU7 7 9:12 57.86% kernel{ix0 que} 12 root -92 - 0K 1248K CPU0 0 82:17 57.47% intr{irq264: ix0:que } 12 root -92 - 0K 1248K WAIT 4 81:23 54.39% intr{irq268: ix0:que } 12 root -92 - 0K 1248K RUN 1 82:10 53.66% intr{irq265: ix0:que } 12 root -92 - 0K 1248K CPU6 6 76:46 52.39% intr{irq270: ix0:que } 12 root -92 - 0K 1248K CPU2 2 83:15 52.20% intr{irq266: ix0:que } 12 root -92 - 0K 1248K RUN 8 56:59 47.27% intr{irq273: ix1:que } 12 root -92 - 0K 1248K RUN 9 57:27 46.78% intr{irq276: ix1:que } 12 root -92 - 0K 1248K CPU9 9 59:16 43.55% intr{irq275: ix1:que } 0 root -92 0 0K 944K - 1 15:19 43.46% kernel{ix0 que} 12 root -92 - 0K 1248K CPU11 11 57:35 42.87% intr{irq279: ix1:que } 12 root -92 - 0K 1248K WAIT 11 57:14 41.26% intr{irq280: ix1:que } 12 root -92 - 0K 1248K RUN 7 78:46 40.87% intr{irq271: ix0:que } 12 root -92 - 0K 1248K RUN 10 56:55 39.45% intr{irq277: ix1:que } 12 root -92 - 0K 1248K CPU10 10 58:23 39.16% intr{irq278: ix1:que } 12 root -92 - 0K 1248K CPU8 8 57:26 38.67% intr{irq274: ix1:que } 0 root -92 0 0K 944K - 6 10:18 35.79% kernel{ix0 que} 0 root -92 0 0K 944K CPU5 4 9:08 30.47% kernel{ix0 que} 0 root -92 0 0K 944K - 6 8:24 30.27% kernel{ix0 que} 0 root -92 0 0K 944K - 2 8:30 27.20% kernel{ix1 que} 0 root -92 0 0K 944K - 6 5:42 26.66% kernel{ix1 que} 0 root -92 0 0K 944K - 4 7:59 25.68% kernel{ix1 que} 0 root -92 0 0K 944K CPU1 2 8:15 25.49% kernel{ix0 que} 0 root -92 0 0K 944K - 4 6:19 23.68% kernel{ix0 que} Изменено 20 мая, 2013 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 23 мая, 2013 · Жалоба судя по top, у вас ix использует по 8 прерываний (intr{irq267: ix0:que }). попробуйте прибить их к 8 ядрам таким образом, чтобы первое прерывание ix0 и ix1 были на, скажем cpu0, второе прерывание ix0 и ix1 - на cpu1 и так далее. ps. я же говорил, что e3-1280 порвет эти два e5. =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 23 мая, 2013 · Жалоба раскидал) Вообщем поставил linux) 2 Гбит по 15 проц загружены ядра прерываниями) Так что не порвет))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 12 ноября, 2013 (изменено) · Жалоба Подниму свой старый топик. Прошу совета: хочу апгрейдить CPU у машины, описанной в начале топика, с E5-2650, на один из процов по этой ссылке. Подскажите, может уже кто имел опыт с такими процами, на какой бы вы произвели апгрейд? Хочется не выкладывать денег за процессор как за новый сервер с E3-1270v2, поэтому мой выбор остановился на E5-1660v2 Изменено 12 ноября, 2013 пользователем John_obn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 18 декабря, 2014 (изменено) · Жалоба Доброго всем времени суток! В консоль после выполнения команды ipfw pipe 197 show высыпают несколько сообщений copy_obj (WARN) type 4 inst 65733 have 92 need 96 Подскажите пожалуйста о чем оно говорит? Гугление особо ничего не дало, кроме указки на dummynet. В sysctl крутил это: # Dummynet net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=65536 net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.ip.dummynet.pipe_byte_limit=20000000 Изменено 18 декабря, 2014 пользователем NeXuSs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 18 декабря, 2014 · Жалоба Доброго всем времени суток! В консоль после выполнения команды ipfw pipe 197 show высыпают несколько сообщений copy_obj (WARN) type 4 inst 65733 have 92 need 96 Подскажите пожалуйста о чем оно говорит? Гугление особо ничего не дало, кроме указки на dummynet. В sysctl крутил это: # Dummynet net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=65536 net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.ip.dummynet.pipe_byte_limit=20000000 # Dummy net.inet.ip.dummynet.io_fast=1 # def 0 (1 - tuning) net.inet.ip.dummynet.pipe_slot_limit=4096 # def 100 (2048 or 4096 - tuning) net.inet.ip.dummynet.hash_size=65535 # def 64 (65535 - tuning) net.inet.ip.dummynet.expire=0 # def 1 (0 - tuning) # net.inet.ip.dummynet.pipe_byte_limit=1048576 # def 1048576 Последнее net.inet.ip.dummynet.pipe_byte_limit у меня по дефолту в 1048576. Может в этом дело? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 19 декабря, 2014 (изменено) · Жалоба Спасибо за ответ! Попробую, посмотрим что получится. Еще такой вопрос: нужно ли рассчитывать размер слотов в нынешних реалиях или же по дефолту все нормально работает? Я выставлял значения на скорости 10Мегабит/с от 10 до 350 - ничего не заметил. Вопрос по прибиванию прерываний к ядрам: если на машине имеется 10 ядер и двухпортовая сетевуха, то как правильно прибивать - 5 прерываний первого порта на первые 5 ядер и 5 прерываний второго порта на 5 оставшихся ядер? Или можно так: 10 прерываний первого на все 10 ядер и 10 прерываний второго так же на 10 ядер, то есть получится на каждом ядре по 2 прерывания с разных портов? Изменено 19 декабря, 2014 пользователем NeXuSs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 21 января, 2015 · Жалоба Сейчас вроде бы по умолчанию система прибиндивает очереди к ядрам. grep queue /var/run/dmesg.boot igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb1: Bound queue 0 to cpu 3 igb1: Bound queue 1 to cpu 4 igb1: Bound queue 2 to cpu 5 По поводу очереди выставлял так: ipfw pipe 1 config bw 52428800bit/s mask dst-ip 0xffffffff red 0.1/10/60/0.95 burst 10M queue 800KB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 21 января, 2015 · Жалоба По поводу очереди выставлял так: ipfw pipe 1 config bw 52428800bit/s mask dst-ip 0xffffffff red 0.1/10/60/0.95 burst 10M queue 800KB Вместо 52428800bit/s используйте запись 50Mbit/s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 21 января, 2015 · Жалоба По поводу очереди выставлял так: ipfw pipe 1 config bw 52428800bit/s mask dst-ip 0xffffffff red 0.1/10/60/0.95 burst 10M queue 800KB Вместо 52428800bit/s используйте запись 50Mbit/s Чем это обусловлено уточните пожалуйста? Изначально так и делал, затем где-то вычитал, что как раз лучше указывать в битах, когда проверял на стэнде показывало более точней, мерил с тем же учетом как и предположительный клиент (speedtest.msk.yota.ru, speedtest.net) dummynet будет больше процессорного времени тратить на перевод ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 22 января, 2015 · Жалоба Чем это обусловлено уточните пожалуйста? Изначально так и делал, затем где-то вычитал, что как раз лучше указывать в битах, когда проверял на стэнде показывало более точней, мерил с тем же учетом как и предположительный клиент (speedtest.msk.yota.ru, speedtest.net) dummynet будет больше процессорного времени тратить на перевод ? Какое процессорное время? тратится только один раз при создании пайпа и все! В вашем пайпе и так специфические настройки. Разберитесь лучше в других числах, что там с очередью происходит. P.S. Я обычно использую gred на скоростях 5-30 Мбит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TheUser Опубликовано 23 января, 2015 (изменено) · Жалоба Коллеги, а чего б такого подкрутить, чтобы у клиента вместо 38 мбит/с в speedtest.net показывало 40 мбит/с. Пайп примерно такой: ipfw pipe 16 config bw 40M burst 5M queue 200k mask src-ip 0xffffffff Подобный "недовес" наблюдается на всех скоростях, процент примерно одинаков. На железных BRASах (huawei, cisco, juniper) работает чётко (по "вёдерному" алгоритму). Какие ручки крутить в dummynet? Изменено 23 января, 2015 пользователем TheUser Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 28 января, 2015 (изменено) · Жалоба В том и дело, что когда я тестировал и ставил bw в битах (config bw 52428800bit/s или config bw 31457280bit/s) у клиента как раз показывает норму, даже чуть выше на 1 Mbit, не так страшно. 00051: 52.429 Mbit/s 0 ms burst 10485760 q131123 100 sl. 0 flows (1 buckets) sched 65587 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65587 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 167 ip 0.0.0.0/0 1.1.1.1/0 570587947 720742763801 0 0 15487009 00050: 52.429 Mbit/s 0 ms burst 10485760 q131122 100 sl. 0 flows (1 buckets) sched 65586 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65586 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 83 ip 1.1.1.1/0 0.0.0.0/0 423912838 129634974617 0 0 112840 00053: 31.457 Mbit/s 0 ms burst 8388608 q131125 800 KB 0 flows (1 buckets) sched 65589 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65589 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 141 ip 0.0.0.0/0 2.2.2.2/0 50937086 64993022585 0 0 5235 00052: 31.457 Mbit/s 0 ms burst 8388608 q131124 800 KB 0 flows (1 buckets) sched 65588 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65588 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 7 ip 2.2.2.2/0 0.0.0.0/0 30900310 4666601864 0 0 94 Изменено 28 января, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DoMeN1line Опубликовано 24 апреля, 2015 · Жалоба В том и дело, что когда я тестировал и ставил bw в битах (config bw 52428800bit/s или config bw 31457280bit/s) у клиента как раз показывает норму, даже чуть выше на 1 Mbit, не так страшно. 00051: 52.429 Mbit/s 0 ms burst 10485760 q131123 100 sl. 0 flows (1 buckets) sched 65587 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65587 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 167 ip 0.0.0.0/0 1.1.1.1/0 570587947 720742763801 0 0 15487009 00050: 52.429 Mbit/s 0 ms burst 10485760 q131122 100 sl. 0 flows (1 buckets) sched 65586 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65586 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 83 ip 1.1.1.1/0 0.0.0.0/0 423912838 129634974617 0 0 112840 00053: 31.457 Mbit/s 0 ms burst 8388608 q131125 800 KB 0 flows (1 buckets) sched 65589 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65589 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 141 ip 0.0.0.0/0 2.2.2.2/0 50937086 64993022585 0 0 5235 00052: 31.457 Mbit/s 0 ms burst 8388608 q131124 800 KB 0 flows (1 buckets) sched 65588 weight 0 lmax 0 pri 0 GRED w_q 0.099991 min_th 10 max_th 60 max_p 0.949997 sched 65588 type FIFO flags 0x1 65535 buckets 1 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 7 ip 2.2.2.2/0 0.0.0.0/0 30900310 4666601864 0 0 94 а не поделитесь настройками фаервола и какаое железо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 24 апреля, 2015 · Жалоба Коллеги, а чего б такого подкрутить, чтобы у клиента вместо 38 мбит/с в speedtest.net показывало 40 мбит/с. Пайп примерно такой: ipfw pipe 16 config bw 40M burst 5M queue 200k mask src-ip 0xffffffff Подобный "недовес" наблюдается на всех скоростях, процент примерно одинаков. На железных BRASах (huawei, cisco, juniper) работает чётко (по "вёдерному" алгоритму). Какие ручки крутить в dummynet? Вообщето в исходниках там множитель 1000 а отнюдь не 1024. ./sbin/ipfw/dummynet.c if (b == 0) sprintf(bwbuf, "unlimited "); else if (b >= 1000000) sprintf(bwbuf, "%7.3f Mbit/s", b/1000000); else if (b >= 1000) sprintf(bwbuf, "%7.3f Kbit/s", b/1000); else sprintf(bwbuf, "%7.3f bit/s ", b); ... if (*end == 'K' || *end == 'k') { end++; bw *= 1000; } else if (*end == 'M' || *end == 'm') { end++; bw *= 1000000; } if ((*end == 'B' && _substrcmp2(end, "Bi", "Bit/s") != 0) || _substrcmp2(end, "by", "bytes") == 0) bw *= 8; И так было всегда. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 апреля, 2015 (изменено) · Жалоба Если будете писать патч для этого дела, то рекомендую не просто менять 1000 на 1024, а ввести новые единицы измерения (kibit/s, Mibit/s, ...) в соответствии со стандартом IEC 80000-13 (http://en.wikipedia.org/wiki/Data_rate_units). Тогда и обратная совместимость сохранится, и есть надежда, что примут в CURRENT. Изменено 28 апреля, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 11 августа, 2016 · Жалоба Судя по текущему коду FreeBSD 10.3, патч никто в апстрим не делал. А сам патч уже у кого-то есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 11 августа, 2016 · Жалоба Хм, а зачем? Зная такую "особенность" я скорости в конифге указываю в байтах/с. ну да, в выводе оно их потом пишет несколько не такими как хотелось бы, но мне этот вывод по большому фиолетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 9 октября, 2016 (изменено) · Жалоба Всем привет. Странная такая ситуация. Сегодня утром на сервере на одном ядре возросла нагрузка по прерываниям в разы. раньше такого не было. На машине используется только bgp и шейпинг dummynet. Единственное, что я делал это патчил драйвера на использование любых SFP. два дня работал хорошо, а сейчас странности. Кто, что подскажет? Есть ли вероятность того, что это SFP дает такую картину? FreeBSD 9.3-RELEASE-p9 FreeBSD 9.3-RELEASE-p9 #0: Wed Feb 4 17:10:53 MSK 2015 root@router.tvinnet.ru:/usr/obj/usr/src/sys/BORDER-04.02.2015 amd64 last pid: 80084; load averages: 1.25, 1.15, 1.03 up 2+06:38:32 09:45:51 165 processes: 15 running, 97 sleeping, 53 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 8.6% interrupt, 91.4% idle CPU 1: 0.0% user, 0.0% nice, 0.4% system, 6.3% interrupt, 93.3% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 9.0% interrupt, 91.0% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 10.2% interrupt, 89.8% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 9.4% interrupt, 90.6% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 29.4% interrupt, 70.6% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 7.5% interrupt, 92.5% idle CPU 7: 0.0% user, 0.0% nice, 0.4% system, 7.8% interrupt, 91.8% idle CPU 8: 0.0% user, 0.0% nice, 7.4% system, 0.0% interrupt, 92.6% idle CPU 9: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle CPU 10: 0.0% user, 0.0% nice, 6.3% system, 0.0% interrupt, 93.8% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 389M Active, 978M Inact, 1214M Wired, 1653M Buf, 13G Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 192K CPU9 9 51.6H 100.00% [idle{idle: cpu9}] 11 root 155 ki31 0K 192K CPU8 8 51.6H 100.00% [idle{idle: cpu8}] 11 root 155 ki31 0K 192K CPU11 11 51.6H 99.46% [idle{idle: cpu11}] 11 root 155 ki31 0K 192K CPU6 6 48.8H 99.37% [idle{idle: cpu6}] 11 root 155 ki31 0K 192K CPU0 0 49.4H 99.17% [idle{idle: cpu0}] 11 root 155 ki31 0K 192K CPU4 4 49.5H 97.27% [idle{idle: cpu4}] 11 root 155 ki31 0K 192K CPU10 10 51.6H 97.07% [idle{idle: cpu10}] 11 root 155 ki31 0K 192K CPU3 3 49.5H 97.07% [idle{idle: cpu3}] 11 root 155 ki31 0K 192K CPU2 2 49.5H 96.58% [idle{idle: cpu2}] 11 root 155 ki31 0K 192K RUN 1 49.5H 96.48% [idle{idle: cpu1}] 11 root 155 ki31 0K 192K CPU7 7 48.9H 96.48% [idle{idle: cpu7}] 11 root 155 ki31 0K 192K CPU5 5 48.9H 74.56% [idle{idle: cpu5}] 12 root -92 - 0K 880K WAIT 5 183:36 23.68% [intr{irq273: ix1:que }] 12 root -92 - 0K 880K WAIT 1 150:29 3.56% [intr{irq269: ix1:que }] 12 root -92 - 0K 880K WAIT 6 175:14 3.47% [intr{irq274: ix1:que }] 12 root -92 - 0K 880K WAIT 5 140:09 3.37% [intr{irq264: ix0:que }] 12 root -92 - 0K 880K WAIT 0 151:32 3.17% [intr{irq268: ix1:que }] 12 root -92 - 0K 880K WAIT 2 151:32 2.98% [intr{irq270: ix1:que }] 12 root -92 - 0K 880K WAIT 7 172:25 2.88% [intr{irq275: ix1:que }] 1220 root 20 0 304M 290M select 11 93:03 2.69% /usr/local/sbin/bgpd -d -A 127.0.0.1 -d 12 root -92 - 0K 880K WAIT 3 153:53 2.59% [intr{irq271: ix1:que }] 12 root -92 - 0K 880K WAIT 6 152:47 2.59% [intr{irq265: ix0:que }] 12 root -92 - 0K 880K WAIT 4 149:42 2.59% [intr{irq272: ix1:que }] 12 root -92 - 0K 880K CPU7 7 151:37 2.49% [intr{irq266: ix0:que }] 12 root -92 - 0K 880K WAIT 2 136:36 2.39% [intr{irq261: ix0:que }] 12 root -92 - 0K 880K WAIT 3 136:20 2.39% [intr{irq262: ix0:que }] 12 root -92 - 0K 880K WAIT 1 136:33 2.20% [intr{irq260: ix0:que }] 12 root -92 - 0K 880K WAIT 4 133:54 1.76% [intr{irq263: ix0:que }] 12 root -92 - 0K 880K RUN 0 134:47 1.37% [intr{irq259: ix0:que }] Изменено 9 октября, 2016 пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 октября, 2016 · Жалоба Медитация над нетфлоу тебе поможет :) Скорее всего всплеск трафа от одного клиента, сетевуха его в одно прерывание и складывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 11 октября, 2016 · Жалоба Медитация над нетфлоу тебе поможет :) Скорее всего всплеск трафа от одного клиента, сетевуха его в одно прерывание и складывает. Нетфлоу отключал. Не помогало. А вот всплеск трафика это да. Заметил увеличение количества PPS на сервере. Странное поведение. Раньше так она не чудила. Прерывания у меня по ядрам прибиты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 11 октября, 2016 · Жалоба причем тут отключал. речь про анализ содержимого. вам как-то абонент насрал ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 13 октября, 2016 · Жалоба причем тут отключал. речь про анализ содержимого. вам как-то абонент насрал ) Понял тогда. На что внимание обращать? на большое количество мелких пакетов или больших? wiresharkом гляну во время проблем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 13 октября, 2016 · Жалоба размер пакета не имеет значения, нагрузка идёт от их количества Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...