den68

попробуй собрать с либами -lmysqlclient_r -lpthread, -lmysqlclient убрать, править в Makefile А вообще лучше взять более свежую версию, заточена под 2.405.х mysql_store.0.68-mutex

при запуске новой версии mysql модуль пишет про андефайнед символ компресс

libmysqlclient_r.so - это динамическая либа, а он линкуется со статикой, libmysqlclient_r.a

Makefile: include ../../../../../Makefile.conf PROG = mod_store_mysql.so SRCS = ./mysql_store.cpp LIBS = -lstg_locker -lstg_common -lconffiles SEARCH_DIRS += -I /usr/include/mysql LDFLAGS += -lmysqlclient -L /usr/lib/mysql include ../../Makefile.in

кстати, на ipq с параметрами тормозит: #define FLUSH_TIME (8) // 10 #define REMOVE_TIME (10) // 31 кстати, на ipq с параметрами не тормозит: #define FLUSH_TIME (5) // 10 #define REMOVE_TIME (8) // 31

при IPQ почти никогда, при EtherCap почти всегда.

Ну вроде при параметрах 5 / 15 и отключенном детайл стате нормализовалось:

результат по загрузке проца пока гуд, в пиках 40-50%, постоянно 8-16%, 750 Онлайн : но надо/пора уже смотреть в сторону bind-9.4.2/lib/isc/task.c

да нет, просто из общего вывода не выкинул. По сути, пока результат положительный, 400 юзеров сосут не вшутку в плане качают, при этом: по сути, порезан трафкаунетр и юзерс цпп. детальная стата прибита в хлам - итог положительный. могу прислать исходники, искать надо именно там ИМХО.

Угу... кстати admin.cpp: WriteServLog("%s", store->GetStrError().c_str()); admin.cpp: WriteServLog(store->GetStrError().c_str()); admins.cpp:strError = "Administrator \'" + login + "\' was not added. Error: " + store->GetStrError(); admins.cpp: strError = "Administrator \'" + login + "\' was not deleted. Error: " + store->GetStrError(); admins.cpp: WriteServLog("%s", store->GetStrError().c_str()); admins.cpp: WriteServLog(store->GetStrError().c_str()); из серии про 6 отличий Попробовал прибить сбор дет. статы, (запись уже была прибита), п

Если загрузка появляется с определенным периодом - это запись статистики или сброс данных траффкаунтера. Можно временно "заглушить" запись статы (в плагине, или в user.cpp (USER::WriteStat)). Если загрузка пропала - это она. Если нет - это траффкаунтер. В файлике traffcounter.cpp есть #define FLUSH_TIME (10) - можно попробывать его уменьшить. Мы с Борей обсуждали недавно этот момент (как раз по поводу твоих тормозов). Возможно, этот параметр будет вынесен в настройки стг. store->WriteDetailStat заглушен давно, однако.... похоже более на переполнение/огромный размер буфера при сборе ста

to madf: какбы отловить место где (на чем) стг создает загрузку 99 проц. ? может есть какая либа типа дебаг ? чтоб контрольные точки прописать ?

доточен еще в кое каких местах модуль mysql-store. брать там-же, архив обновлен mysql_store-mutex Добавлена функция реконнекта и опять пофикшены глюки с буфером - причина падений.

Все сделал - стало еще хуже ############################################################################# Building STG 2.4 for Linux ############################################################################# Makeing stg_logger.lib ../Makefile.in:74: deps: No such file or directory deps:2: *** пропущен разделитель. Останов. не пойму в какую сторону капать ? make/gmake версии этих варезов.

опцию parch -p(0,1,2,3,4,5,6,7,8,9) кто-то отменил ?

Лучше тогда netmond - это намного более функционально...

Улыбнуло Максим, если хочется рассмотреть изменения, ссылка на файл присутствует выше, если ты помниш я принимал участие в финансировании этого и других твоих проектов из соображений развития СТГ не только силами stg-34. К сожалению за полтора года попользоваться этим модулем была не судьба, но при попытке это сделать, половина января была потеряна на поиски глюков...

А команда top в это-же время что говорит ?

Проблема с падениями порешилась переписыванием модуля mysql_store, при рождении, в нем небыло в помине тред локов, что на реальных многопроцессорных платфомах приводило к краху программы. также, пересмотрена схема работы с sql базой, теперь создается только один коннект и держится он постоянно, поскольку по факту, чтение/запись идет тоже постоянно. До этого у меня было до 600!!!! одновременных конектов с базой со статусом тайм_вайт, что есть сакс несомненный и нагрузка на систему, + возможность заюзать все сетевые сокеты на это развлечение. Так-же, чего-то пофикшено по пути, что-то поп

Кстати, а id всегда один и тот-же ? или генерируется случайным образом ? (или одинаков до перезагрузки stg) ?

Кстати, а что такое передается в Онконнект-Ондисконнект: логин - ип - деньги - ???? - направление ?

Ну чего, всем жалко раритетами делится ? не дайте потерять неделю времени! поделитесь исходниками Win sgconf 1.60.7 наверняка же лежит у кого мертвым грузом

to madf: БД mysql, но ее загрузка минимальна, я выше в этом топике приводил статистику. Все остальное понятно - из области сказок, я не могу мотивировать, в противном случае придется сидеть с дебагером неделю, а пользователи хотят работать однако. без нагрузки оно воркает, загрузка проца - сам видел = 100, при этом юзает один проц из 4 для smp при демонизации какието хитрости применяются, глянь намед, дшцп и т.д. Библиотек лишних нету, и вообще я это запускаю из отдельной директории: rm -f /etc/stargazer_2.4/monitor/* #/etc/stargazer_2.4/_run/update_OnDisconn

Нет, я не ошибся. Именно отключить. Вывод лога в консоль в режиме дэмона часто (а на FreeBSD - всегда) приводил к SIGPIPE. madf, я специально, в ручную включал в версии скомпиленной с дебагом - эта более 10 минут не работает, рядом лежит другая, без дебага, результат тамже, работает дольше иногда.... 1. Мне кажеться что падение с сегфаулт как-то привязано к детальной статистике. 2. с тех пор как в СТГ появился кусок либы ipq у меня все версии стг тормозят и теряют пакеты вплоть до полной картины плохо обжатого провода. 3. При сборе статистики через ethercap (далее чудеса) скачиваетьс

to stg-34: если незатруднит, поясни плз. какая задумка была насчет файла UpdateMsg.txt в конфиг директории ? Всем кто коннектится его показывать ?