Перейти до

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


Рекомендованные сообщения

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 545
  • Створено
  • Остання відповідь

Top Posters In This Topic

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

 

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

 

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

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

 

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

 

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

 

 

далее...

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

 

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

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

 

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

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

 

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

 

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

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

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

легко :)

 

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

 

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

 

ЗЫ тут сложно что-то посоветовать разработчикам, ибо я прекрасно понимаю как и сколько данных постоянно туда-сюда... главная загвоздка, что нет времени когда загрузки нет - долбанные юзеры постоянно качают :) так что только профилактика :(

Ссылка на сообщение
Поделиться на других сайтах
...

Oldest transaction 121

Oldest active 8268422

Oldest snapshot 8268422

Next transaction 8268423

...

"Вот он! Вот этот тип гражданской наружности!" (с)

Собсно, причина видна:

Oldest transaction 121

Next transaction 8268423

 

Застревание Oldest transaction буквально означает, что где то в базе данных есть версии записей, которые однозначно являются мусором и должны быть удалены. В то же время застревание Oldest transaction не говорит о том, что в базе данных накапливается мусор - если все записи в базе данных так или иначе прочитываются приложениями, то вероятнее всего накопленные мусорные версии будут удалены посредством кооперативной сборки мусора (фоновой или явной).

 

Фоновая сборка (к стати, Firebird, случайно, не 2-й ветки?) мусора не срабатывает, т.к. в базу постоянно идет запись (это не зависит от активности пользователей). По этой-же причине не работает и явная.

 

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

Ссылка на сообщение
Поделиться на других сайтах
...

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

...

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

Ссылка на сообщение
Поделиться на других сайтах

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 раза ?

Ссылка на сообщение
Поделиться на других сайтах
Макс, у меня ваще не пишется детайл-стат :)

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

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

 

Вот обычную нужно замедлить.

Ссылка на сообщение
Поделиться на других сайтах

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 вносит свою лепту :)

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
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

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

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

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

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

 

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

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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бит проработал неделю и не падал.

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

 

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

 

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

 

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
...

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

...

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

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

Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...