gall

А более развернутый ответ можеш дать?

Ну принимать-не принимать.. дело твое))) А вот к падениям стг 1-2 раза в сутки лучше просто привыкнуть. Я уже почти привык, искать надоело, потому как непонятно ЧТО искать. Осталось еще 120 юзеров приучить к падениям сервера и отвалу инета на 15-70сек. в зависимости от того в какой момент минуты он упадет

MRTG - мониторит сеть и не только. примеры конфигов на офф сайте, и еще модификаций всяких куча.

Ты таки присел на антидепресанты пока ставил стг+мускуль, дальше только суицид...лучше остановись на достигнутом и сделай паузу)))

Отследить это трудновато будет((( Никаких закономерностей нету в падениях этого процесса. А не пройдет ли такой вариант - запускать не один stg-exec, а допустим 2-3. Какие шансы, что упадут все?

И тишина Неужели нет ни одного человека у которого бы СТГ+мускуль работал стабильно? Отзовитесь людииии. P.S.: опять в логе стг зачастили сообщения "Executer exited." вот кусок лога. 2008-10-08 06:02:04 -- Stg started successfully. /// В 6 утра плановый рестарт сервера, так он падает меньше в течении дня 2008-10-08 06:02:04 -- +++++++++++++++++++++++++++++++++++++++++++++ 2008-10-08 15:48:01 -- Executer exited. /// А вот и падение 2008-10-08 15:48:01 -- All executers exited. Stopping stg. 2008-10-08 15:48:01 -- +++++++++++++++++++++++++++++++++++++++++++++ 2008-10-08 15:48:01 -- Module: 'Stg configurator v.0.07'. Stop successfull. 2008-10-08 15:48:01 -- Module: 'Pinger v.1.01'. Stop successfull. 2008-10-08 15:48:01 -- Module: 'Always Online authorizator v.1.0'. Stop successfull. Пожалуйста проясните мне такую ситуацию.

Будут..будут.. и по 50-150 будут. Осталось только дождаться..

Как это глянуть? Разве сейчас мы используем транзакции, БД вроде myISAM? Или может покажите все значения переменных мускуля на сервере который работает без падений

Файловую систему правил я использовал пока юзеров было 20-30. При большом количестве народу даже минимальная смена любого из параметров повлечет неимоверный гемор с редактированием всех файлов. Поэтому использую динамические правила, которые создаются при коннекте юзера и удалябтся при дисконнекте. Использование HTB не принципиально, но он дает возможность использовать свободную полосу...В CBQ я такого параметра не вычитал. В данный момент все вроде нормально работает. Входящий траф режется жестко (пришлось отключить на время использование свободной полосы), исходящий тоже вроде без нареканий порезало через метки iptables. Но все таки хотелось бы решить задачу с использованием полосы по максимуму.

+1 PCI 10/100

А что он покажет при коротком замыкании?

А в чем проблема мопеда-роутера?

Если хорошенько подумать, то больше всего сессий плодят P2P приложения. Поэтому рекомендовал бы фильтровать их и резать сессии, все остальное не сможет так положить каналы ИМХО. Для этого можно использовать связку модулей ipp2p и connlimit. Когдато пробовал такой вариант iptables -A FORWARD -s $user_ip -m ipp2p --ipp2p -m connlimit --connlimit-above 5 -j DROP И все замечательно резало.

Тут подумаю насчет корневого класса. Изначально во время тестов все шейпалось отлично (онлайнеров на тесте было 3-5 всего), и внутрь и наружу. Проблема именно появилась при большом онлайне. Буду думать. За пендаль на опеннет спасибо конечно, но все, что я делал, вычитывал и оттуда тоже. Адрес этот знаю хорошо. Но сюда я написал пытаясь найти помощь, а не редирект на опеннет.

По поводу 10мбит на интерфейсе, не думаю что это критично. По исходящему, вполне может быть...Тут я не уверен ни в чем((( Сейчас сделал таким образом Старт: tc qdisc add dev eth0 root handle 1: htb default 999 tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit ceil 100Mbit burst 10k И правила для каждого: tc class add dev eth0 parent 1:1 classid 1:$hex htb rate $speedmin ceil $speedmax burst 100k tc filter add dev eth0 protocol ip parent 1: handle 800::$hex prio 2 u32 match ip dst $IP flowid 1:$hex tc qdisc add dev eth0 parent 1:$hex handle $hex: sfq perturb 10 Исходящий пока отключил. Онлайн 35, вроде еще никто не жаловался. Если есть спецы по данному вопросу, помогите пожалуйста разрулить тему шейпа. У меня крышу сносит, когда пытаюсь раздуплить его.

Скорости канала хватает.... 10Мбит При таком количестве онлайнеров и таких скоростях, думаю должно хватать...

это скорость интерфейса.

Вкратце суть проблемы. Есть сервер Debian на нем СТГ, есть куча юзеров с анлимами которым режу скорость с помощью HTB. В последнее время, когда онлайн переваливает за 40 юзеров, появляются проблемы со скоростью у некоторых. Вместо положенных 128-256кбит у юзеров 20-30кбит...или вообще ничего не открывается. Через некоторое время опять все стает в норму. Подскажите куда покопать. Вот все что касается шейпера Старт родительского класса tc qdisc add dev eth0 root handle 1: htb default 999 tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit ceil 100Mbit burst 1024k Далее в скрипте OnConnect старгазера даю юзеру полосу, соответствующую его тарифу hex=$ID hexa=$ID let "hex += 800" let "hexa += 801" case $tariff in u_32) speedmin=32kbit;speedmax=128kbit;uploadmin=32kbit;uploadmax=64kbit;; u_64) speedmin=64kbit;speedmax=256kbit;uploadmin=32kbit;uploadmax=64kbit;; esac if [[ $tariff = u_32 || $tariff = u_64 ]] then #исходящий tc class add dev eth0 parent 1:1 classid 1:$hexa htb rate $uploadmin ceil $uploadmax burst 40k tc filter add dev eth0 protocol ip parent 1: handle $hexa prio 1 fw classid 1:$hexa #входящий tc class add dev eth0 parent 1:1 classid 1:$hex htb rate $speedmin ceil $speedmax burst 100k tc filter add dev eth0 protocol ip parent 1: handle 800::$hex prio 3 u32 match ip dst $IP flowid 1:$hex fi Помогите решить задачу.

Плагин и не врубал. Да и не падал больше с таким сообщением. Падать после отключения детайлстат стал намного меньше, раз в 1-2 суток. Что есть большой прогресс. Вот только светофорить стал иногда. arp -n | wc -l cat /proc/sys/net/ipv4/neigh/default/gc_thresh* делал, переполнения нету у меня треш 512, 1024, 2048 а арп показует 100-150 не более.

Это чтоб поддержать разговор? А по-существу?

Вот и прошел отпуск. Начинаем трудовые будни. Запустил сервер Stg v. Stg 2.404 + mysql_store v.0.68-mutex (STG-Web) Он честно отработал АЖ 12 часов и сейчас вот падает с завидной регулярностью 5-10 минут в среднем. Вылетает в segfault. Система как и раньше debian. Уже собрал с дебагом. Как только упадет, посталю на дебаг, хотя я уже это делал и результатов положительных это не принесло. Сейчас вот, как писали выше, немного подправил mysql_store.cpp while (stIter != statTree->end()) { sprintf(qbuf,"INSERT INTO detailstat_%02d_%4d SET login='%s', day=%d, startTime='%s', endTime='%s', IP='%s', dir=%d, down=%lld, up=%lld, cash=%f, sess_id='%s'", lt->tm_mon+1, lt->tm_year+1900, login.c_str(), lt->tm_mday, stTime.c_str(), endTime.c_str(), inet_ntostr(stIter->first.ip), stIter->first.dir, stIter->second.down, stIter->second.up, stIter->second.cash, sessionID.c_str() ); if( (retRes = MysqlQuery(qbuf)) ) { errorStr = "Couldn't insert data in WriteDetailedStat."; return MysqlReConnect(); } Работает уже больше 15 минут. ========= Допишу еще немножко. Таки опять упал. стартовал норм 2008-09-06 15:42:56 -- Stg started successfully. а падал както необычно. такого он мне еще не писал. 2008-09-06 19:47:01 -- Executer exited. 2008-09-06 19:47:01 -- All executers exited. Stopping stg. Что посоветуете в такой ситуации?

В хреновых, но работает

Фигасе... Нада хоть иногда телик смотреть и новости читать.... Я даже не знал об этом.

Есть кто живой? В аську написал - тишина.. Где продавец делся? Или кому то не качественный товар продал....и мы его больше не увидим

$stg_host = "192.168.51.222"; // IP-адрес сервера STG а не 127.0.0.1