Hawk128 Опубликовано 5 февраля, 2013 · Жалоба Name: <unnamed> Type: ksocket ID: 00000040 Num hooks: 1 похоже эта, но лучше построчно запускать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
resident_k Опубликовано 6 февраля, 2013 · Жалоба Name: <unnamed> Type: ksocket ID: 00000040 Num hooks: 1 похоже эта, но лучше построчно запускать. Благодарю всех за помощь - заработало как надо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lucky SB Опубликовано 18 февраля, 2014 · Жалоба Followup FreeBSD 7.2 em ng_nat Core2Duo В среднем 10000 pps, пики в 20000 pps. Не очень много.... Процессор на 20-30% максимум загружен. Но вот сегодня случился матч по хоккею Россия-Норвегия. И видимо много абонентов одновременно захотели его посмотреть. Сервер впал в кому: одно ядро 100% ng_queue0, второе простаивает пинг до сервера 1000ms, ssh с трудом протискивается на коммутаторах нагрузка интерфейса минимальная.... На сервере крутиться ng_nat и шейпер через dummynet 03000 netgraph tablearg ip from any to table(6) in recv vlan0 10000 pipe tablearg ip from table(100) to any in 10005 deny ip from table(109) to any 10010 netgraph tablearg ip from table(5) to any out xmit vlan0 10100 pipe tablearg ip from any to table(101) out Вот что нашлось в интернете: http://lists.freebsd.org/pipermail/freebsd-net/2010-January/024357.html Вкратце - на FreeBSD7.2 у человека как только количество пакетов в ng_ipfw превышает порог и узел перестает успевать обрабатывать пакеты наступает попа. одно ядро занято ng_queueX, остальные простаивают. ng_ipfw один, не параллелится. моя нагрузка. netstat -w1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 9033 0 7058753 8767 0 7037515 0 10096 0 7769096 9803 0 7757513 0 9882 0 7798929 9635 0 7787372 0 10365 0 7842143 9998 0 7702506 0 11305 0 8400510 11066 0 8442332 0 12084 0 9238992 11750 0 9167847 0 14929 0 11745265 14722 0 11777404 0 12287 0 9132906 12031 0 9180145 0 11 root 1 171 ki31 0K 8K CPU1 1 124:22 100.00% idle: cpu1 12 root 1 171 ki31 0K 8K RUN 0 127:00 90.58% idle: cpu0 27 root 1 -68 - 0K 8K WAIT 0 19:07 9.67% irq256: em0 2 root 1 -68 - 0K 8K sleep 1 28:03 0.29% ng_queue0 3 root 1 -68 - 0K 8K sleep 1 6:49 0.20% ng_queue1 48 root 1 -68 - 0K 8K - 0 9:13 0.00% dummynet 14 root 1 -32 - 0K 8K WAIT 0 1:42 0.00% swi4: clock 28 root 1 -68 - 0K 8K WAIT 1 1:00 0.00% irq257: em0 26 root 1 -68 - 0K 8K - 0 0:40 0.00% em0 taskq У меня 7.2, работало без проблем, а у топик стартера 9.0 - и такие же сипмтомы. неужели не починили.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apm Опубликовано 18 февраля, 2014 · Жалоба Followup FreeBSD 7.2 em ng_nat Core2Duo FreeBSD 9.1-STABLE #0: Fri Jan 18 16:20:47 YEKT 2013 У меня такое же бывало Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 18 февраля, 2014 · Жалоба sysctl на нетграфову память крутили? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 20 февраля, 2014 (изменено) · Жалоба Сейчас: [size=2] SIZE LIMIT USED FREE REQUESTS FAILURES[/size] NetGraph items: 52, 4130, 0, 177, 89, 0 NetGraph data items: 52, 531, 1, 530, 1791029767, 1178838 net.graph.msg_version: 8 net.graph.abi_version: 65547 net.graph.maxdata: 512 net.graph.maxalloc: 4096 net.graph.threads: 2 net.graph.control.proto: 2 net.graph.data.proto: 1 net.graph.family: 32 net.graph.recvspace: 128000 net.graph.maxdgram: 128000 Добавил в boot/loder.conf net.graph.maxdata=65536 net.graph.maxalloc=65536 на будущее. Пока попробовал поставить net.isr.direct=0 net.inet.ip.fastforwarding: 0 Нагрузка с irq уползла на swi1:net, распределилась на два ядра параллельно, НО стала больше. Если раньше одно ядро было под 28%, второе в районе 10%, то теперь одно 32%, второе 20% PPS при этом 24к Жалоб от клиентов нет, буду дальше смотреть на статистику и да. сетевуха - десктопный интел за 1000 руб. Изменено 20 февраля, 2014 пользователем LuckySB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 5 марта, 2014 · Жалоба Решил поменять железо. Взял соседний core i3 с 4Gb и перенес в него винт и сетевуху. В процессе смены выяснилось, что на том сервере, с которого переносил винт проблемы с кулером на проце. После включения обороты в районе 100-300 rpm, потом правда раскручивается по полной. Возможно и в этом проблема была... Смущает, что на нем загрузка процессора больше.... Но пока все работает хорошо. сегодня обмолотил 37к пакетов в секунду.... 200/50 мбит трафика (но видимо есть проблемы с bsnmpd, при опросе snmp-счетчиков кактусом и mrtg не рисуется трафик больше 200мбит. Увеличил begemotIfForcePoll = 6000, будем посмотреть. [/size] 15560 0 12530952 14991 0 12022975 0 13433 0 10742020 12755 0 10129682 0 16931 0 14308109 16385 0 13788607 0 14928 0 12408319 14408 0 11974836 0 12836 0 10533682 12286 0 10033641 0 [size=2]^C[/size] # top -SP last pid: 28766; load averages: 0.08, 0.08, 0.07 132 processes: 3 running, 109 sleeping, 1 zombie, 19 waiting CPU 0: 0.0% user, 0.0% nice, 8.3% system, 0.8% interrupt, 91.0% idle CPU 1: 0.0% user, 0.0% nice, 0.8% system, 13.2% interrupt, 86.1% idle Mem: 116M Active, 1149M Inact, 341M Wired, 116K Cache, 199M Buf, 1577M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 8K RUN 0 116.6H 91.06% idle: cpu0 11 root 1 171 ki31 0K 8K CPU1 1 110.9H 85.50% idle: cpu1 32 root 1 -68 - 0K 8K WAIT 1 897:31 19.48% irq256: em0 2 root 1 -68 - 0K 8K sleep 0 207:59 3.08% ng_queue0 3 root 1 -68 - 0K 8K sleep 0 207:58 3.08% ng_queue1 33 root 1 -68 - 0K 8K WAIT 0 61:08 0.68% irq257: em0 Старый сервер loader.conf [size=2]kern.ipc.maxpipekva="60000000"[/size] geom_label_load="YES" hw.em.rxd=4096 hw.em.txd=4096 [size=2] sysctl [/size] [size=2] kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=1024 [size=2]kern.ipc.nmbclusters=65535[/size] kern.maxfiles=65000 kern.maxfilesperproc=32000 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_max=65536 net.inet.ip.rtmaxcache=1024 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=1000 net.route.netisr_maxqlen=2048 net.inet.ip.fw.one_pass=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 # Generate random IP_ID's net.inet.ip.random_id=1 net.inet.ip.fastforwarding=1 net.graph.recvspace=128000 net.graph.maxdgram=128000 dev.em.0.rx_int_delay=1000 dev.em.0.tx_int_delay=1000 dev.em.0.rx_abs_int_delay=2000 dev.em.0.tx_abs_int_delay=2000 dev.em.0.rx_processing_limit=4096 [/size] [size=2] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 5 марта, 2014 · Жалоба (но видимо есть проблемы с bsnmpd, при опросе snmp-счетчиков кактусом и mrtg не рисуется трафик больше 200мбит. Увеличил begemotIfForcePoll = 6000, будем посмотреть. Это у вас в какти счетчики 32-х битные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lucky SB Опубликовано 7 марта, 2014 · Жалоба Это у вас в какти счетчики 32-х битные. Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах Сегодня в середине дня опять случился жорик. Не помогло новое железо. ;( Причем жорик длился около часа и прошел сам собой. ;( будем переползать на 9.2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 8 марта, 2014 · Жалоба Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах Конечно рисует, если при создании выбрать протокол v2 и график 64-бита... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lucky SB Опубликовано 11 марта, 2014 · Жалоба Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах Конечно рисует, если при создании выбрать протокол v2 и график 64-бита... не надо считать людей глупее себя. заменил штатный bsmnpd на netsnmpd - все стало рисоваться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 12 марта, 2014 · Жалоба заменил штатный bsmnpd на netsnmpd - все стало рисоваться. Значит, вы не подгрузили соответствующие netgraph модули. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apm Опубликовано 12 марта, 2014 · Жалоба заменил штатный bsmnpd на netsnmpd - все стало рисоваться. Значит, вы не подгрузили соответствующие netgraph модули. Или не покормили собаку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 28 марта, 2014 · Жалоба Добрый день. Имеются сходные симптомы ng_queue грузит ядро на 100% ping: sendto: Cannot allocate memory NetGraph data items fails Накрутка net.graph.maxdata=262144 net.graph.maxalloc=262144 ничего не дает в каой то момент все равно происходит переполнение. NetGraph data items: 72, 262160, 262147, 13,52086227,1246688, 0 root@firewall-2:/usr/home/Multik # top -HS last pid: 18557; load averages: 1.55, 1.41, 1.55 up 23+14:57:53 22:05:50 139 processes: 6 running, 106 sleeping, 27 waiting CPU: 0.4% user, 0.0% nice, 23.2% system, 8.0% interrupt, 68.5% idle Mem: 918M Active, 437M Inact, 817M Wired, 827M Buf, 5717M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root -16 - 0K 64K CPU3 3 49.5H 100.00% ng_queue{ng_qu 11 root 155 ki31 0K 64K RUN 3 431.2H 75.39% idle{idle: cpu3 11 root 155 ki31 0K 64K CPU2 2 431.1H 73.19% idle{idle: cpu2 11 root 155 ki31 0K 64K RUN 0 433.4H 68.36% idle{idle: cpu0 11 root 155 ki31 0K 64K CPU1 1 431.5H 67.09% idle{idle: cpu1 12 root -92 - 0K 432K WAIT 0 34.4H 3.86% intr{irq261: ig 12 root -92 - 0K 432K WAIT 3 39.1H 3.47% intr{irq259: ig 12 root -92 - 0K 432K WAIT 0 39.3H 3.27% intr{irq256: ig 12 root -92 - 0K 432K WAIT 1 39.4H 2.69% intr{irq257: ig 12 root -92 - 0K 432K WAIT 2 39.1H 2.29% intr{irq258: ig 12 root -92 - 0K 432K WAIT 2 34.2H 2.20% intr{irq263: ig 12 root -92 - 0K 432K WAIT 3 33.7H 1.76% intr{irq264: ig 12 root -92 - 0K 432K WAIT 1 34.1H 1.17% intr{irq262: ig 13 root -16 - 0K 64K sleep 0 49.0H 0.78% ng_queue{ng_que 13 root -16 - 0K 64K sleep 1 48.7H 0.68% ng_queue{ng_que 13 root -16 - 0K 64K sleep 2 49.9H 0.49% ng_queue{ng_que Присем данная проблема возникает на 2х машинах на одной 9.0 на второй 9.2 обе машины обновлялись с 8.2 и там была эта же проблема. К разным машинкам подключены 2а разных канала от 2х не зависимых провайдеров. работают как нат+шейпер От нагрузки возникновение проблемы не зависит, иногда это бывает в моменты близкие к пикам 150k pps иногда это вообще не серьезная нагрузка вида 50k pps Перезагрузка сервера помогает не на долго, минут через 10 проблема снова возникает, потом сама собой проходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 28 марта, 2014 · Жалоба Добрый день. Имеются сходные симптомы ng_queue грузит ядро на 100% ping: sendto: Cannot allocate memory NetGraph data items fails Накрутка net.graph.maxdata=262144 net.graph.maxalloc=262144 ничего не дает в каой то момент все равно происходит переполнение. NetGraph data items: 72, 262160, 262147, 13,52086227,1246688, 0 Допишите в /etc/sysctl.conf net.graph.recvspace=2048000 net.graph.maxdgram=2048000 kern.ipc.nmbclusters=2000000 и покажите netstat -m Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 29 марта, 2014 · Жалоба я уже крутил эти параметры немного net.graph.maxdgram=724248 net.graph.recvspace=724248 kern.ipc.maxsockbuf=23175936 никакого эффекта не дает. netstat -m вышлю как проблема повторится Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 29 марта, 2014 · Жалоба собственно вот начинается процесс умирания всего поднялся пинг от пользователей чере нат начало расти заполнение буфера NetGraph data items: 72, 262160, 2448, 4106,2757945007, 0, 0 NetGraph data items: 72, 262160, 2529, 4025,2760913074, 0, 0 но пока ошибок еще нет и про отсутствие памяти не пишет root@firewall-2:/usr/home/Multik # netstat -m 9541/6209/15750 mbufs in use (current/cache/total) 9533/5321/14854/524288 mbuf clusters in use (current/cache/total/max) 9533/5315 mbuf+clusters out of packet secondary zone in use (current/cache) 0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 21557K/12502K/34059K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines динамика такая root@firewall-2:/usr/home/Multik # netstat -m 10701/5049/15750 mbufs in use (current/cache/total) 10693/4161/14854/524288 mbuf clusters in use (current/cache/total/max) 10693/4155 mbuf+clusters out of packet secondary zone in use (current/cache) 0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 24225K/9892K/34117K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Переключил пользователей на другого провайдера, без перезагрузки сервера, просто нат завернул на другой ИП все нормализовалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 9 апреля, 2014 · Жалоба Вот в очередной раз ситуация повторилась root@firewall-2:/usr/home/Multik # netstat -mb 8573/263437/272010 mbufs in use (current/cache/total) 8451/262659/271110/524288 mbuf clusters in use (current/cache/total/max) 8451/262648 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 19110K/591593K/610704K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines NetGraph data items: 72, 262160, 674, 261486,62733990280,39958556, 36 но на этот раз все не умерло а через некоторое время очухалось. распределение нагрузки по ядрам вроде нормальное last pid: 48472; load averages: 2.65, 2.34, 2.16 up 11+23:34:07 22:03:19 130 processes: 6 running, 97 sleeping, 27 waiting CPU 0: 0.0% user, 0.0% nice, 13.8% system, 37.9% interrupt, 48.3% idle CPU 1: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle CPU 2: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle CPU 3: 0.0% user, 0.0% nice, 31.0% system, 17.2% interrupt, 51.7% idle Mem: 784M Active, 312M Inact, 1765M Wired, 973M Buf, 5028M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K CPU3 3 224.2H 58.89% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 1 224.5H 58.25% idle{idle: cpu1} 11 root 155 ki31 0K 64K RUN 2 224.4H 54.79% idle{idle: cpu2} 11 root 155 ki31 0K 64K CPU0 0 216.8H 51.17% idle{idle: cpu0} 12 root -72 - 0K 432K WAIT 2 39.5H 25.59% intr{swi1: netisr 0} 13 root -16 - 0K 64K sleep 1 21.3H 23.39% ng_queue{ng_queue2} 13 root -16 - 0K 64K sleep 3 22.2H 22.56% ng_queue{ng_queue1} 13 root -16 - 0K 64K sleep 2 21.3H 22.36% ng_queue{ng_queue3} 13 root -16 - 0K 64K CPU2 2 21.7H 21.97% ng_queue{ng_queue0} 12 root -92 - 0K 432K WAIT 3 19.0H 13.28% intr{irq259: igb0:que} 12 root -92 - 0K 432K WAIT 1 18.9H 12.79% intr{irq257: igb0:que} 12 root -92 - 0K 432K WAIT 0 19.7H 10.79% intr{irq256: igb0:que} 12 root -92 - 0K 432K WAIT 2 19.0H 10.50% intr{irq258: igb0:que} 12 root -92 - 0K 432K WAIT 0 890:13 7.76% intr{irq261: igb1:que} 12 root -92 - 0K 432K WAIT 1 422:17 3.17% intr{irq262: igb1:que} 12 root -92 - 0K 432K WAIT 2 423:43 2.78% intr{irq263: igb1:que} 12 root -92 - 0K 432K WAIT 3 427:36 2.20% intr{irq264: igb1:que} 12 root -60 - 0K 432K WAIT 0 286:15 0.88% intr{swi4: clock} 4342 bind 20 0 814M 764M uwait 2 15:02 0.29% named{named} 4342 bind 20 0 814M 764M uwait 3 15:00 0.29% named{named} 4342 bind 20 0 814M 764M uwait 3 14:58 0.29% named{named} 4342 bind 20 0 814M 764M uwait 2 15:01 0.20% named{named} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitcin Опубликовано 14 апреля, 2014 (изменено) · Жалоба В свое время были такие проблемы - перешли на ipfw nat. Но проблемы порой знали о себе знать, только немного в другом обличии. Проблему решили - сейчас самому интересно сработает ли, но попробуйте и обязательно отпишитесь о результате: Добавьте в правило фаервола 00011 382711287 27928042812 deny ip from any to any dst-port 6881 это стандартный порт обмена DHT у торрентов может достигать умопомрачительный чисел для процессора запросов на соединение и ждать ответа. P.S. В последних версиях торрент клиентов видимо также появилась возможность использовать другие порты для DHT. Ребята нашли решение в пересборке libalias с меньшими временами поддержания соединения. Изменено 14 апреля, 2014 пользователем vitcin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 24 апреля, 2014 · Жалоба У меня тоже были подозрения на торенты. Когда снифирил входящий трафик было очень много соединений на этот порт как раз. Сейчас попробовал закрыть, посмотрим как пойдет. А что за сборка библиотеки libalias? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
supermultik Опубликовано 19 мая, 2014 · Жалоба Прошел почти месц с момента как закрыл порт 6881 полет нормальный, проблема не повторялась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 6 июня, 2014 · Жалоба Совсем DHT резать - это наверное жестоко.... ;) Попробую я вот такую конструкцию: allow ip from any to any dst-port 6881 limit src-addres,dst-port 100 Кстати, на FreeBSD 9.2 ng_queue более щадяще в 100% упирается, чем на 7.3.... хоть на консоль можно без тормозов зайти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 7 июня, 2014 · Жалоба http://forum.nag.ru/forum/index.php?showtopic=85544&view=findpost&p=845342 Неожиданно. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...