IBAnalyst: Как правильно получить статистику из базы данных InterBase/Firebird

Дмитрий Кузменко, последнее обновление 31-03-2014

Аннотация

Этот документ посвящен советам и приемам по сбору и анализу статистики из баз данных InterBase/Firebird с использованием IBAnalyst или без него.

Правильное время, правильное место

Это звучит странно, но просто снятие статистики через gstat или Services API недостаточно. Статистика должна сниматься в правильный момент, чтобы показать, как приложения влияют на данные и транзакции в базе данных. Худшее время для снятия статистики:

• Сразу после восстановления (restore)
• После резервного копирования (gbak -b db.gdb) без ключа -g
• После ручного sweep (gfix -sweep)

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

Как поймать момент, когда в базе данных что-то не так?

Да, ваши приложения могут быть спроектированы настолько идеально, что они всегда будут правильно работать с транзакциями и данными, не создавая промежутков sweep, множества активных транзакций, длительных snapshot и так далее. Обычно этого не происходит. По крайней мере, потому что некоторые разработчики тестируют свои приложения с 2-3 одновременными пользователями, не более. Таким образом, когда они устанавливают написанные приложения для 15 и более одновременных пользователей, база данных может вести себя непредсказуемо. Конечно, многопользовательский режим может работать нормально, потому что большинство многопользовательских конфликтов можно протестировать с 2-3 одновременно работающими приложениями. Но затем, когда будет работать больше одновременных приложений, могут возникнуть проблемы со сборкой мусора (как минимум). И это можно обнаружить, если снимать статистику в правильные моменты.

Если у вас нет периодических проблем с производительностью

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

Наиболее ценная информация - это нагрузка транзакций и накопление версий. Это можно увидеть только в том случае, если вы настроите регулярное сохранение статистики.

InterBase не имеет внутреннего планировщика задач, поэтому вы можете использовать любой внешний, например, стандартный Планировщик задач (Windows) или cron (Unix).

Лучшая настройка - получать почасовую статистику транзакций. Это можно сделать, запустив

gstat -h db.gdb >db_stat_.txt

где

db.gdb - имя вашей базы данных,

db_stat_.txt - текстовый файл, куда будет сохранена статистика,

• текущая дата и время снятия статистики.

Если у вас есть периодические проблемы с производительностью

Эти проблемы обычно вызваны автоматическим запуском sweep. Сначала вам нужно определить период времени между такими падениями производительности. Затем разделите этот интервал минимум на 4 (8, 16 и так далее). Сейчас информационные системы имеют много одновременных пользователей, и большинство проблем с производительностью при не настроенном сервере и базе данных происходят 2 или 3 раза в день. Например, если падения производительности происходят каждые 3 часа, вам нужно снимать

gstat -h db.gdb

статистику каждые 30-45 минут, и

gstat -a -r db.gdb -user SYSDBA -pass masterkey

каждые 1-1.5 часа.

Лучше всего снимать статистику gstat -a -r непосредственно перед ожидаемым падением производительности. Это покажет, где находится реальный мусор и сколько устаревших версий записей накопилось.

Что делать с этой статистикой

Если ваше приложение явно использует транзакции и использует их хорошо, то есть вы знаете, что такое read_committed и когда его использовать, ваши snapshot транзакции длятся не дольше, чем нужно, и транзакции активны минимальное время, вы можете настроить интервал sweep или отключить его, и тогда заботиться только о том, сколько обновлений делает(ют) приложение(я) и какие таблицы нужно обновлять реже или следить за обновлениями.

Что это значит, спросите вы? Мы приведем пример некоторой системы, где проблемы с производительностью возникали каждое утро в течение 20-30 минут. Это было очень существенно для “утренних” приложений и не могло длиться дольше.

Администратору базы данных были заданы правильные вопросы, и вот картина:

Ежедневная работа была разделена на секции - аналитики работают утром, затем данные вставляются и редактируются обычными операторами, а в конце дня запускаются специальные процедуры для сбора данных, которые будут использоваться аналитиками на следующий день (как минимум).

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

И ответ на эту проблему был найден простой - запускать gfix -sweep в конце дня.

Sweep читает все таблицы в базе данных и пытается собрать все мусорные версии для зафиксированных и откаченных транзакций. После sweep база данных становится чистой почти как после восстановления.

И “утренняя проблема” исчезла.

Итак, вам нужно рассматривать статистику с учетом многих других факторов:

1. сколько одновременных пользователей (в среднем) работают в течение дня

2. какова продолжительность рабочего дня (8, 12, 16, 24 часа)

3. какие приложения работают в разное время дня и как они влияют на данные, используемые другими приложениями, работающими в то же время или позже. То есть вы должны понимать бизнес-процессы, происходящие в течение всего дня и всей недели.

Когда DBA ничего не может сделать

К сожалению, такие ситуации случаются. И снова пример:

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

К сожалению, приложения были написаны с BDE и вообще без использования транзакций; то есть вся обработка транзакций была автоматической и использовалась самим BDE. Это приводило к тому, что некоторые транзакции оставались активными в течение длительного времени, и мусор (версии записей) накапливался до тех пор, пока DBA не перезапускал сервер. После перезапуска автоматически запускался sweep, и мусор собирался (устранялся).

Все это было вызвано приложениями, потому что они тестировались только с 2-3 одновременными пользователями, а когда их стало ~15, приложения начали создавать очень высокую нагрузку.

Нужно сказать, что в этой конфигурации 70% пользователей только читали данные, а остальные 30% вставляли и обновляли некоторые (!) данные.

В этой ситуации единственное, что может улучшить производительность, - это полностью переработать приложения.

Остались вопросы? Спросите нас по адресу [email protected]