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

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

Анотація

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

Правильний час, правильне місце

Це звучить дивно, але просто зняття статистики через gstat або Services API недостатньо. Статистику потрібно знімати в правильний момент, щоб показати, як застосунки впливають на дані та транзакції в базі даних. Найгірший час для зняття статистики:

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

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

Як зловити момент, коли з базою даних щось не так?

Так, ваші застосунки можуть бути спроєктовані настільки ідеально, що вони завжди працюватимуть з транзакціями та даними правильно, не створюючи розривів очищення, великої кількості активних транзакцій, довготривалих знімків тощо. Зазвичай цього не відбувається. Принаймні тому, що деякі розробники тестують свої застосунки з 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-транзакції тривають не довше, ніж потрібно, а транзакції залишаються активними мінімальний проміжок часу, ви можете налаштувати інтервал очищення або вимкнути його, а потім лише піклуватися про те, скільки оновлень роблять застосунки та які таблиці потребують менше оновлень або уваги.

Що це означає, можете запитати ви? Наведемо приклад деякої системи, де проблеми з продуктивністю виникали щоранку протягом 20-30 хвилин. Це було дуже суттєво для “ранкових” застосунків і не могло тривати довше.

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

Щоденна робота була розділена на секції - аналітики працюють вранці, потім дані вставляються та редагуються звичайними операторами, а наприкінці дня запускалися спеціальні процедури для збору даних, які використовуватимуться для аналітики наступного дня (принаймні).

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

І рішення цієї проблеми виявилося простим - запустити gfix -sweep наприкінці дня.

Очищення читає всі таблиці в базі даних і намагається зібрати всі версії сміття для зафіксованих і відкочених транзакцій. Після очищення база даних стає чистою майже як після відновлення.

І “ранкова проблема” зникла.

Отже, потрібно розглядати статистику з урахуванням багатьох інших факторів:

1. скільки одночасних користувачів (у середньому) працює протягом дня

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

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

Коли DBA нічого не може вдіяти

На жаль, такі ситуації трапляються. І знову приклад:

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

На жаль, застосунки були написані з використанням BDE і взагалі без використання транзакцій; тобто вся обробка транзакцій була автоматичною і використовувалася самим BDE. Це спричинило те, що деякі транзакції залишалися активними протягом тривалого часу, і сміття (версії записів) накопичувалося, поки DBA не перезапускав сервер. Після перезапуску запускалося автоматичне очищення, і сміття було зібране (усунене).

Усе це було спричинено застосунками, оскільки вони тестувалися лише з 2-3 одночасними користувачами, а коли їх стало ~15, застосунки почали створювати дуже високе навантаження.

Слід зазначити, що в цій конфігурації 70% користувачів лише читали дані, а інші 30% вставляли та оновлювали деякі (!) дані.

У цій ситуації єдине, що може покращити продуктивність, - це повністю переробити застосунки.

Залишилися питання? Напишіть нам на [email protected]