den68 0 Опубліковано: 2008-01-11 20:11:18 Share Опубліковано: 2008-01-11 20:11:18 58 processes: 57 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 1.1% user 30.0% system 0.0% nice 0.0% iowait 67.1% idle CPU1 states: 3.0% user 22.0% system 0.0% nice 0.0% iowait 74.0% idle CPU2 states: 3.0% user 9.1% system 0.0% nice 0.0% iowait 86.1% idle CPU3 states: 37.1% user 5.1% system 0.0% nice 0.0% iowait 56.0% idle Mem: 2070032k av, 671088k used, 1398944k free, 0k shrd, 156272k buff 188996k active, 161600k inactive Swap: 779144k av, 0k used, 779144k free 194232k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 27730 root 1 -19 31216 30M 2020 S < 69.6 1.5 62:56 2 stargazer2_4 1550 mysql 9 0 19368 18M 2348 S 6.4 0.9 7:37 2 mysqld и так до 98% CPU это на 4x3.2 Xeon в таком режиме как правило долго не живет - падает. Ссылка на сообщение Поделиться на других сайтах
nallien 3 Опубліковано: 2008-01-12 07:10:31 Share Опубліковано: 2008-01-12 07:10:31 отписываюсь по пробле при удалении пользователя с графического конфигуратора - действительно, если предварительно пользователя отключить - удаляется без проблем! после этого попробовал удалить пользователя (офлайн, но не "отключен") конфигуратор выругался кучей пустых окошек (ака сообщения о ошибке) в это время в поле "баланс" и "предоплачено" пользователя появилось числа дробные что-то вроде 1,732489134 но пользователь удалился, сервер не упал как было до этого. зы. юзаю файловое хранилище БД Ссылка на сообщение Поделиться на других сайтах
Watson 0 Опубліковано: 2008-01-12 08:30:40 Share Опубліковано: 2008-01-12 08:30:40 отписываюсь по пробле при удалении пользователя с графического конфигуратора - действительно, если предварительно пользователя отключить - удаляется без проблем! после этого попробовал удалить пользователя (офлайн, но не "отключен") конфигуратор выругался кучей пустых окошек (ака сообщения о ошибке) в это время в поле "баланс" и "предоплачено" пользователя появилось числа дробные что-то вроде 1,732489134 но пользователь удалился, сервер не упал как было до этого. зы. юзаю файловое хранилище БД Я такого не замечал, удалял "Отключеных", "Замороженых", "Всегда онлайн" все без ошибок, сервер при этом не падал.ПОследняя новогодняя сборка с поленовогодними исправлениями. Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2008-01-12 08:53:39 Share Опубліковано: 2008-01-12 08:53:39 была проблема с удалением причина - не правильные индексы, а точнее нарушение форейджин кеев после падения базы лечилось пересозданием и чисткой... консольный конфигуратор сообщения не оправляет... уже давно... далее... не правильно построенна работа с транзакциями... стг очень долго их держит... за более чем месяц загрузка проца выростает с жалких 5-8 до 80%, это на пеньке4... бекап/рестор - спасет... но загрузка начинает снова расти... клиника короче Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 09:31:37 Share Опубліковано: 2008-01-12 09:31:37 Stg держит транзакцию только на время записи данных. Не больше и не меньше. В последней версии у модуля Firebird появилось 2 новых параметра: isolationLevel и lockResolution. Они описанны в прилагающейся документации. Посмотрите - может это Вам поможет. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 09:34:31 Share Опубліковано: 2008-01-12 09:34:31 Не совсем понял как могут быть нарушены Foreign Keys - это же основа целостности БД. СУБД просто не допустила бы их нарушения. По поводу неотправки сообщений: бага была, она давно пофикшена, нужно просто перезалить исходники. Постараемся сделать это в ближайшее время. Ссылка на сообщение Поделиться на других сайтах
den68 0 Опубліковано: 2008-01-12 10:27:55 Share Опубліковано: 2008-01-12 10:27:55 По поводу неотправки сообщений: бага была, ..... в ближайшее время. Очень! Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2008-01-12 11:38:52 Share Опубліковано: 2008-01-12 11:38:52 Stg держит транзакцию только на время записи данных. Не больше и не меньше.В последней версии у модуля Firebird появилось 2 новых параметра: isolationLevel и lockResolution. Они описанны в прилагающейся документации. Посмотрите - может это Вам поможет. не сомневаюсь вот только пишет оно все время... сделать свип - не возможно никогда... все время дедлок ибаналист - пишет sweep gap больше чем среднее количество транзакци в день у меня их в день до млн... так же большое количество транзакий в транзакшн инвентори пейджес короче, рост загрузки проца со временем - это факт у меня доходило до 80%, это при том что размер базы не сильно ростет, а детайл-стат - я отключил ваще... Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2008-01-12 11:41:19 Share Опубліковано: 2008-01-12 11:41:19 Не совсем понял как могут быть нарушены Foreign Keys - это же основа целостности БД. СУБД просто не допустила бы их нарушения. легко база уронилась... ремонтировалась часть данных была беззаветно потеряна рестор делался с неактивными индексами - вот и ответ на вопрос лечится так же легко как и роняется Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 14:23:38 Share Опубліковано: 2008-01-12 14:23:38 вот только пишет оно все время...сделать свип - не возможно никогда... все время дедлок Попробуй увеличить StatWritePeriod (нужно как-то прикинуть, сколько времени у тебя занимает запись статистики всех пользователей и сделать период, скажем, в 3 раза больше) и делать свип точно в промежутке между периодами записи. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 16:24:56 Share Опубліковано: 2008-01-12 16:24:56 не правильно построенна работа с транзакциями... стг очень долго их держит... за более чем месяц загрузка проца выростает с жалких 5-8 до 80%, это на пеньке4... бекап/рестор - спасет... но загрузка начинает снова расти... клиника короче Начитался ibase.ru Stg не держит долго транзакции (это было-бы как минимум странно). Он оборачивает в транзакцию запись статы и конфа каждого пользователя. Это приводит к тому, что набирается много "мусора", а очистка не происходит, т.к. Oldest Interesting Transaction и так является самой "верхней". Невозможность (блокировка) запуска gfix -sweep - это результат слышком частой записи статистики и конфов пользователей. Фактически, разные процессы записи могут даже накладываться друг на друга, что приводит к непрерывной записи (в плагине стоит мьютексная блокировка, по этому наложение приводит только к задержке). Это все мои предположения (сегодня поставим сервак на проверку этой версии). Интересно было-бы глянуть вывод верхушки gstat на вашей базе. Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2008-01-12 17:31:28 Share Опубліковано: 2008-01-12 17:31:28 база уже бекапленна/ресторенна Database header page information: Flags 0 Checksum 12345 Generation 8268432 Page size 4096 ODS version 10.1 Oldest transaction 121 Oldest active 8268422 Oldest snapshot 8268422 Next transaction 8268423 Bumped transaction 1 Sequence number 0 Next attachment ID 0 Implementation ID 19 Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Jan 5, 2008 10:10:17 Attributes force write для себя я конечно нашел способ борьбы... профилактика, можно свип, а можно и бекап/ресторе... ЗЫ тут сложно что-то посоветовать разработчикам, ибо я прекрасно понимаю как и сколько данных постоянно туда-сюда... главная загвоздка, что нет времени когда загрузки нет - долбанные юзеры постоянно качают так что только профилактика Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 19:31:06 Share Опубліковано: 2008-01-12 19:31:06 ... Oldest transaction 121 Oldest active 8268422 Oldest snapshot 8268422 Next transaction 8268423 ... "Вот он! Вот этот тип гражданской наружности!" (с) Собсно, причина видна: Oldest transaction 121 Next transaction 8268423 Застревание Oldest transaction буквально означает, что где то в базе данных есть версии записей, которые однозначно являются мусором и должны быть удалены. В то же время застревание Oldest transaction не говорит о том, что в базе данных накапливается мусор - если все записи в базе данных так или иначе прочитываются приложениями, то вероятнее всего накопленные мусорные версии будут удалены посредством кооперативной сборки мусора (фоновой или явной). Фоновая сборка (к стати, Firebird, случайно, не 2-й ветки?) мусора не срабатывает, т.к. в базу постоянно идет запись (это не зависит от активности пользователей). По этой-же причине не работает и явная. Однозначно надо увеличивать период записи статистики в базу. Иначе хана Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-12 19:33:12 Share Опубліковано: 2008-01-12 19:33:12 ...для себя я конечно нашел способ борьбы... профилактика, можно свип, а можно и бекап/ресторе... ... Чтобы бекап/ресторе был эквивалентен свипу его нужно делать с определенными ключами. На вскидку не скажу, но сегодня на ibase.ru натыкался на них. Ссылка на сообщение Поделиться на других сайтах
den68 0 Опубліковано: 2008-01-12 20:10:45 Share Опубліковано: 2008-01-12 20:10:45 2008-01-12 13:31:27 -- Stg v. Stg 2.404 2008-01-12 13:31:27 -- Message queue created successfully. msgKey=5555 msgID=65536 2008-01-12 13:31:27 -- Timer thread started successfully. 2008-01-12 13:31:27 -- Storage plugin: mysql_store v.0.67. Loading successfull. 2008-01-12 13:31:33 -- Users started successfully. 2008-01-12 13:31:33 -- Traffcounter started successfully. 2008-01-12 13:31:33 -- Module: 'ipq_cap v.1.1'. Start successfull. 0 2008-01-12 13:31:33 -- Module: 'InetAccess authorizator v.1.1'. Start successfull. 50 2008-01-12 13:31:33 -- Module: 'InetAccess authorizator v.1.1'. Start successfull. 50 2008-01-12 13:31:33 -- Module: 'Always Online authorizator v.1.0'. Start successfull. 70 2008-01-12 13:31:33 -- Module: 'Stg configurator v.0.07'. Start successfull. 220 2008-01-12 13:31:33 -- Stg started successfully. 2008-01-12 13:31:33 -- +++++++++++++++++++++++++++++++++++++++++++++ Грузит 2 раза ? Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2008-01-13 10:14:43 Share Опубліковано: 2008-01-13 10:14:43 Однозначно надо увеличивать период записи статистики в базу. Иначе хана Макс, у меня ваще не пишется детайл-стат Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-13 12:08:56 Share Опубліковано: 2008-01-13 12:08:56 Макс, у меня ваще не пишется детайл-стат Есть обычная, а есть - детальная статистика. # Время через которое пишется d БД детальная статистика пользователя # Значения: 1, 1/2, 1/4, 1/6. # 1 - раз в чаc, 1/2 - раз в пол часа, 1/4 - раз в 15 мин, 1/6 - раз в 10 мин DetailStatWritePeriod=1/6 # Периодичность записи записи в БД информации о статистике пользователя (минуты) # При большом кол-ве пользователей эту величину стоит увеличить, т.к. # запись в БД может занимать длительное время. # Значения: 1...1440 (минуты) StatWritePeriod = 10 Вот обычную нужно замедлить. Ссылка на сообщение Поделиться на других сайтах
den68 0 Опубліковано: 2008-01-13 17:32:25 Share Опубліковано: 2008-01-13 17:32:25 To: madf,stg34 А нельзя выложить изменения где поправленны сообщения отсылаемые из КК ? текущая ситуация: 58 processes: 56 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 0.2% user 7.0% system 0.0% nice 0.0% iowait 91.1% idle CPU1 states: 100.0% user 0.0% system 0.0% nice 0.0% iowait 0.0% idle CPU2 states: 9.0% user 6.1% system 0.0% nice 0.0% iowait 83.1% idle CPU3 states: 2.0% user 3.1% system 0.0% nice 0.0% iowait 93.1% idle Mem: 2070032k av, 181848k used, 1888184k free, 0k shrd, 45012k buff 46128k active, 33908k inactive Swap: 779144k av, 0k used, 779144k free 34940k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 1565 root 1 -19 34572 33M 1960 S < 99.9 1.6 44:18 3 stargazer2_4 1562 mysql 9 0 3120 3116 2312 S 2.4 0.1 1:37 2 mysqld ping к хосту где стг ходит через один, вых. нагрузка 50 Мб/сек. на свиче, 700 юзеров. Общее впечатление что модуль ipq_cap вносит свою лепту Ссылка на сообщение Поделиться на других сайтах
REND 0 Опубліковано: 2008-01-14 14:28:48 Share Опубліковано: 2008-01-14 14:28:48 При сборке дистрибудива stg-2.404.9.7, скачан с сайта выскакивает ошибка: /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ext/mt_allocator.h:614: note: candidates are: void __gnu_cxx::__mt_alloc_base<_Tp>::destroy(_Tp*) [with _Tp = RESETABLE<std::string>] gmake[2]: *** [ao.o] Ошибка 1 gmake[2]: Leaving directory `/+DISTR/stg-2.404.9.7/projects/stargazer/plugins/authorization/ao' gmake[1]: *** [authorization/ao] Ошибка 2 gmake[1]: Leaving directory `/+DISTR/stg-2.404.9.7/projects/stargazer/plugins' gmake: *** [plugins] Ошибка 2 gcc -v: gcc version 4.0.0 20050519 (Red Hat 4.0.0-8) uname -a: Linux ftp.zoo-net.ru 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 athlon i386 GNU/Linux собирался скриптом build Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-14 14:55:01 Share Опубліковано: 2008-01-14 14:55:01 1. Было бы неплохо увидеть больший кусок лога. То что привели Вы - это конец, а не начало ошибки. 2. Судя по приведенному, скорее всего проблема в установке вашего компилятора. Такое уже было на какой-то SuSE. Попробуйте или более старую или более новую версию. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-14 15:04:56 Share Опубліковано: 2008-01-14 15:04:56 To: madf,stg34А нельзя выложить изменения где поправленны сообщения отсылаемые из КК ? текущая ситуация: 58 processes: 56 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 0.2% user 7.0% system 0.0% nice 0.0% iowait 91.1% idle CPU1 states: 100.0% user 0.0% system 0.0% nice 0.0% iowait 0.0% idle CPU2 states: 9.0% user 6.1% system 0.0% nice 0.0% iowait 83.1% idle CPU3 states: 2.0% user 3.1% system 0.0% nice 0.0% iowait 93.1% idle Mem: 2070032k av, 181848k used, 1888184k free, 0k shrd, 45012k buff 46128k active, 33908k inactive Swap: 779144k av, 0k used, 779144k free 34940k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 1565 root 1 -19 34572 33M 1960 S < 99.9 1.6 44:18 3 stargazer2_4 1562 mysql 9 0 3120 3116 2312 S 2.4 0.1 1:37 2 mysqld ping к хосту где стг ходит через один, вых. нагрузка 50 Мб/сек. на свиче, 700 юзеров. Общее впечатление что модуль ipq_cap вносит свою лепту ipq_cap сильнее нагружает машину, но он гарантирует 100% перехват трафика. ether_cap меньше нагружает машину, но может пропускать пакеты. Такие дела... Для файла projects/sgconf/main.cpp: @@ -592,7 +592,8 @@ break; case 'm': //message - ParseMessage(optarg, &req.usrMsg); + //ParseMessage(optarg, &req.usrMsg); + req.usrMsg = optarg; break; case 'e': //Prepaid Traffic Вот, примерно, как-то так. ВНИМАНИЕ! Этот код не предназначен для patch! Это просто кусочек diff'а из CVS Ссылка на сообщение Поделиться на других сайтах
den68 0 Опубліковано: 2008-01-14 18:42:46 Share Опубліковано: 2008-01-14 18:42:46 ipq_cap сильнее нагружает машину, но он гарантирует 100% перехват трафика.ether_cap меньше нагружает машину, но может пропускать пакеты. Такие дела... Дык, в топ посмотрите 4шт. - 3.2 Xeon ! 100% загружен один проц, остальные ещн как-то свободны - а пакеты теряються ! вот это непонятно. С ether_cap почемуто неработает авторизатор На версии 2.0.16 тянуло тоже самое через ipq и никаких проблем ... За код - спасибо. Ссылка на сообщение Поделиться на других сайтах
Watson 0 Опубліковано: 2008-01-14 21:14:11 Share Опубліковано: 2008-01-14 21:14:11 2008-01-14 21:07:12 -- User's connect failed. IP '192.168.13.49'. Wrong login or password 2008-01-14 21:21:06 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:21:12 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:21:53 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:21:59 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:23:14 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:23:20 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:23:26 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' 2008-01-14 21:33:13 -- User's connect failed:: user 'Ryzhenko' not found. IP '192.168.48.195' 2008-01-14 21:33:25 -- User's connect failed:: user 'Ryzhenko' not found. IP '192.168.48.195' 2008-01-14 21:33:28 -- User's connect failed:: user 'Ryzhenko' not found. IP '192.168.48.195' 2008-01-14 21:33:31 -- User's connect failed:: user 'Ryzhenko' not found. IP '192.168.48.195' 2008-01-14 21:33:45 -- User's connect failed:: user 'Ryzhenko' not found. IP '192.168.48.195' 2008-01-14 21:35:31 -- Stg v. Stg 2.404 2008-01-14 21:35:31 -- Message queue created successfully. msgKey=5555 msgID=98304 2008-01-14 21:35:31 -- Timer thread started successfully. 2008-01-14 21:35:32 -- Storage plugin: file_store v.1.02. Loading successfull. 2008-01-14 21:35:33 -- Users started successfully. 2008-01-14 21:35:33 -- Traffcounter started successfully. 2008-01-14 21:35:33 -- Module: 'ipq_cap v.1.1'. Start successfull. 0 2008-01-14 21:35:33 -- Module: 'InetAccess authorizator v.1.2'. Start successfull. 50 2008-01-14 21:35:33 -- Module: 'Always Online authorizator v.1.0'. Start successfull. 70 2008-01-14 21:35:33 -- Module: 'Pinger v.1.01'. Start successfull. 100 2008-01-14 21:35:33 -- Module: 'Stg configurator v.0.07'. Start successfull. 220 2008-01-14 21:35:33 -- Stg started successfully. 2008-01-14 21:35:33 -- +++++++++++++++++++++++++++++++++++++++++++++ 2008-01-14 21:39:13 -- User's connect failed:: user 'benedik' not found. IP '192.168.49.17' 2008-01-14 21:39:20 -- User's connect failed:: user 'benedik' not found. IP '192.168.49.17' Поставил в субботу вечером уже на рабочую машину x86_64 с +2000 юзеров, стг-2.404, резулльтат неважный...Сервер упал а на тестовой 32бит проработал неделю и не падал. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-14 22:30:33 Share Опубліковано: 2008-01-14 22:30:33 Дык, в топ посмотрите 4шт. - 3.2 Xeon ! 100% загружен один проц, остальные ещн как-то свободны - а пакеты теряються ! вот это непонятно. С ether_cap почемуто неработает авторизатор На версии 2.0.16 тянуло тоже самое через ipq и никаких проблем ... За код - спасибо. Если пакеты теряются - значит они не попадают под правила файрвола для коллектора. ipq не может терять пакеты по определению. Если с ether_cap не работает авторизатор - скорее всего опять проблема в файрволле. По поводу нагрузки: попробуйте пустить в дебаговом режиме и посмотреть - что это он там такое делает, что 99% проца грузит. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2008-01-14 22:32:46 Share Опубліковано: 2008-01-14 22:32:46 ...2008-01-14 21:21:06 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69' ... А с базой все в порядке? Не похерилась? Права на файлы нормальные? Юзер-то не найден. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения