madf

Предлагаю фичу: в зависимости от усредненной bandwidth за пол часа менять интенсивность окраски индикатора online. Ярко зеленый, зеленый, тусклый...

Опять же, были идеи написать какой-то гибкий анализатор по детальной статистике, только ее объемы на нормальных скоростях-количествах абонентах могут слегка запугать. Проще тогда уже tcpdump разбирать на лету Хранить последний месяц (или день). И сказать "Нет!" своим страхам

nightfly, надо подписать не "Завантажено/Відвантажено" а "Завантажено/Розвантажено (вагонів CD)"

По поводу трафика - не забывайте что у NetFlow есть латентность, и довольно большая. Имеет смысл говорить только о трафике за последние, скажем, минут 30. Ну и какая-нибуть классификация по портам. В принципе вся эта информация есть в Stargazer - включаем запись детальной статистики и смотрим данные в последнем сбросе. В том числе с разбивкой по портам.

и парсить, парсить, парсить Ыть? Что парсить? Оно ж сразу в правильных типах данных приходит. Это ж не XML какой-нибуть, а RPC все-таки!

Обмен трафиком - понятие дискретное. В данный момент времени обмена нет, но через 500 мкс пролетел пакет - есть обмен или нет? Или один пакет раз в час пролетает? Можно говорить только о том был ли у абона трафик за определенный промежуток времени.

Даже не хочется такое банчмаркать на пятизначных абонбазах Выборка занимает до пары секунд (скорее даже меньше секунды). Дергать можно раз в минуту.

Можно периодически по XML RPC дергать список юзеров и обновлять статус online.

А там при запросе REQ_RETRIES не 1 случайно? SNMP - он же по UDP работает, доставка не гарантируется. Я как минимум 3 ставил.

Предлагаю кроме раздела "известные проблемы" завести раздел "неизвестные проблемы"

Наверное, надо пересобрать sgconf_xml на той машине на которую его перенесли.

В таком случае имеет смысл строить БС как бриджи с proxy-arp чтобы: 1. не плодить на каждого юзера= (аккаунтов * количество секторов) 2. обеспечить бесшовную миграцию между БС Вопрос же был про разные подсети. arp-proxy тут плохое решение.

Включить WiFi бриджем?

А можно поподробнее про шаманства? Вдруг завтра придет еще кто-нибуть с такой-же проблемой.

Да там, по идее, проблем никаких. Нужны исходники ядра. Потом собирается модуль из новой версии дров и загружается через modprobe. Если все в порядке - кидаем его вместо старого в /lib/modules/... ksoftirqd начинает работать когда ядро не успевает обрабатывать прерывания и ставит их в очередь. Люди живут с 10G при маршрутизации, а у вас все-таки web-сервер. Немножко другие задачи, более тяжеловесные. Не пробовали оптимизировать nginx, сайт или раскидать его задачи на несколько серваков?

Ну я вашего cat /proc/interrupts так и не увидел, там картинка которая не грузится. А определил просто - по времени работы ksoftirqd. Один работает, все остальные простаивают. Ну и было бы интересно посмотреть top при пиковой нагрузке, сейчас я ничего особенного кроме ksoftirqd не вижу.

Судя по TIME для ksoftirqd у вас все прерывания обрабатываются одним ядром. Сравните TIME для разных ksoftirqd - на лицо перекос. HyperThreading лучше не включать, но в вашем случае действительно не поможет. Короче, у вас проблема с балансировкой прерываний. Думаю, "ручками раскидать" у вас не получилось. Как делали? И к стати, самое интересное - cat /proc/interrupts - не показывает

Тогда каким боком тут тема про stg?

На винде тоже нормально.

Вывод iptables -nL -t nat интереснее. NAT сильнее нагружает. Еще есть мнение что FreeBSD для задач маршрутизации рулит больше.

Никуда я не делся, тут я. Я не обещал что буду собирать ее под все дистрибутивы и архитектуры, у меня на это просто нет ни сил, ни времени ни желания. Собирайте из исходников.

Единственно, какой информации нет в базе, так это информации о том кто когда кого добавил и кто когда кого удалил. Но это как-бы не предусмотрено архитектурно, так что тут так просто ничего не исправишь.

Я не знаю как там в мускульном модуле (сам по себе он крив и убог (сейчас набегут nightfly )), но во всех других плагинах БД есть отдельная таблица хранящая изменения пользователей. В т.ч. "кто", "когда", "кого", "в каком месте", старое и новое значение. В плагинах для FireBird и PostgreSQL эти данные содержатся в таблице tb_params_log. В файловой БД они лежат в файлах log в каталогах с данными юзеров. Я вот тут сейчас глянул код - нужные вам данные лежат в таблицах с префиксом logs_ в виде тупого текста. Парсить придется.

Эммм... Хочу предупредить. Сам по себе он ничего не умеет. Надо писать скрипты OnConnect, OnDisconnect и OnChange и из них вызывать snmpset. Ничего сложного, но...

Stg может вполне успешно менять шейпы и тушить порты с помощью snmpset