kvirtu

Проверка синхронности сессий микротика с билингом Программа проверяет активные сессии на микротике и сравнивает их с билингом. Не зарегистрированные в биллинге сессии программа отключает. Также есть возможность просмотр активных сессий микротика. /usr/abills/libexec/billd checkmikro NAS_IDS='1,2' Список серверов доступа. По умолчанию скорость просматривается на всех DEBUG=1..7 Режимы отладки. 1 - Отображать базовые сообщения программы и писать лог команд для

/usr/abills/libexec/billd -all - не сбрасывает сессии Lost-Alive/Billd Calculation Сессия не завершилась самостоятельно Данная сессия не завершилась самостоятельно и биллинг завершил её по истечению времени жизни сессии. Биллинг завершает сессии которые не отвечают на протяжении трёх alive периодов программой billd

а какая версия Абилса ?

отлично

800 Kbit качает

, наблюдаем

ключевое слово - "абилсовский нат". А в этой теме всегда упоминалось - отключаю ШЕЙПЕР и все работает. Соотв. не там искали. та да

это в процентах

В общем похоже на атаку, могу ошибаться, НО все происходит в одно и тоже время. Помогает добавление deny_in в правило НАТа . Росла нагрузка на внешнем igb0. Почему так долго было, МОЯ НЕвнимательность . Значит, в моем фаерволе в НАТе прописано log same_ports deny_in unreg_only . Я использую Абилс, там скрипт, который создает НАТ и шейпер, но без deny_in и перетирает мой НАТ. (читал доку по абилсу невнимательно, мой косяк). В моменты пиковых нагрузок, я отключал абиловский НАТ и шейпер и включал свой НАТ. После этого нагрузка падала. вот график загрузки, черными кружечками обозначены пики за сегодня

А не пробовали вести аккаунтинг. Тот-же netflow генерировать и принимать коллектором? Думаю в моменты пиковых тормозов там найдется ответ. думал, но пока все хорошо, хотя попытки скачков были, в практически в ТОЖЕ самое время, как и раньше. Около 12:30 , 15 часов , 17 часов. Скрин выложу

Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже Тестирую пока 9.3. - завтра хочу попробовать Проблема не в отсутствии deny_in, а в железе. Потому как железо, доже при отсутствии deny_in, должно переваривать поток и не ребутится, аверейдж будет расти до 5-10-20..., пинги до несколько секунд, очередь дропацца, но тачка не должна ребутится. А если тачка ребутится, то это означает что грабли в железе, проявляются на определенной, высокой нагрузке, вот и фсе. То что ты тюнингуеш, прикрутил deny_in и понизил нагрузку..., конечно круто, но это железо не реанимирует и наступит определенный уровень нагрузки даже при наличии deny_in, и тачка твоя свалится, бизнес на таком железе делать не рекомендуется. хорошо,а чем Вы объясните именно лавинообразный, быстрый рост нагрузки, и также резкий его спад ?

не из-за того что машине приходится отвечать на каждый откинутый пакет? sysctl -a | grep blackhole sysctl -a | grep blackhole net.inet.tcp.blackhole: 2 net.inet.udp.blackhole: 1 Эти переменные уже как 2 года прописаны

Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже Тестирую пока 9.3. - завтра хочу попробовать

Дай Бог, что бы больше не понадобилось, вот с 16 часов - проблем обнаружено.

9.3. настраивается

Так и фря у меня работала , горе на знал, как поставил 7.2 в 2012 - работала, без проблем .

9.3. c ZyXel сейчас конфигурим давно пора, в мене правда тьфу-тьфу-тьфу 9.2 працює нормально. ну я 10.1, пробовал, 9.2 пробовал - не идет и пипец у меня.

9.3. c ZyXel сейчас конфигурим

до 80 мбит, Intel 82575EB dual-port Gigabit Ethernet controller, 9.3 настраиваеться, 9.2. и 10.1 - висли без объяснений

не не факт, сморят видео всякое с социалок

тут фейли по нетграфу, цього не повинно бути уху, но они пока больше не растут vmstat -z | grep Graph NetGraph items: 36, 4134, 0, 390, 194970, 0 NetGraph data items: 36, 1092, 0, 1092, 89792636, 61094

ну сейчас проблем с буферами нет ?

розривало з'єднання? /boot/loader.conf =65535 net.graph.maxalloc=65535 /etc/sysctl.conf net.inet.udp.maxdgram=57344 net.graph.recvspace=128000 net.graph.maxdgram=128000 більше вродє нічого до діла не відноситься vmstat -z в момент проблеми ще б це все й досі на 7.2? в моменты глюков с буферами - MPD - онлайн 0 vmstat -z | grep Graph NetGraph items: 36, 4134, 0, 390, 89605, 0 NetGraph data items: 36, 1092, 0, 1092, 35366929, 61094 сейчас net.graph.maxdata=1024(сделал было 4028) , думал из-за него траблы

HP G5, Xeon x3075, 2 гига озу, сетевая 2-х портовая igb

Тут дело в другом: мешают мне, подлянки делают: свет рубят на оборудовании, вот с серваком ...... такого не было: top -SH last pid: 4749; load averages: 5.02, 2.69, 1.58 up 0+00:18:03 14:55:40 131 processes: 13 running, 98 sleeping, 1 zombie, 19 waiting CPU: 0.0% user, 0.0% nice, 23.4% system, 50.5% interrupt, 26.2% idle Mem: 768M Active, 26M Inact, 95M Wired, 932K Cache, 36M Buf, 1111M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 24 root -68 - 0K 8K CPU1 1 16:30 100.00% irq257: igb0