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

Введение

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

В правильное время

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

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

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

Как поймать состояние базы данных, когда там не все хорошо?

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

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

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

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

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

Лучше всего получать информацию о транзакциях один раз в 1-2 часа . Например,

gstat –h db.gdb >db_stat_.txt

где
db.gdb – имя вашей базы данных,
db_stat_.txt – текстовый файл, куда будет сохранена статистика,
– текущие дата и время на момент получения статистики.

И статистику

gstat –r db.gdb –user SYSDBA –pass masterkey

примерно 1 раз в день.

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

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

gstat –h db.gdb

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

gstat –r db.gdb –user SYSDBA –pass masterkey

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

Что делать с полученной статистикой?

Если ваше приложение явно работает с транзакциями, и использует их уровни изолированности корректно, то есть вы знаете что такое read read_committed и когда его использовать, что транзакции snapshot не "живут" дольше чем это нужно, и вообще транзакции "живут" минимально необходимое время, то вы можете установить sweep interval в 0, и дальше беспокоиться только о том, в каких таблицах накапливается много обновлений.

Вы можете спросить – что это значит? Вот пример одной системы, где замедления случались каждое утро примерно на 20-30 минут. Для "утренних" приложений это было очень существенно, и такую ситуацию терпеть дальше было нельзя.

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

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

Решение проблемы было простым – запускать gfix –sweep в конце дня.

Sweep читает записи во всех таблицах, и пытается убрать все мусорные версии, в том числе последствия больших rollback. После чистки база данных становится как новенькая, т.е. как будто после restore.

И, на этом "утренняя проблема" прекратилась.

Таким образом, вы должны рассматривать статистику учитывая многие факторы:

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

Когда администратор БД ничего не может сделать?

Печально, но такие ситуации бывают. И снова пример:

Некоторая система установлена для ~15 пользователей. Периодически производительность ухудшается настолько, что администратор вынужден рестартовать сервер (IB/FB). После рестарта все работает нормально некоторое время, после чего производительность опять потихоньку падает до критического уровня. Статистика показывает, что среднее число транзакций в день ~75000, и есть активные транзакции, "живущие" практически с начала дня и до момента, когда сервер перезагружается.
К несчастью, приложения написаны на BDE, причем без явного управления транзакциями. То есть, BDE управляет транзакциями сам, автоматически. Это приводит к тому, что часть транзакций остается активной непредсказуемо длительное время, версии записей накапливаются, и общая производительность падает до необходимости рестартовать сервер. После рестарта сразу срабатывает автоматический sweep, мусор собирается, но все начинается по новой.

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

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

В этой ситуации единственный способ починить производительность – это переписать приложения.

Дополнения

Статистика по базе данных может быть получена утилитой gstat, через Services API, или сторонними инструментами (IBExpert)
gstat старых версий может выводить информацию по индексам (Max Dup и Total Dup) обрезанной до ~32К или ~64К. Если вы это видите в статистике, воспользуйтесь gstat от более свежих версий InterBase или Firebird. То же самое относится к возможности gstat выдавать информацию по версиям с ключом -r.

Все еще есть вопросы ? Напишите нам на support@ibase.ru