IBAnalyst: що ви можете побачити у поданні Summary View

Дмитро Кузьменко, останнє оновлення 31-03-2014

Анотація

Цей документ присвячено поясненню інформації на сторінці «Підсумковий перегляд» (Summary view) в IBAnalyst, а також тому, як інтерпретувати цю інформацію для власної статистики бази даних. Також ми додали кілька прикладів статистики до інсталяційного пакета, щоб полегшити вам вивчення всіх тонкощів статистики InterBase. Вони знаходяться в каталозі Examples інсталяції IBAnalyst.

Якщо ви не знаєте, що таке Oldest transaction, Oldest snapshot, active та Next, будь ласка, спочатку прочитайте статтю Крейга Стунца «Understanding Transactions Lifetime»:

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

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

Якщо ви прочитали статтю Understanding Transaction Lifetimes, можливо, у вас все ще є питання щодо чисел OIT/OST/OAT. Ось короткий опис:


Номер	Утримується, …	Рухається вперед, …
Oldest transaction	коли транзакція з цим номером була відкочена, і в ній було багато змін даних, або коли з’єднання з клієнтом було втрачено	коли автоматичне або ручне очищення (sweep) успішно завершується.
Oldest Snapshot	коли знімок (або read committed write до IB 7.1) активний протягом тривалого часу (він запам’ятовував найстаріший активний знімок як свій локальний OST)	коли починається нова транзакція, якщо транзакція, що утримує OST, завершилася
Oldest Active	коли транзакція з цим номером активна протягом тривалого часу	коли починається нова транзакція, якщо транзакція, що утримує OAT, завершилася
Next	ніколи	коли починається нова транзакція

примітка: Oldest transaction тут те саме, що й Oldest Interesting Transaction (OIT), згадане в багатьох інших статтях.

Точна статистика зі стандартними налаштуваннями

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

IBAnalyst повідомляє не лише дату створення бази даних, але також розпізнає поточну дату/час на сервері, якщо статистику було отримано через Services API, або дату/час файлу, якщо це завантажений файл статистики.

Тому ми рекомендуємо не змінювати файли статистики, оскільки в цьому випадку IBAnalyst неправильно розрахує середню кількість транзакцій на день. Рядок Transactions per day тут показує близько ~12500 транзакцій на день, і що база даних «живе» з моменту її створення або відновлення протягом 8 днів.

Oldest, Oldest snapshot, Oldest active та Next транзакції тут у ідеальному стані, бажаємо, щоб ваша статистика завжди виглядала саме так.

Багато активних транзакцій

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

Тут рядок Active transactions позначено червоним, оскільки існує велика різниця між Oldest active та Next транзакцією. Це означає, що деяка транзакція на момент зняття статистики все ще активна, і після її початку вже розпочалося 55 000 транзакцій (вони можуть бути в будь-якому стані - активні, зафіксовані, відкочені). Оскільки середня кількість транзакцій на день становить ~12500, IBAnalyst показує вам попередження, що деяка транзакція все ще живе протягом 4.4 днів. Це може статися, коли:

деяка програма все ще працює і має принаймні одну відкриту транзакцію - можливо, користувач тримає програму запущеною протягом тривалого часу
програма працює довго і втрачає дескриптори транзакцій - тобто ваш код (або компоненти/бібліотеки, які ви використовуєте) динамічно запускає транзакції і за певних обставин «забуває» завершити їх за допомогою rollback або commit.
ваша програма не використовує явні транзакції (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.

Sweep - це процес обслуговування всередині InterBase. Sweep проходить по всіх записах у базі даних і намагається очистити всі застарілі версії, потім намагається підняти номер Oldest transaction. У новоствореній базі даних інтервал sweep за замовчуванням становить 20000. Коли різниця між транзакціями (див. таблицю нижче) стає більшою за інтервал sweep, sweep запускається автоматично. Таким чином, ви можете спостерігати періодичне погіршення продуктивності вашої бази даних. Наприклад, ваші програми працюють нормально в понеділок і вівторок, але в середу користувачі повідомляють про проблеми з продуктивністю протягом кількох годин, а потім продуктивність знову стає нормальною.

Якщо ви бачите подібну поведінку - це автоматичне очищення (sweep).


Версія сервера	Коли запускається sweep
InterBase 7.x	(Oldest Active - Oldest) > Інтервал sweep
InterBase 4.x, 5.x, 6.x, Firebird до 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > Інтервал sweep

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

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

Коли ваша база даних має інтервал sweep <> 0, IBAnalyst зазвичай позначає цей рядок жовтим (попереджаючи, що автоматичне очищення може запуститися в будь-який непередбачуваний момент). Загалом 60% усіх програм мають проблеми з автоматичним очищенням. Найпростіший спосіб уникнути цієї проблеми - встановити інтервал sweep на 0, що призводить до вимкнення автоматичного очищення. Але якщо якась програма зробить багато змін, а потім відкотить їх, Oldest transaction заморозиться і не рухатиметься вгору, доки не буде запущено sweep. Оскільки ефективний стан транзакцій розраховується від Oldest до Next транзакції, ця відстань зростатиме, і продуктивність впаде. Щоб запобігти цьому, ви повинні запускати sweep вручну (gfix -sweep). На цьому зображенні ви можете бачити поведінку, коли інтервал sweep дорівнює 0 і була відкочена велика транзакція:

Тут значення sweep gap показує, що деяка велика (з багатьма змінами) транзакція була відкочена приблизно 4.5 дні тому. Ми рекомендуємо запускати sweep вручну щодня.

Звичайно, для тих згаданих 60% програм, можливо, краще встановити інтервал sweep більшим або меншим за 20000, але це залежить від багатьох факторів (щоденна кількість транзакцій є одним із цих факторів, наприклад) і може бути зрозуміло лише експериментальним шляхом. Отже, якщо ви встановите інтервал sweep на 0, ви можете бути впевнені, що sweep не запуститься автоматично в непередбачуваний момент.

Те саме зображення ви можете побачити для файлу !rollback.txt.

примітка: Якщо sweep запускається автоматично, для великої бази даних або бази даних з великою кількістю сміттєвих версій записів Snapshot, Active та Next транзакції можуть рухатися вперед, поки працює sweep, і sweep може запуститися знову при найближчому старті транзакції.

Коли sweep не може виконати свою роботу

Існує багато випадків, коли sweep не може підняти Oldest transaction вище. Звичайно, sweep спочатку намагається виконати свою роботу, тобто перевірити всі записи в базі даних і зібрати непотрібні версії записів. Але він буде запускатися знову і знову без успіху, якщо

під час запуску sweep виникла якась проблема: сервер було зупинено під час sweep, або сталася помилка під час очищення сміттєвих версій записів. Крім того, ви можете побачити цю картину, коли:

статистику було знято під час роботи sweep
sweep працює і намагається зібрати сміття для таблиці, яка постійно оновлюється. Це може тривати, доки оновлення не завершаться.
sweep зупиняється на блокуваннях сторінок, оскільки багато користувачів працюють з даними.

Загалом, sweep не має шансів завершитися під час високого навантаження на базу даних. Зазвичай, коли продуктивність деградує до неможливості продовжувати нормальну роботу, DBA перезапускає сервер, і sweep запускається при першому підключенні користувача. Оскільки пройде деякий час, поки інші користувачі підключаться, sweep встигне завершити свою роботу.

Оскільки InterBase 7.1/7.5 розраховує Sweep gap інакше, ніж попередні версії, інша ситуація, коли sweep не може виконати свою роботу, - це коли деякий застосунок має довготривалу snapshot-транзакцію:

Тут є два попередження - одне (жовте) про довготривалий snapshot, а інше (червоне) про Sweep interval та Sweep gap.

Довготривалий snapshot

Попереднє зображення вказує на довготривалий snapshot в InterBase 7.1/7.5. Якщо Sweep interval було встановлено на 0, червоних попереджень не було б, лише жовті. Подібне зображення вказуватиме на довготривалу snapshot-транзакцію в інших версіях InterBase, Firebird та Yaffil:

Як бачите тут, Sweep gap розраховується за різницею між Oldest Snapshot та Oldest transaction (для ODS 10, версії до IB7.x). Тож попередження про sweep немає (окрім стандартного Sweep interval).

Але не лише snapshot-транзакції впливають на стан транзакцій таким чином. Усі версії InterBase, Firebird та Yaffil, окрім InterBase 7.1/7.5, мають таку поведінку, яку ми назвали “артефакт read committed”.

Snapshots знову і коли ReadCommitted заморожує Oldest Snapshot

Відкрийте !snapshot2.txt. :

Зверніть увагу, що Oldest transaction більший за Oldest snapshot. І Sweep gap має від’ємне значення. Це може статися у двох випадках. Перший випадок - коли деякі snapshot-транзакції запускаються та завершуються одна за одною. Тобто це зображення може статися зі snapshot-транзакціями так само, як і попереднє. Наступний випадок відбувається лише на серверах, відмінних від IB 7.1/7.5, з ReadCommitted-транзакціями (або в комбінації ReadCommitted та Snapshot-транзакцій). Вони можуть блокувати номер Oldest Snapshot так само, як це роблять Snapshot-транзакції. Поточний стан транзакцій можна відтворити такою послідовністю:

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

(звісно, ми говоримо тут про read_committed write-транзакції, не read-only).

У цей момент активна транзакція 2 (snapshot або read committed), запущена після snapshot 1 (пункт 3), утримуватиме номер snapshot як Oldest Snapshot (якщо ви працюєте з IB 7.1/7.5, це може статися лише для одночасних snapshot-транзакцій. read_committed або read_committed+snapshot не дадуть такого ефекту). Оскільки не було великих відкатів, Oldest transaction рухається вперед і стає більшим за Oldest Snapshot.

Тепер, якщо у вас є довготривала read committed-транзакція, ви побачите таку картину. На жаль, ви нічого не можете зробити тут зі своїми застосунками (окрім додавання параметра “read” для read-only-транзакцій). І, звісно, sweep не запуститься автоматично (якщо він встановлений <> 0) у цьому випадку.

примітка: ця поведінка буде виправлена у Firebird 2.0

Абсолютний та відносний вигляд

За замовчуванням IBAnalyst заповнює рядки транзакцій відповідно до відсотка від їхнього абсолютного значення. Тобто 100% - це від 0 до Next transaction. Іноді, коли база даних працює тривалий час, ви можете бачити інформацію про транзакції так:

Хоча транзакцій багато, різниця між snapshot, active та oldest виглядає дуже малою (близько 98%). Щоб зробити ситуацію зрозумілішою, відкрийте діалог Options, вкладку Transactions і позначте опцію “Relative (from oldest) bars %” (ви не можете встановити цей прапорець, якщо використовуєте старий вигляд без графічних стовпців). Після натискання кнопки OK вигляд транзакцій зміниться на:

Тепер ви бачите різницю транзакцій у відносному вигляді (100% - це від Oldest (або snapshot) транзакції до Next, а не від 0). Легше зрозуміти поточну ситуацію та переглянути попередження (якщо вони є).

Цей вигляд збережеться, доки ви не знімете позначку в діалозі Options. Ви можете зрозуміти, який вигляд бачите, за рядком Oldest Transaction або Oldest snapshot - у відносному вигляді один із цих рядків ніколи не заповнюється зеленим кольором. В абсолютному вигляді він завжди заповнений (частково, звісно).

Все ще є питання? Запитайте нас на [email protected]