kaN5300

Тут весь раздел забит воплями тех, у кого зуд обновления сильнее зуда предварительного тестирования. Если работает - зачем апгрейдить ? Работает - не трогай, как говорится =) с утра. net.inet.ip.fw.dyn_count: 0 При 121-м туннеле на оптимизированном сервере. На "старом": net.inet.ip.fw.dyn_count: 289 Читайте внимательно, что такое stateless логика.

net.inet.ip.fw.dyn_max - целочисленная переменная. Максимальное количество одновременно существующих динамических правил. Значение по умолчанию - 8192. А может ну их нафиг эти динамические правила? Переводить ipfw в stateless режим не пробовали?

Лолово! У нас ДО НОВОГО ГОДА два раза на дню глючило. С нашей т.з. надо копать в сторону ipfw+dummynet. Параллельно (если есть возможность) подготовьте тачку с 7.1 + mpd 5.2. Отключите SMP пока на время. В личку можно было не писать, я подписан на тему.

Знакомая ситуация, только у нас один из ифейсов жил. В следующий раз сфотографируйте вывод top -S и обратите внимание на STATE процессов ядра типа swi1: net. И загляните в нашу тему соседнюю: http://forum.nag.ru/forum/index.php?showtopic=46227 Может быть вам тоже для профилактики не помешает пощаманить с ipfw или можно еще обновиться на 7.1 и 5.2.

Всех СНГ!!! Вобщем, пока все гуд. Накапливаем аптайм на "временной" машине с двумя интерфейсами rtl8139 =) last pid: 86725; load averages: 0.01, 0.01, 0.00 up 5+06:31:52 20:45:48 62 processes: 2 running, 44 sleeping, 16 waiting CPU: 0.8% user, 0.0% nice, 4.3% system, 21.9% interrupt, 73.0% idle Mem: 16M Active, 204M Inact, 144M Wired, 92K Cache, 112M Buf, 1625M Free Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 ki31 0K 8K RUN 107.7H 84.28% idle 22 root 1 -68 - 0K 8K WAIT 596:11 13.87% irq10: rl0 rl1 12 root 1 -44 - 0K 8K WAIT 288:13 4.59% swi1: net 30 root 1 -68 - 0K 8K - 146:42 0.00% dummynet 13 root 1 -32 - 0K 8K WAIT 33:09 0.00% swi4: clock sio 15 root 1 44 - 0K 8K - 15:06 0.00% yarrow 719 root 1 44 0 8824K 5168K select 7:01 0.00% snmpd 36 root 1 20 - 0K 8K syncer 4:20 0.00% syncer Дамминет судим по показателю TIME. После всяческих оптимизаций этот показатель упал по сравнению с остальными процессами. <kan5300@nas4>netstat -s -p ip ip: 2424834596 total packets received 43 bad header checksums 0 with size smaller than minimum 5 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 1432783 fragments received 0 fragments dropped (dup or out of space) 4851 fragments dropped after timeout 712790 packets reassembled ok 699142507 packets for this host 2875 packets for unknown/unsupported protocol 1438769544 packets forwarded (0 packets fast forwarded) 130636 packets not forwardable 433661 packets received for unknown multicast group 0 redirects sent 888643261 packets sent from this host 0 packets sent with fabricated ip header 452 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 83994 output datagrams fragmented 168186 fragments created 14517 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header

У нас с четырьмя мегабитами частенько недогружают. Поработать бы сутки с нулевым значением и сутки с единичкой, сравнить статистику.

when the packet flow is under the pipe bandwidth Написано же. Если поток не доходит до потолка, механизм шейпирования вобще не применяется. Я так понял.

Я кстати, когда качал rc1 почему-то при переходе на ftp-сцылу обнаружил RC2. А в новостяъ про это ничего нет. В роадмапе у них помоему 7.1 уже вот-вот. Её-то и поставим при первой же возможности.

Подскажите диапазон значений для tablearg плииз. Задоблабся искать. Похоже. что 4094 в качестве tablearg уже указывать нельзя.

С наступающим! Что было сделано: 1) Перевели шейпирование на таблицы (вот такая конструкция): pipe 40961 config bw 4096Kbit/s mask src-ip 0xffffffff pipe 40962 config bw 4096Kbit/s mask dst-ip 0xffffffff 100 pipe tablearg ip from table\(2\) to any in recv ng* 200 pipe tablearg ip from any to table\(22\) out xmit ng* 2) Полностью отказались от stateful режима. Сейчас есть сервера работающие в старом режиме (statefull - пускай и частичный). Там к-во динамических правил примерно равно к-ву абонентов онлайн помноженного на 1.5. Т.е. сейчас на наиболее загруженном насе 534 динамических правила. 3) Почистили сами правила, оставили самое необходимое. Сократили к-во правил с 2955 до 30. Помогло как введение таблиц, так и выкидывание ненужных строчек. 4) С целью исключения двойного прохождения пакетов по одному правилу постарались максимально подробно указать направление прохождение пакета (in, out / recv, xmit). Чего не делали: 1) Для skipto применения не нашлось. Решили, что с 30-ю правилами и так будет нормально. 2) Читаем про тюнинг sysctl-ов для более производительной работы dummynet О результатах тестирования отпишусь.

Ув. jab, благодарю за ответ. Таблицы успешно удалось внедрить в механизм контроля доступа, с pipe пытался - не вышло. Буду пробовать снова. Вместе с этим посмотрим в сторону использования skipto. Еще в догонку (пока везут новое железо для экспериментов). Ставить 7.0, или можно смело релиз-кандидейт лить?

Решили проблему с резким всплесокм lavg при высоком к-ве ng-интерфейсов. Ядро не выделяло больше 60 мегов на процесс (mpd5). Решили путем введения следующих параметров ядра: options MAXDSIZ=(2048UL*1024*1024) options MAXSSIZ=(728UL*1024*1024) options DFLDSIZ=(1024UL*1024*1024) Но и не смотря на это, существует еще одна большая проблема. Сервак виснет произвольно в любой момент времени не важно при какой нагрузке. При этом остается возможность удаленного доступа (ssh). top -S кажет в поле STATE для swi1: net *in_mu, а для dummynet *if_ad. Согласно man, STATE, это событие, на котором происходит ожидание процесса. Как правило, это WAIT (в штатном режиме функционирования нашего сервера доступа). По вышеуказанным статусам я ничего не нагуглил. Есть подозрение, что "не вытягивает" dummynet. В ipfw всего 2889 правил, из них 2850 - пайпы. Сейчас у пользователей приобладают высокоскоростные безлимитные тарифы и мы не исключаем, что причиной сбоя является зараженный клиент. В ближайшее время постараемся перевести dummynet на таблицы, либо вобще уйти от ipfw в пользу pf, а шейпинг будет реализован через ng_car.

Низнал. mikevlz, спасибо. Но мы для начала попробуем 5.2 (сейчас стоит 5.1).

А нам так нравился netflow из коробки =)