madf

Пилю

Такое могло случиться если Stargazer был собран через build/make а для sgconf был просто вызван make. При этом новая версия libsrvconf.so просто не собралась и, естественно, не установилась.

Там дальше по треду пришли к выводу что это проблема конфигуратора на самом деле.

VACUUM не возвращает выделенное место в файловую систему, только очищает базу от "мертвых" записей. Потом на их место помещаются новые, так что база расти не будет. По идее можно вернуть место в файловую систему с помощью VACUUM FULL, но везде не рекомендуют этого делать, тем более что он лочит таблицы. 1.5 Гб - это совсем не много, у меня почти 200 Гб на совсем небольшом сегменте сети

Ставил на чистую систему? Может какие-то либы старые остались? Например libsrvconf.so

нет, не постоянно, нагрузка меняется динамически... Что бы всегда была 100% загрузка проца - честно говоря ни разу не видел... Вобще говоря странно. Для 300 онлайнеров это как-то многовато. У нас на 1500 онлайнерах на похожей конфигурации скачет от 40 до 80 а какой модуль захвата трафика у вас ? cap_nf Может в этом и дело

Странно. По идее должно маршрутизировать а не натить

нет, не постоянно, нагрузка меняется динамически... Что бы всегда была 100% загрузка проца - честно говоря ни разу не видел... Вобще говоря странно. Для 300 онлайнеров это как-то многовато. У нас на 1500 онлайнерах на похожей конфигурации скачет от 40 до 80

Если импульсно - то это нормально. Если постоянно - то это зависание. Этот баг пофикшен.

сколько там активных на глаз сложно сказать... но вот глядя на хтоп, видно что потоки эти грузят разные ядра... и особой привязки к какому-то из них не видно... т.е. оно все время прыгает Я смотрел на своих серверах (тем же htop/strace), заметная загрузка (более 20%) идет от 3 потоков. Остальные либо висят в слипе, либо замьючены и проц не грузят.

Хорошо, а может быть такое что, грузит проц что то другое, а показывает что стг (например прерывания сетевух, кол-во активных соединений\сессий и т.п.) ???? Вряд ли. Прерывания будут влиять на ksoftirqd, а сессии - это просто записи в таблицах ядра.

Не стоит. Если 2 ядра он еще утилизирует, то больше вряд ли. Архитектурные ограничения Процесса 2: сам stargazer и stg-exec. Правда, stg-exec может быть несколько, но они проц не потребляют практически. То что ты видишь, видимо, потоки. Из них активных - 3 штуки, и пара слабо активных. При чем они друг друга лочат. По моим наблюдениям из этих 3 параллельно работают от силы 2 потока. И еще. Т.к. основная работа - это прием и обработка данных, stargazer вряд ли когда-нибуть будет требовать более 2 ядер.

Исправлено. Жди релиза.

омг, я даже затрудняюсь определить диагноз Хм, по-моему даже прикольно. Всякие умные буковки бегут по экрану, такая себе матрица. Как в шматрице было "Эти придурки думают, что я эту хрень понимаю" Да, недавно на работе базу одну переносил, медитировал на выхлоп скрипта. Все думали что я работаю

Ну тут вопрос еще не только в скорости сборки. Настройка Autotools для проекта - тот еще квест.

gmake - GNU Make cmake это совсем другая штука. Это скорее эквивалент Autotools чем make. Т.е. это то чем сейчас занимается скрипт build. Обновление из пакетов менее болезненно, плюс это потенциально облегчит жизнь тому кто захочет протащить Stargazer в какой-нибуть дистрибутив. Компиляция - поучительный и созидательный процесс, я гарантирую это! FreeBSD 6, по моему, не такая уж и старая система. А как затронет не скажу - им виднее.

Не совпадает кодировка базы, client encoding и в том месте где ты просматриваешь таблицы. Попробуй все поставить в koi8-r.

Я редко задаю тут вопросы, в основном отвечаю. Но сегодня хочу узнать мнение сообщества. С развитием проекта становится все сложнее развивать и поддерживать собственную систему сборки на базе скрипта build. Он потихоньку превращается в configure и это мне очень не нравится. Несколько лет назад, когда я только начинал заниматься этим проектом, я в качестве эксперимента попробовал перевести его на autotools (configure, libtool, etc.). Почти получилось, но при этом пришлось кардинально изменить структуру проекта, и сама сборка происходила очень не быстро (точнее тормозил скрипт configure). Сейча

По существу: - оригинальный build от 2.406 ничего не знает про FreeBSD 8; - раз ваш задетектил FreeBSD 8 значит вы его патчили; - раз он вместо -lpthread пытается подцепить -lc_r значит вы его пропатчили не так как надо. А надо просто вот в этом куске кода: if [ "$sys" = "FreeBSD" ] then case $release in 4) OS=bsd;; 5) OS=bsd5;; 6) OS=bsd5;; 7) OS=bsd7;; *) OS=unknown;; esac ETC_DIR="./inst/freebsd/etc/stargazer" MAKE="gmake" fi вставить строчку: if [ "$sys" = "FreeBSD" ] then case $release in 4) OS=bsd;;

Какие-то левые патчи у вас

Начиная с 2.405 Stargazer сам пишет pid-файл (смотри в конфиге параметр PIDFile). Так что строка ps x | grep $DAEMON | grep -v grep | cut -f1 -d" " > $PIDFILE не нужна

Дело в том что сама логика работы divert'а построена на том чтобы получить пакет, что-то с ним сделать и потом положить его на место. Как вариант можешь попробовать закомментироывать sendto в divert_freebsd/divert_cap.cpp. Но лучше разобраться почему пакеты ходят мимо диверта.

А может просто не использовать tee?

Сегодня-завтра планирую дофиксить пару мажорных багов, потом занимаюсь вот этими: http://gforge.stgteam.dp.ua/tracker/?atid=121&group_id=10&func=browse Потом готовлю релиз. Думаю во второй половине марта будет.

СУБД в любом случае требует несколько боле ресурсов чем ФС. И ее нужно уметь "готовить". В любом случае я рекомендовал бы подождать с переходом до релиза 2.407 - я планирую синхронизировать структуру базы с текущей. В прошлом релизе у меня так и не дошли до этого руки. Что бы там кто ни говорил - MySQL не рекомендую. Слишком глючный плагин, можно использовать на свой страх и риск.