Новая сборка СТГ 2.4

[den68 0]

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]

отписываюсь по пробле при удалении пользователя с графического конфигуратора - действительно, если предварительно пользователя отключить - удаляется без проблем!

 

после этого попробовал удалить пользователя (офлайн, но не "отключен") конфигуратор выругался кучей пустых окошек (ака сообщения о ошибке) в это время в поле "баланс" и "предоплачено" пользователя появилось числа дробные что-то вроде 1,732489134 но пользователь удалился, сервер не упал как было до этого.

 

зы. юзаю файловое хранилище БД

[Watson 0]

отписываюсь по пробле при удалении пользователя с графического конфигуратора - действительно, если предварительно пользователя отключить - удаляется без проблем!

 

после этого попробовал удалить пользователя (офлайн, но не "отключен") конфигуратор выругался кучей пустых окошек (ака сообщения о ошибке) в это время в поле "баланс" и "предоплачено" пользователя появилось числа дробные что-то вроде 1,732489134 но пользователь удалился, сервер не упал как было до этого.

 

зы. юзаю файловое хранилище БД

Я такого не замечал, удалял "Отключеных", "Замороженых", "Всегда онлайн" все без ошибок, сервер при этом не падал.ПОследняя новогодняя сборка с поленовогодними исправлениями.

[Ork Yason 8]

была проблема с удалением

 

причина - не правильные индексы, а точнее нарушение форейджин кеев после падения базы

 

лечилось пересозданием и чисткой...

 

 

консольный конфигуратор сообщения не оправляет... уже давно...

 

 

далее...

 

не правильно построенна работа с транзакциями... стг очень долго их держит... за более чем месяц загрузка проца выростает с жалких 5-8 до 80%, это на пеньке4... бекап/рестор - спасет... но загрузка начинает снова расти... клиника короче

[madf 279]

Stg держит транзакцию только на время записи данных. Не больше и не меньше.

В последней версии у модуля Firebird появилось 2 новых параметра: isolationLevel и lockResolution. Они описанны в прилагающейся документации. Посмотрите - может это Вам поможет.

[madf 279]

Не совсем понял как могут быть нарушены Foreign Keys - это же основа целостности БД. СУБД просто не допустила бы их нарушения.

 

По поводу неотправки сообщений: бага была, она давно пофикшена, нужно просто перезалить исходники. Постараемся сделать это в ближайшее время.

[den68 0]

По поводу неотправки сообщений: бага была, ..... в ближайшее время.

Очень!

[Ork Yason 8]

Stg держит транзакцию только на время записи данных. Не больше и не меньше.

В последней версии у модуля Firebird появилось 2 новых параметра: isolationLevel и lockResolution. Они описанны в прилагающейся документации. Посмотрите - может это Вам поможет.

не сомневаюсь

 

вот только пишет оно все время...

сделать свип - не возможно никогда... все время дедлок

 

ибаналист - пишет sweep gap больше чем среднее количество транзакци в день

у меня их в день до млн...

 

так же большое количество транзакий в транзакшн инвентори пейджес

 

короче, рост загрузки проца со временем - это факт

у меня доходило до 80%, это при том что размер базы не сильно ростет, а детайл-стат - я отключил ваще...

[Ork Yason 8]

Не совсем понял как могут быть нарушены Foreign Keys - это же основа целостности БД. СУБД просто не допустила бы их нарушения.

легко

 

база уронилась...

 

ремонтировалась

часть данных была беззаветно потеряна

рестор делался с неактивными индексами - вот и ответ на вопрос

 

лечится так же легко как и роняется

[madf 279]

вот только пишет оно все время...

сделать свип - не возможно никогда... все время дедлок

Попробуй увеличить StatWritePeriod (нужно как-то прикинуть, сколько времени у тебя занимает запись статистики всех пользователей и сделать период, скажем, в 3 раза больше) и делать свип точно в промежутке между периодами записи.

[madf 279]

не правильно построенна работа с транзакциями... стг очень долго их держит... за более чем месяц загрузка проца выростает с жалких 5-8 до 80%, это на пеньке4... бекап/рестор - спасет... но загрузка начинает снова расти... клиника короче

Начитался ibase.ru

Stg не держит долго транзакции (это было-бы как минимум странно). Он оборачивает в транзакцию запись статы и конфа каждого пользователя. Это приводит к тому, что набирается много "мусора", а очистка не происходит, т.к. Oldest Interesting Transaction и так является самой "верхней".

Невозможность (блокировка) запуска gfix -sweep - это результат слышком частой записи статистики и конфов пользователей. Фактически, разные процессы записи могут даже накладываться друг на друга, что приводит к непрерывной записи (в плагине стоит мьютексная блокировка, по этому наложение приводит только к задержке).

Это все мои предположения (сегодня поставим сервак на проверку этой версии). Интересно было-бы глянуть вывод верхушки gstat на вашей базе.

[Ork Yason 8]

база уже бекапленна/ресторенна

 

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]

...

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]

...

для себя я конечно нашел способ борьбы... профилактика, можно свип, а можно и бекап/ресторе...

...

Чтобы бекап/ресторе был эквивалентен свипу его нужно делать с определенными ключами. На вскидку не скажу, но сегодня на ibase.ru натыкался на них.

[den68 0]

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]

Однозначно надо увеличивать период записи статистики в базу. Иначе хана

Макс, у меня ваще не пишется детайл-стат

[madf 279]

Макс, у меня ваще не пишется детайл-стат

Есть обычная, а есть - детальная статистика.

# Время через которое пишется 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]

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]

При сборке дистрибудива 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]

1. Было бы неплохо увидеть больший кусок лога. То что привели Вы - это конец, а не начало ошибки.

2. Судя по приведенному, скорее всего проблема в установке вашего компилятора. Такое уже было на какой-то SuSE. Попробуйте или более старую или более новую версию.

[madf 279]

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]

ipq_cap сильнее нагружает машину, но он гарантирует 100% перехват трафика.

ether_cap меньше нагружает машину, но может пропускать пакеты.

Такие дела...

Дык, в топ посмотрите 4шт. - 3.2 Xeon ! 100% загружен один проц, остальные ещн как-то свободны - а пакеты теряються ! вот это непонятно.

 

С ether_cap почемуто неработает авторизатор

 

На версии 2.0.16 тянуло тоже самое через ipq и никаких проблем ...

 

За код - спасибо.

[Watson 0]

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]

Дык, в топ посмотрите 4шт. - 3.2 Xeon ! 100% загружен один проц, остальные ещн как-то свободны - а пакеты теряються ! вот это непонятно.

 

С ether_cap почемуто неработает авторизатор

 

На версии 2.0.16 тянуло тоже самое через ipq и никаких проблем ...

 

За код - спасибо.

Если пакеты теряются - значит они не попадают под правила файрвола для коллектора. ipq не может терять пакеты по определению.

Если с ether_cap не работает авторизатор - скорее всего опять проблема в файрволле.

 

По поводу нагрузки: попробуйте пустить в дебаговом режиме и посмотреть - что это он там такое делает, что 99% проца грузит.

[madf 279]

...

2008-01-14 21:21:06 -- User's connect failed:: user 'ruslan0' not found. IP '192.168.77.69'

...

А с базой все в порядке? Не похерилась? Права на файлы нормальные?

Юзер-то не найден.