ex-transfer Опубликовано 17 ноября, 2010 · Жалоба Добрый день, уважаемые! Меня достала проблема с наглухо виснущем сервером. Происходит совершенно спонтанно, не зависит ни от пиков загрузки (~220 Mbitps/32kpps), ни от количества трансляций (max ~80k)! Сеть маленькая, на ~1000 хомяков. У всех влан-до-абонента. Система FreeBSD shaper.transfer.su 8.1-RELEASE FreeBSD 8.1-RELEASE Три сетевухи - две одинаковые Intel em (pci-e) dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14.Yandex[$Revision: 1.36.2.17.2.6 $] dev.em.0.%driver: em + одна для управления bge. Стоит pf и ipfw Установил драйвера yandex, настроил sysctl , стал виснуть РЕЖЕ. (было каждый день, или через день), стало раз в неделю. Нагрузка утром ничтожная: shapper# top -SHPb last pid: 34691; load averages: 0.33, 0.41, 0.40 up 0+14:47:43 09:52:55 123 processes: 5 running, 93 sleeping, 25 waiting Mem: 26M Active, 207M Inact, 330M Wired, 420K Cache, 213M Buf, 1412M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU3 3 658:33 95.07% {idle: cpu3} 11 root 171 ki31 0K 64K CPU2 2 657:18 94.78% {idle: cpu2} 11 root 171 ki31 0K 64K CPU1 1 638:18 93.21% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 0 610:02 91.41% {idle: cpu0} 0 root 46 0 0K 256K WAIT 1 95:37 5.08% {em1_rx_3} 961 nobody 46 0 9048K 3684K select 0 106:44 4.98% softflowd 0 root 47 0 0K 256K WAIT 2 95:28 4.88% {em1_rx_1} 0 root 47 0 0K 256K WAIT 3 95:34 4.20% {em1_rx_2} 0 root 47 0 0K 256K WAIT 3 95:53 4.05% {em1_rx_0} 0 root 46 0 0K 256K WAIT 3 59:04 4.05% {em0_rx_2} 959 nobody 46 0 9048K 3624K select 0 92:11 3.66% softflowd 0 root 47 0 0K 256K WAIT 2 59:08 2.39% {em0_rx_0} 0 root 47 0 0K 256K WAIT 0 59:21 2.00% {em0_rx_3} 0 root 45 0 0K 256K WAIT 2 58:41 1.66% {em0_rx_1} 0 root -68 0 0K 256K - 1 30:25 1.12% {bge0 taskq} 12 root -32 - 0K 400K WAIT 0 15:52 0.39% {swi4: clock} 20 root 44 - 0K 16K flowcl 3 3:16 0.34% flowcleaner 0 root -68 0 0K 256K - 1 82:21 0.00% {dummynet} Параметры sysctl.conf dev.em.0.rx_abs_int_delay=1500 dev.em.0.rx_int_delay=750 dev.em.0.rx_kthreads=4 dev.em.0.rx_processing_limit=1024 dev.em.0.tx_abs_int_delay=1500 dev.em.0.tx_int_delay=750 dev.em.1.rx_abs_int_delay=1500 dev.em.1.rx_int_delay=750 dev.em.1.rx_kthreads=4 dev.em.1.rx_processing_limit=1024 dev.em.1.tx_abs_int_delay=1500 dev.em.1.tx_int_delay=750 kern.ipc.maxsockbuf=2097152 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 net.inet.icmp.icmplim=500 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.dyn_buckets=2048 net.inet.ip.fw.one_pass=1 net.inet.ip.intr_queue_maxlen=2048 net.inet.ip.redirect=0 net.inet.tcp.blackhole=0 net.inet.tcp.maxtcptw=40960 net.inet.udp.blackhole=0 net.isr.direct=1 net.isr.direct_force=1 Конфиг pf простейший: set skip on lo0 set block-policy return set optimization normal set limit { states 300000, frags 600000 } set limit table-entries 600000 nat on vlan250 inet from { 172.16.16.0/23, 172.16.18.0/23 } to any -> xx.xx.xx.xx/28 source-hash ... Конфиг ipfw тоже простой: ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1 ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1 # === 1 Mbit ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700 ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700 # === 2 Mbit ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700 ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700 ipfw add 20085 allow ip from any to "table(68)". ipfw add 20090 allow ip from "table(68)" to any. ipfw add 20100 allow ip from any to "table(69)". ipfw add 20110 allow ip from "table(69)" to any. Подскажите, ЧТО и где можно промониторить/поменять! Уже поломал мозг, не могу понять что ему нужно. p.s. в messages перед зависанием ничего кроме ov 16 17:47:17 shapper kernel: Limiting icmp unreach response from 510 to 500 packets/sec Nov 16 17:47:19 shapper kernel: Limiting icmp unreach response from 513 to 500 packets/sec Nov 16 17:47:24 shapper kernel: Limiting icmp unreach response from 519 to 500 packets/sec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба я бы скопировал всю эту систему на другой диск, поставил второй сервер - разнёс задачи (например PF вынести на другую машину) так хоть можно попробовать отловить проблему. ну и почитайте: http://www.freebsd.org/doc/en_US.ISO8859-1...-deadlocks.html http://www.freebsd.org/doc/en_US.ISO8859-1...ug-options.html может, поможет конечно приятно было бы видеть отчет, как отловили и получилось ли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба я думаю надо переделать: # === 1 Mbit ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700 ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700 # === 2 Mbit ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700 ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700 на out xmit где там у вас абоненты это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.* а также сомневаюсь в dev.em.Х.rx_int_delay=750 посмотрите что написано в исходниках драйвера про это зачем это: kern.ipc.maxsockbuf=2097152 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 где-то видел, что не рекомендуют завышать kern.ipc.nmbclusters более 42000 или 49000 без увеличения памяти ядра а тут вы ещё и сокеты забубенили, может, вас сканируют... поставьте отличное от нуля: net.inet.tcp.blackhole=0 net.inet.udp.blackhole=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 17 ноября, 2010 · Жалоба я бы скопировал всю эту систему на другой диск, поставил второй сервер - разнёс задачи(например PF вынести на другую машину) так хоть можно попробовать отловить проблему. в недалеком будущем будет второй сервер, но пока, увы ... только этот.по поводу дебуга ядра на предмет зависания - попробую, надо это прокурить внимательно! Спасибо за наводку! а также сомневаюсь вdev.em.Х.rx_int_delay=750 посмотрите что написано в исходниках драйвера про это В исходниках яндексовских дрв? Где именно? Да, это стояло ещё при стандартных драйверах - перешло без изменений.А по поводу kern.ipc.maxsockbuf=2097152kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 память ядра увеличена до 2Г vm.kmem_size="2G" а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным? net.inet.tcp.blackhole=0 net.inet.udp.blackhole=0 да, это выставлю. На самом деле раньше и было по 1. Но в процессе поиска причины ребута убирал. ВЫставлю сейчас! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 17 ноября, 2010 · Жалоба # === 2 Mbit ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700 ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700 на out xmit где там у вас абоненты это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.* у меня vlan700 смотрит какраз на абонентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба # === 2 Mbit ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700 ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700 на out xmit где там у вас абоненты это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.* у меня vlan700 смотрит какраз на абонентов. простите запутался и запутал вас. надо внешний интерфейс указать, НО у вас же НАТ, поэтому никак. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба а также сомневаюсь вdev.em.Х.rx_int_delay=750 посмотрите что написано в исходниках драйвера про это В исходниках яндексовских дрв? Где именно? Да, это стояло ещё при стандартных драйверах - перешло без изменений. файл sys/dev/e1000/if_em.hпоиск по EM_RDTR А по поводу kern.ipc.maxsockbuf=2097152kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 память ядра увеличена до 2Г vm.kmem_size="2G" как вы отдадите ядру 2Гб, если в системе всего 2Гб?ядру можно отдать... (сомневаюсь, но где-то видел цифру 1.5Гб на 32-х битной системе) вот некогда мне искать в исходниках эти формулы, так бы дискуссию продложил бы. если у вас не высоконагруженый "комбайн" с биллингом на борту, советую убрать этот тюнинг с количеством памяти ядра, настройкой сокетов, буферов на сокеты, а также nlbclusters вернуть на базу что можно увеличить так это kern.maxusers до 512 а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным?зачем там такое количество сокетов? у вас на роутере высоконагруженый веб-сервер, ДНС-сервер?как подсчитали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 17 ноября, 2010 · Жалоба Уберите FLOWTABLE из ядра... С ним были траблы. set block-policy return замените на дроп, и, как выше написали net.inet.tcp.blackhole= net.inet.udp.blackhole= больше 0 тогда уйдут Nov 16 17:47:17 shapper kernel: Limiting icmp unreach response from 510 to 500 packets/sec set limit table-entries 600000 куда столько ? Что там у Вас в таблицах ? Максимум список абонентов. тогда с 2-х кратным запасом 2000 будет. Если в pf нет фаервола, то добавьте чтото вида pass all no state no scrub дабы оно не пыталось фигней маяться... ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1 # === 1 Mbit ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700 ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700 Я что то не понимаю тут, а ЧТО Вы шейпите ? Входящий трафик к каждому абоненту и отдельно исходящий к каждому ресурсу, не важно от кого? у Вас же маска dst ip? Исходняк он разных абонентов на один IP попадет в 1 трубу и исходнятк от одного абонента к разным ресурсам попадет в разные... Вы ipfw pipe 65 show посмотрите. Что там в трубы то напопадало. По идее ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1 ipfw pipe 1065 config queue 12 bw 131072bit/s mask src-ip 0xffffffff gred 0.002/3/6/0.1 ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1 ipfw pipe 1066 config queue 24 bw 262144bit/s mask src-ip 0xffffffff gred 0.002/6/12/0.1 # === 1 Mbit ipfw add 13000 pipe tablearg ip from "table(78)" to any in recv vlan700 ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700 и в 78 таблице номера 10ХХ и в 68 ХХ Тогда получится дуплексом 128к (для второго набора пайпов 256к) на вход и на выход каждому IP. Зачем таблица 69 вообще ? Все в одну пару таблиц (туда и оттуда). И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ? а ещё блок питания, и вообще, сервер он сервер или дешевое десктопное железо... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 17 ноября, 2010 · Жалоба если у вас не высоконагруженый "комбайн" с биллингом на борту,советую убрать этот тюнинг с количеством памяти ядра, настройкой сокетов, буферов на сокеты, а также nlbclusters вернуть на базу спасибо, все вернул на Родину :)количество пользователей увеличил Уберите FLOWTABLE из ядра... С ним были траблы.убрал. ночью пересоберу! спасибо.set block-policy return замените на дропзаменил, это осталось ещё от тех времён, когда работал только pf вместе со своим altqи количество таблентрисов урезал. не помню, нафиг я так делал! PF вообще занимается исключительно НАТом, больше в нем НИЧЕГО нет, т.к. когда-то заметил, что если закрыть им ssh снаружи, то в момент брутов сервер вешается. ipfw это дело закрывает стабильнее. pass all no stateno scrub попробую!Я что то не понимаю тут, а ЧТО Вы шейпите ? Входящий трафик к каждому абоненту и отдельно исходящий к каждому ресурсу, не важно от кого? у Вас же маска dst ip?Исходняк он разных абонентов на один IP попадет в 1 трубу и исходнятк от одного абонента к разным ресурсам попадет в разные... Поясните, я недавно перешел на ipfw, не совсем понял.Преследовалось, чтоб написать один пайп с маской /32 , сделать таблицу и зарезать все адреса таблицы этим пайпом в обе стороны. Видимо, синтаксис неверен, объясните! Можно пример корректного написания?! Вот кусок ipfw pipe 65 show: 00065: 131.072 Kbit/s 0 ms burst 0 q131137 12 sl. 0 flows (1 buckets) sched 65601 weight 0 lmax 0 pri 0 GRED w_q 0.001999 min_th 3 max_th 6 max_p 0.099991 sched 65601 type FIFO flags 0x1 1024 buckets 92 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 2 ip 0.0.0.0/0 78.31.244.61/0 3 144 0 0 0 9 ip 0.0.0.0/0 93.186.231.124/0 1 40 0 0 0 16 ip 0.0.0.0/0 172.16.16.48/0 39 28794 0 0 0 19 ip 0.0.0.0/0 92.124.12.235/0 1 48 0 0 0 22 ip 0.0.0.0/0 212.77.140.141/0 2 82 0 0 0 25 ip 0.0.0.0/0 80.249.93.235/0 1 49 0 0 0 34 ip 0.0.0.0/0 178.66.56.166/0 43 2149 0 0 0 34 ip 0.0.0.0/0 86.19.124.4/0 5 707 0 0 0 64 ip 0.0.0.0/0 93.84.218.233/0 2 174 0 0 0 77 ip 0.0.0.0/0 93.186.235.56/0 98 4124 0 0 0 84 ip 0.0.0.0/0 82.46.16.8/0 3 137 0 0 0 86 ip 0.0.0.0/0 178.66.124.210/0 4 196 0 0 0 92 ip 0.0.0.0/0 109.168.223.13/0 3 144 0 0 0 98 ip 0.0.0.0/0 78.36.104.42/0 2 96 0 0 0 101 ip 0.0.0.0/0 78.61.232.30/0 1 48 0 0 0 103 ip 0.0.0.0/0 172.16.16.71/0 57129 52422452 7 4547 12361 И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ?нет, но хочу поставить на отдельный винт Win с SiSoftware Sandra и погонять на стресс-тестах!Если есть варианты как на BSD это налету сделать, буду рад советам! ещё блок питания, и вообще, сервер он сервер или дешевое десктопное железо...Тоже была мысль. Пока резервного нет. Зато поменял и блок разеток, и даже кабель... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 17 ноября, 2010 · Жалоба Температура процессора в норме ? собираю инфу coretemp'ом, и в кактус - всё в норме! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 17 ноября, 2010 · Жалоба Сам тоже помучался. Выяснил что 8.х не очень любит тюнинги от прошлых версий. Выкинул все лишние, оставил самый минимум - стало все супер, система сама рулит теперь что ей надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 ноября, 2010 · Жалоба Nov 16 17:47:19 shapper kernel: Limiting icmp unreach response from 513 to 500 packets/secЗаменить на: set block-policy drop зачем это:kern.ipc.maxsockbuf=2097152 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 Очевидно, из стенограммы выступления Сысоева несколько лет назад. а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным?Это параметр для задания размера очереди желающих подключится к сокету.Те вот есть ссш, который принимает соединения на 22 порту. Вот когда будет наплыв желающих подключится, то приложение не будет успевать обрабатывать запросы на подключение, которые и будут ставится в очередь привязанную к слушающему сокету на 22 порту. Это никак не максимальное количество соединений. http://www.freebsd.org/doc/ru/books/handbo...nel-limits.html 11.13.1.2. kern.ipc.somaxconnПеременная sysctl kern.ipc.somaxconn ограничивает размер очереди для приема новых TCP соединений. Значение по умолчанию 128 слишком мало для надежной обработки новых соединений для нагруженного web сервера. Для такого сервера рекомендуется увеличить это значение до 1024 или выше. Даемон сервиса может сам ограничивать очередь приема новых соединений (например, sendmail(8), или Apache), но обычно в файле настройки даемона есть директива для настройки длины очереди. Более длинная очередь также помогает избежать атак Denial of Service (DoS). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 17 ноября, 2010 · Жалоба Цитата(Giga-Byte @ 17.11.2010, 13:35) зачем это: kern.ipc.maxsockbuf=2097152 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 Очевидно, из стенограммы выступления Сысоева несколько лет назад. ТОЧНО!!!Заменить на: set block-policy dropзаменил!Проверяю, но пока никаких Limiting icmp unreach response from 513 to 500 packets/sec нет ! На данный момент ядро поправлено: #options FLOWTABLE# Kernel Debugging options KDB options KDB_TRACE options DDB options SOCKBUF_DEBUG options DEBUG_VFS_LOCKS завтра начну пересборку! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 17 ноября, 2010 · Жалоба 00065: 131.072 Kbit/s 0 ms burst 0 q131137 12 sl. 0 flows (1 buckets) sched 65601 weight 0 lmax 0 pri 0 GRED w_q 0.001999 min_th 3 max_th 6 max_p 0.099991 sched 65601 type FIFO flags 0x1 1024 buckets 92 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 2 ip 0.0.0.0/0 78.31.244.61/0 3 144 0 0 0 9 ip 0.0.0.0/0 93.186.231.124/0 1 40 0 0 0 16 ip 0.0.0.0/0 172.16.16.48/0 39 28794 0 0 0 19 ip 0.0.0.0/0 92.124.12.235/0 1 48 0 0 0 22 ip 0.0.0.0/0 212.77.140.141/0 2 82 0 0 0 25 ip 0.0.0.0/0 80.249.93.235/0 1 49 0 0 0 34 ip 0.0.0.0/0 178.66.56.166/0 43 2149 0 0 0 34 ip 0.0.0.0/0 86.19.124.4/0 5 707 0 0 0 64 ip 0.0.0.0/0 93.84.218.233/0 2 174 0 0 0 77 ip 0.0.0.0/0 93.186.235.56/0 98 4124 0 0 0 84 ip 0.0.0.0/0 82.46.16.8/0 3 137 0 0 0 86 ip 0.0.0.0/0 178.66.124.210/0 4 196 0 0 0 92 ip 0.0.0.0/0 109.168.223.13/0 3 144 0 0 0 98 ip 0.0.0.0/0 78.36.104.42/0 2 96 0 0 0 101 ip 0.0.0.0/0 78.61.232.30/0 1 48 0 0 0 103 ip 0.0.0.0/0 172.16.16.71/0 57129 52422452 7 4547 12361 2 труба откуда угодно к 78.31.244.61 скорость 128к 9 труба откуда угодно к 93.186.231.124 скорость 128к ... 103 труба откуда угодно к 172.16.16.7 скорость 128к Это то, что Вам надо ? у Вас маска /32 на адресе ПОЛУЧАТЕЛЯ. на входящих пакетах это адрес Вашего клиента, и это, наверное, соответствует Вашим ожиданиям, а вот на исходящих это адрес удаленной стороны. Если Вы запустите торрент, то входняк будет резаться к Вам на 128 к, а вот исходящий трафик от Вас к каждому Вашему пиру по 128к, что при количстве пиров 100 даст 12800к.... Если это не так, как Вам надо, то нужно делать по 2 трубы - труда туда и труба оттуда на каждую скорость, для входящего маска dst для исходящего src и делать 2 таблички, в перую номера пайпов для входящго трафика во вторую номера пайпов для исходящего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 ноября, 2010 · Жалоба На данный момент ядро поправлено:#options FLOWTABLE# Kernel Debugging options KDB options KDB_TRACE options DDB options SOCKBUF_DEBUG options DEBUG_VFS_LOCKS завтра начну пересборку! боюсь не понадобится :))),кроме как выкинуть из ядра FLOWTABLE (чего сам не проверял, до сих пор боевые серверы на 7.2 стоят, чуть больше года аптайма) но попробовать стоит. кстати - вы скрипт ddb посмотрите, чтобы ddb сам собрал нужные данные и увёл сервер в ребут, когда вы будите пить пиво далеко от серверной Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 ноября, 2010 · Жалоба кстати - вы скрипт ddb посмотрите, чтобы ddb сам собрал нужные данные и увёл сервер в ребут, когда вы будите пить пиво далеко от сервернойОн не всегда это может сделать.Кроме того, нужно выключит вачдог, иначе он перезагрузит сервер раньше, чем завершится дамп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ex-transfer Опубликовано 18 ноября, 2010 · Жалоба 2 труба откуда угодно к 78.31.244.61 скорость 128к9 труба откуда угодно к 93.186.231.124 скорость 128к ... 103 труба откуда угодно к 172.16.16.7 скорость 128к Это то, что Вам надо ? у Вас маска /32 на адресе ПОЛУЧАТЕЛЯ. на входящих пакетах это адрес Вашего клиента, и это, наверное, соответствует Вашим ожиданиям, а вот на исходящих это адрес удаленной стороны. Если Вы запустите торрент, то входняк будет резаться к Вам на 128 к, а вот исходящий трафик от Вас к каждому Вашему пиру по 128к, что при количстве пиров 100 даст 12800к.... Если это не так, как Вам надо, то нужно делать по 2 трубы - труда туда и труба оттуда на каждую скорость, для входящего маска dst для исходящего src и делать 2 таблички, в перую номера пайпов для входящго трафика во вторую номера пайпов для исходящего. Это не то что надо :)Спасибо за наведение на путь истинный! Поправил: ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1ipfw pipe 35 config queue 12 bw 131072bit/s mask src-ip 0xffffffff gred 0.002/3/6/0.1 # === 128 Kbit ipfw add 11000 pipe tablearg ip from any to "table(65)" out xmit vlan700 ipfw add 11000 pipe tablearg ip from "table(35)" to any in recv vlan700 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...