IBAnalyst: cosa puoi vedere nella Vista Riepilogo

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

Аннотация

Этот документ посвящён объяснению информации на странице «Сводный вид» (Summary view) в IBAnalyst, а также тому, как интерпретировать эту информацию для статистики вашей базы данных. Кроме того, мы добавили несколько примеров статистики в установочный пакет, чтобы облегчить вам изучение всех тонкостей статистики InterBase. Они находятся в каталоге Examples установки IBAnalyst.

Если вы не знаете, что такое старейшая транзакция (Oldest transaction), старейший снимок (Oldest snapshot), активная (active) и следующая (Next), пожалуйста, сначала прочитайте статью Крейга Стунца «Понимание времени жизни транзакций»:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Номера транзакций

Если вы прочитали статью «Понимание времени жизни транзакций», возможно, у вас всё ещё остались вопросы по номерам OIT/OST/OAT. Вот краткое описание:


Номер	Удерживается, …	Движется вперёд, …
Старейшая транзакция	когда транзакция с этим номером была откачена и в ней было много изменений данных, или когда соединение с клиентом было потеряно	когда автоматическая или ручная уборка (sweep) завершается успешно.
Старейший снимок	когда снимок (или read committed write до IB 7.1) активен в течение длительного времени (он запоминает старейший активный снимок как свой локальный OST)	когда начинается новая транзакция, если транзакция, удерживающая OST, завершена
Старейшая активная	когда транзакция с этим номером активна в течение длительного времени	когда начинается новая транзакция, если транзакция, удерживающая OAT, завершена
Следующая	никогда	когда начинается новая транзакция

примечание: старейшая транзакция здесь - это то же самое, что старейшая интересная транзакция (OIT), упоминаемая во многих других статьях.

Точная статистика со стандартными настройками

Давайте запустим IBAnalyst и откроем (через меню Statistics/Load statistics from file) файл !allok.txt.

IBAnalyst сообщает не только дату создания базы данных, но также распознаёт текущую дату и время на сервере, если статистика была получена через Services API, или дату и время файла, если загружен файл статистики.

Вот почему мы рекомендуем не изменять файлы статистики, потому что в этом случае IBAnalyst будет неправильно рассчитывать среднее количество транзакций в день. Строка транзакций в день здесь показывает около ~12500 транзакций в день, и база данных «живёт» с момента её создания или восстановления в течение 8 дней.

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

Много активных транзакций

Далее откройте файл !lotofactive.txt (вы можете в любой момент вернуться к картинке !allok, чтобы сравнить следующие примеры с ней).

Здесь строка активных транзакций помечена красным, потому что есть большая разница между старейшей активной и следующей транзакцией. Это означает, что некоторая транзакция на момент снятия статистики всё ещё активна, и после её начала уже запущено 55 000 транзакций (они могут быть в любом состоянии - активные, зафиксированные, откаченные). Поскольку среднее количество транзакций в день составляет ~12500, IBAnalyst показывает вам предупреждение, что некоторая транзакция всё ещё живёт в течение 4,4 дней. Это может произойти, когда:

некоторое приложение всё ещё работает и имеет хотя бы одну открытую транзакцию - возможно, какой-то пользователь держит приложение запущенным в течение длительного времени;
приложение работает долго и теряет дескрипторы транзакций - то есть ваш код (или компоненты/библиотеки, которые вы используете) динамически запускает транзакции и при некоторых обстоятельствах «забывает» завершить их откатом или фиксацией;
ваше приложение не использует явные транзакции (BDE), оставляя обработку транзакций используемым компонентам. В результате время жизни транзакций не контролируется приложением, и вы можете быть уверены, что большинство транзакций Next-OAT действительно активны;
ваше приложение использует драйвер или компоненты, которые допускают «транзакцию по умолчанию». Если ваш код не контролирует эту транзакцию, она может работать очень долго.

К сожалению, статистика не показывает фактическое количество активных транзакций в данный момент. Это можно увидеть только в InterBase 7.x с помощью IBConsole, IB Performance Monitor или через прямой запрос к временной системной таблице tmp$transactions. В Firebird 1.5 вы можете вызвать isc_database_info с параметром isc_info_active_transactions.

Уборка (Sweep)

Теперь откроем !needsweep.txt.

Уборка - это процесс обслуживания внутри InterBase. Уборка проходит по всем записям в базе данных и пытается очистить все устаревшие версии, затем пытается продвинуть номер старейшей транзакции вперёд. В новой созданной базе данных интервал уборки по умолчанию равен 20000. Когда разница между транзакциями (см. таблицу ниже) становится больше интервала уборки, уборка запускается автоматически. Таким образом, вы можете наблюдать периодическое ухудшение производительности вашей базы данных. Например, ваши приложения работают нормально в понедельник и вторник, но в среду пользователи сообщают о проблемах с производительностью в течение нескольких часов, а затем производительность снова становится нормальной.

Если вы видите подобное поведение - это автоматическая уборка.


Версия сервера	Когда запускается уборка
InterBase 7.x	(Старейшая активная - Старейшая) > Интервал уборки
InterBase 4.x, 5.x, 6.x, Firebird до 1.5.2, Yaffil	(Старейший снимок - Старейшая) > Интервал уборки

Таблица 1. Условия запуска автоматической уборки

примечание: IBAnalyst автоматически показывает правильную информацию о разрыве уборки для всех версий. IBAnalyst может определить разницу между реализациями серверов только по идентификатору ODS, например, InterBase 7.x имеет ODS 11.x, другие современные серверы имеют ODS 10.x. Если вы работаете только с базами InterBase 7.x (ODS 11), вы можете переключить соответствующую опцию в диалоге Options.

Когда интервал уборки вашей базы данных <> 0, IBAnalyst в основном помечает эту строку жёлтым цветом (предупреждая вас, что автоматическая уборка может запуститься в любой непредсказуемый момент). Обычно 60% всех приложений имеют проблемы с автоматической уборкой. Самый простой способ избежать этой проблемы - установить интервал уборки в 0, что приводит к отключению автоматической уборки. Но если какое-то приложение сделает много изменений, а затем откатит их, старейшая транзакция заморозится и не будет двигаться вперёд, пока не будет запущена уборка. Поскольку эффективное состояние транзакций рассчитывается от старейшей до следующей транзакции, это расстояние будет расти, и производительность упадёт. Чтобы предотвратить это, вы должны запускать уборку вручную (gfix -sweep). На этой картинке вы можете видеть поведение, когда интервал уборки равен 0 и была откачена большая транзакция:

Здесь значение разрыва уборки показывает, что некоторая большая (сделавшая много изменений) транзакция была откачена около 4,5 дней назад. Мы рекомендуем запускать уборку вручную каждый день.

Конечно, для упомянутых 60% приложений, возможно, лучше установить интервал уборки больше или меньше 20000, но это зависит от многих факторов (ежедневное количество транзакций - один из этих факторов, например) и может быть понято только экспериментальным путём. Итак, если вы установите интервал уборки в 0, вы можете быть уверены, что уборка не запустится автоматически в непредсказуемый момент.

Ту же картину вы можете увидеть для файла !rollback.txt.

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

Когда уборка не может выполнить свою работу

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

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

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

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

Поскольку InterBase 7.1/7.5 рассчитывает разрыв уборки иначе, чем предыдущие версии, другая ситуация, когда уборка не может выполнить свою работу, - это когда некоторое приложение имеет долго работающую транзакцию снимка:

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

Долго работающий снимок

Предыдущая картинка указывает на долго работающий снимок в InterBase 7.1/7.5. Если бы интервал уборки был установлен в 0, красных предупреждений не было бы, только жёлтые. Похожая картина укажет на долго работающую транзакцию снимка в других версиях InterBase, Firebird и Yaffil:

Как вы видите здесь, разрыв уборки рассчитывается по разнице между старейшим снимком и старейшей транзакцией (для ODS 10, версии до IB 7.x). Таким образом, предупреждения об уборке нет (кроме интервала уборки по умолчанию).

Но не только транзакции снимка влияют на состояние транзакций таким образом. Все версии InterBase, Firebird и Yaffil, кроме InterBase 7.1/7.5, имеют следующее поведение, которое мы назвали «артефакт read committed».

Снимки снова и когда ReadCommitted замораживает старейший снимок

Откройте !snapshot2.txt:

Обратите внимание, что старейшая транзакция больше, чем старейший снимок. И разрыв уборки имеет отрицательное значение. Это может произойти в двух случаях. Первый случай - когда есть несколько транзакций снимка, которые запускаются и фиксируются одна за другой. То есть эта картина может произойти со снимками так же, как и предыдущая. Второй случай происходит только на серверах, отличных от IB 7.1/7.5, с транзакциями ReadCommitted (или в комбинации ReadCommitted и Snapshot). Они могут заблокировать номер старейшего снимка так же, как это делают транзакции Snapshot. Текущее состояние транзакций можно эмулировать следующей последовательностью:

запустить транзакцию 1, snapshot или read_committed
запустить/зафиксировать несколько транзакций read_committed
запустить транзакцию 2, snapshot или read_committed
запустить/зафиксировать несколько транзакций read_committed
зафиксировать транзакцию 1

(конечно, мы говорим здесь о транзакциях read_committed write, а не read-only).

В этот момент текущая активная транзакция 2 (snapshot или read committed), запущенная после снимка 1 (пункт 3), будет удерживать номер снимка как старейший снимок (если вы работаете с IB 7.1/7.5, это может произойти только для параллельных транзакций snapshot. read_committed или read_committed+snapshot не дадут этого эффекта). Поскольку больших откатов не было, старейшая транзакция движется вперёд и становится больше, чем старейший снимок.

Теперь, если у вас есть долго работающая транзакция read committed, вы увидите картину, подобную этой. К сожалению, вы ничего не можете сделать здесь со своими приложениями (кроме добавления параметра «read» для транзакций только для чтения). И, конечно, уборка не запустится автоматически (если она установлена <> 0) в этом случае.

примечание: это поведение будет исправлено в Firebird 2.0

Абсолютное и относительное представление

По умолчанию IBAnalyst заполняет строки транзакций в соответствии с процентом от их абсолютного значения. То есть 100% - это от 0 до следующей транзакции. Иногда, когда база данных работает долгое время, вы можете увидеть информацию о транзакциях так:

Хотя транзакций много, разница между снимком, активной и старейшей выглядит очень маленькой (близко к 98%). Чтобы сделать ситуацию более понятной, откройте диалог Options, вкладку Transactions и установите флажок «Relative (from oldest) bars %» (вы не можете установить этот флажок, если используете старый стиль просмотра без графических полос). После нажатия кнопки OK вид транзакций изменится на

Ora vedi la differenza delle transazioni in vista relativa (100% è dalla transazione più vecchia (o snapshot) alla successiva, non da 0). È più facile comprendere la situazione attuale e visualizzare gli avvisi (se presenti).

Questa vista rimarrà attiva finché non la disattivi tramite la finestra di dialogo Opzioni. Puoi capire quale vista stai osservando dalla riga Transazione più vecchia o Snapshot più vecchio - nella vista relativa una di queste righe non è mai riempita di verde. Nella vista assoluta è sempre riempita (parzialmente, ovviamente).

Hai ancora domande? Contattaci a [email protected]