День добрый.
Буквально в двух словах о проекте.
Это ПО для автоматизированной системы коммерческого учета электроэнергии. Есть около 200 точек учета, каждая из которых имеет до 4 каналов измерения (активная/реактивная энергия, прием/отдача), итого около 700. Раз в полчаса для каждой точки учета в таблицу значений пишется очередная получасовка (энергия за полчаса, данные со счетчика), т.е. за день набегает примерно 33600 записей. Кроме того, после записи в таблицу значений срабатывает триггер, который в таблице последних данных обновляет время и дату получения этих самых данных. Здесь первая проблема - база пухнет со страшной силой из-за версий (если сморозил чушь - поправьте плиз), ибо после бакап-рестора размер базы уменьшается мегабайт на 50-100.
Тем не менее это все прекрасно работало почти полгода, но уже три дня наблюдается такая картина: дополнительный модуль выкачивает данные из базы Oracle и льет их в Firebird (2.0.1) раз в десять минут (в среднем 700-1000 записей каждый влив), коммитит после влива всего набора, и вот после очередной закачки опросник повисает, загрузка процесса SQL-сервера 100%. Виснет он не после первого опроса, а где-то после третьего-четвертого.
Я не прошу (упаси бог) попытаться посмотреть мой код чтобы найти ошибку в генах, там все просто и тривиально. Просьба лишь подсказать, в какую сторону копать? К примеру, может быть есть ограничение на количество записей в таблице? Их уже порядка 79-и млн.
Спасибо.
Зависает проект
Модератор: kdv
Re: Зависает проект
Для начала я бы посмотрел на статистику (gstat -r) перед или в момент "зависания"aes писал(а):Просьба лишь подсказать, в какую сторону копать?
ODS 11
http://aevgs.newmail.ru/stat.zip
Здесь собранная статистика (3,25КБ), сформировано через пару минут после "зависания". Таблица, которая вызывает у меня некоторые подозрения - AC_HAH_VAL_LAST.
Просьба посмотреть, ткнуть так сказать носом. Кроме огромного количества версий в указанной таблице я не вижу более проблем
Да, про 79 млн. записей я несколько загнул, это генератор у меня добежал. На самом деле записей всего 6 с чем-то млн., это явно не может быть причиной "зависания".
http://aevgs.newmail.ru/stat.zip
Здесь собранная статистика (3,25КБ), сформировано через пару минут после "зависания". Таблица, которая вызывает у меня некоторые подозрения - AC_HAH_VAL_LAST.
Просьба посмотреть, ткнуть так сказать носом. Кроме огромного количества версий в указанной таблице я не вижу более проблем
Да, про 79 млн. записей я несколько загнул, это генератор у меня добежал. На самом деле записей всего 6 с чем-то млн., это явно не может быть причиной "зависания".
Т.е. когда ужё всё в порядке ? А смысл ? Статистика нужна когда всё только начало висетьaes писал(а):ODS 11
http://aevgs.newmail.ru/stat.zip
Здесь собранная статистика (3,25КБ), сформировано через пару минут после "зависания".
Тогда можно собирать статистику только по ней : gstat -r -t AC_HAH_VAL_LASTaes писал(а):Таблица, которая вызывает у меня некоторые подозрения - AC_HAH_VAL_LAST.
Это не огромное кол-во.aes писал(а):Просьба посмотреть, ткнуть так сказать носом. Кроме огромного количества версий в указанной таблице я не вижу более проблем
Ещё, в качестве эксперимента, можно попробовать не обновлять эту таблицу триггером, а одним апдейтом перед коммитом. Есть шанс, что во время заливки пакета данных одна и таже запись обновляется многократно ?
Да, ещё, - раз генератор добежал до 79млн, а записей всего 6млн - значит есть массовые удаления ?
IBAnalyst-ом смотрел, ничего страшного не увидел.
Уточню кое что по работе ПО.
После каждого влива данных происходит две вещи:
1. Запрашиваю количество записей в таблице последних данных для уборки мусора.
2. Запускаю процедуру сбора статистики, в духе "с такой-то точки учета перестали поступать данные в такое-то время, возобновилось поступление данных с такого-то времени", обновляются записи в таблице статистики.
У каждого шага своя транзакция, коммит естессно после операции.
Сейчас методом научного тыка выяснил, что после третьего опроса все виснет на 1-ом шаге. Если его отключить - так же виснет на втором. При отключении обоих все работает прекрасно. Еще один момент: в процессе зависания в IBExpert спокойно выполняются процедуры обоих шагов.
Да, есть. Если с точки учета данных не было какое-то время, то в процессе заливки, когда данные придут, будут подтягиваться значения по очереди, и для каждого будет срабатывать триггер. Все это идет в рамках одной транзакции, и только когда все данные со всех точек учета вольются - делаю коммит.
Уточню кое что по работе ПО.
После каждого влива данных происходит две вещи:
1. Запрашиваю количество записей в таблице последних данных для уборки мусора.
2. Запускаю процедуру сбора статистики, в духе "с такой-то точки учета перестали поступать данные в такое-то время, возобновилось поступление данных с такого-то времени", обновляются записи в таблице статистики.
У каждого шага своя транзакция, коммит естессно после операции.
Сейчас методом научного тыка выяснил, что после третьего опроса все виснет на 1-ом шаге. Если его отключить - так же виснет на втором. При отключении обоих все работает прекрасно. Еще один момент: в процессе зависания в IBExpert спокойно выполняются процедуры обоих шагов.
Нет, все продолжало висеть, и я собрал статистику в этот момент.Т.е. когда ужё всё в порядке ? А смысл ? Статистика нужна когда всё только начало висеть
Есть шанс, что во время заливки пакета данных одна и таже запись обновляется многократно ?
Да, есть. Если с точки учета данных не было какое-то время, то в процессе заливки, когда данные придут, будут подтягиваться значения по очереди, и для каждого будет срабатывать триггер. Все это идет в рамках одной транзакции, и только когда все данные со всех точек учета вольются - делаю коммит.
Да, было такое, в процессе тестовой эксплуатации. С тех пор много воды утекло, раз десять делался бакап-рестор, полгода проработало нормально.Да, ещё, - раз генератор добежал до 79млн, а записей всего 6млн - значит есть массовые удаления ?
Всем спасибо большое за помощь, проблема решена. Ошибка таки оказалась в генах. В работе проекта через полгода эксплуатации стала возникать ситуация, при которой одна из хранимых процедур уходит в бесконечный цикл. Вообще говоря такой ситуации быть не должно в принципе, в соответствии с требованиям к работе систем такого класса (АИИС КУЭ), но безусловно мне не плюс, что я это не предусмотрел.
Осталась еще одна проблема - мусор.
Таблица с последними данными постоянно открыта на всех клиентах для контроля за работой системы, т.е. висит транзакция. После влива данных, как уже говорил, запрашиваю количество записей в этой таблице для уборки мусора, тем не менее при сборе статистики вижу, что мусор не убирается (потому и база после рестора уменьшается примерно на 50 мегабайт после недельной работы). Выполняю sweep в ручном режиме - помогает только в том случае, если клиенты закрыты, иначе же версии остаются.
Компоненты доступа - fibplus, во всех транзакциях TPBMode=tpbReadCommited.
Подскажите, где туплю?
Сейчас планирую сделать коммит и заново старт транзакции (она стартует при открытии таблицы с последними данными) в момент обновления данных на клиенте (оно автоматическое раз в 15 минут). Прав ли я?
Осталась еще одна проблема - мусор.
Таблица с последними данными постоянно открыта на всех клиентах для контроля за работой системы, т.е. висит транзакция. После влива данных, как уже говорил, запрашиваю количество записей в этой таблице для уборки мусора, тем не менее при сборе статистики вижу, что мусор не убирается (потому и база после рестора уменьшается примерно на 50 мегабайт после недельной работы). Выполняю sweep в ручном режиме - помогает только в том случае, если клиенты закрыты, иначе же версии остаются.
Компоненты доступа - fibplus, во всех транзакциях TPBMode=tpbReadCommited.
Подскажите, где туплю?
Сейчас планирую сделать коммит и заново старт транзакции (она стартует при открытии таблицы с последними данными) в момент обновления данных на клиенте (оно автоматическое раз в 15 минут). Прав ли я?
Спасибо, то что нужноОни все равно по умолчанию на write настроены. Надо вручную задать параметры(TPBMode=tpbDefault), убрать write и поставить read в TRParams
Час работы, 6 опросов, версий 0, полет нормальный.
База-то всего ничего, 600 метров (пока), потому 50 - не так уж и мало. Примерно раз в месяц приходилось делать рестор, поскольку начинало очень серьезно тормозить.50 метров после недельной работы - это не то что мусор, но даже не пыль. Так, незначительные колебания рабочего объема при нагревании/охлаждении
Люблю читать ваши комментарии на этом форуме, подавляющее большинство из них отсылают к документации, статьям и т.п.используйте IBAnalyst и читайте хелп к нему.
Не в обиду будь сказано, просто шутить пытался
Как бы там ни было, еще раз спасибо за помощь, тему можно закрывать.
я статьи пишу именно для того, чтобы не пересказывать тысячи раз одно и то же. Кроме того, в IBAnalyst встроен полноценный хелп, с тремя статьями и FAQ.Люблю читать ваши комментарии на этом форуме, подавляющее большинство из них отсылают к документации, статьям и т.п. Smile
Не в обиду будь сказано, просто шутить пытался
таким образом, если я отсылаю к статье, то я точно знаю, что вопрос решается внимательным прочтением статьи. Чего зря воду на форуме толочь?
Люди-то обычно как делают:
- Аааа!! у меня проблема! Подскажите!
- прочитай то и это
- Нет, вы мне сейчас подскажите, а я потом или прочитаю или не прочитаю
и спрашивается, нафига тогда вообще сайт ibase.ru?