FBMonLogger
FBMonLogger тепер є частиною HQbird Standard!
FBMonLogger - це інструмент для аналізу виводу таблиць моніторингу у Firebird та виявлення проблем із повільними SQL-запитами, неправильно спроєктованими транзакціями (довготривалі транзакції, транзакції з неправильним рівнем ізоляції тощо) та ідентифікації проблемних застосунків.
FBMonLogger може підключитися до бази даних Firebird із проблемами продуктивності та визначити причину повільності: чи це якесь користувацьке підключення, повільний SQL-запит чи довготривала транзакція?
FBMonLogger підтримує Firebird 2.1, 2.5 та 3.0 - для старіших версій Firebird або InterBase використовуйте FBScanner.
FBMonLogger може показати вам:
- Топ підключень із найбільшою кількістю операцій введення-виведення, неіндексованих та індексованих читань
- Топ SQL-запитів із найбільшою кількістю операцій введення-виведення, неіндексованих та індексованих читань
- Проблемні транзакції: довготривалі транзакції, транзакції з помилковим рівнем ізоляції, транзакції читання/запису та пов’язану інформацію: коли вони почалися, які застосунки їх запустили, з якої IP-адреси тощо
- Підключення та запити з найінтенсивнішими діями зі збирання сміття
- Співвідношення читання/запису, співвідношення INSERT/UPDATE/DELETE тощо.
Після підключення до бази даних, де ви хочете знайти проблеми з продуктивністю, слід зробити кілька знімків таблиць моніторингу - натисніть «Get Snapshot», щоб зробити знімок.
Агрегована статистика продуктивності для підключень користувачів
На першому екрані ми бачимо агреговану статистику для підключень до бази даних та можемо визначити підключення з найбільшими проблемами:
Послідовні читання / Індексовані читання
«Послідовні читання / Індексовані читання» показує загальне співвідношення між послідовними (неіндексованими) читаннями та індексованими читаннями у застосунку. Зазвичай кількість неіндексованих читань має бути низькою, тому великий відсоток послідовних читань є ознакою того, що багато SQL-запитів мають NATURAL плани виконання, і вони можуть бути причиною повільного часу відповіді.
Натискання на запис у «TOP підключень: послідовні/індексовані читання» перенесе вас на вкладку «Підключення», де ви можете побачити більше деталей про підключення, а потім перейти на вкладку «Транзакції» або «Запити», де ви побачите транзакції та запити, пов’язані з вибраним підключенням (якщо позначка «Link to selected attachment» увімкнена, інакше будуть показані всі транзакції/запити для всіх підключень).
Деталі запису
«Деталі запису» дає вам огляд операцій запису: співвідношення між INSERT/UPDATE/DELETE серед усіх підключень до бази даних. У таблиці топових записувачів ви можете побачити підключення з найбільшою кількістю операцій запису. Це корисно для виявлення застосунків або програмних модулів, які виконують надмірну кількість оновлень або видалень (які є найнебезпечнішими операціями з точки зору збирання сміття).
Деталі збирання сміття
Що означають операції збирання сміття?
- Purge - рушій видаляє зворотні версії, у базі даних залишається лише основна версія.
- Expunge - видалені і основна версія, і всі зворотні версії.
- Backout - видаляється лише основна версія (через відкат).
Зазвичай ми можемо пов’язати purge з операцією UPDATE, Expunge з DELETE, а Backout з відкатом INSERT або UPDATE. Багато backout може означати, що є проблема з управлінням транзакціями у застосунку.
Використання пам’яті
Графік «Використання пам’яті» показує загальний обсяг пам’яті, який використовують усі активні підключення зараз, та пік виділеної пам’яті для них у минулому.
Список топових підключень за використанням пам’яті показує найбільших споживачів пам’яті серед ваших підключень. Це корисно для виявлення застосунків або програмних модулів із надмірним використанням пам’яті.
Агрегована статистика продуктивності для запитів
На другій вкладці ви можете знайти агреговану статистику продуктивності для запитів. Ця статистика краще відображає поточну ситуацію в базі даних - оскільки таблиці моніторингу збирають інформацію з початку життя кожного об’єкта, запити, які ви бачите тут, - це ті, що виконувалися в момент знімка.
Послідовні читання / Індексовані читання
У цьому списку ми бачимо топові запити, які виконують багато послідовних читань із бази даних. Зазвичай такі запити потребують налаштування SQL - або через налаштування індексів, або через перепроєктування SQL-запиту.
Щоб налаштувати запит, перевірте його план виконання: зазвичай можна покращити швидкість запиту, усунувши NATURAL у планах за допомогою нових індексів або перепроєктування запиту. Натисніть на запит у цьому списку, щоб відкрити вкладку «Запити», де ви можете знайти більше деталей про вибраний запит і перейти до пов’язаної транзакції або підключення.
Читання сторінок/запис сторінок
Ці графіки та список показують коротку інформацію про топові запити, які виконують багато читань - це означає, що вони споживають значний обсяг введення-виведення і можуть впливати на продуктивність інших запитів. SQL-запити з піковими значеннями слід ретельно перевірити на оптимальну продуктивність.
Деталі запису для запитів
На цьому графіку ви можете побачити, які операції запису виконували SQL-запити в момент знімка таблиць моніторингу, та визначити UPDATE і DELETE, які внесли багато змін у базу даних.
Деталі збирання сміття для запитів
На цьому графіку ми бачимо, скільки операцій збирання сміття було виконано запитами, що працювали в момент знімка.
Використання пам’яті для запитів
На відміну від агрегованої статистики використання пам’яті для підключень, використання пам’яті запитами може показати нам список конкретних запитів, які споживають багато пам’яті в поточний момент.
Підключення
Третя вкладка - «Підключення». Ви можете відкрити цю вкладку безпосередньо, натиснувши на один із записів у «Агрегованій статистиці продуктивності».
«Підключення» показує список користувачів, підключених до бази даних Firebird, з багатьма корисними деталями: USER та ROLE підключення, час початку та ID підключення, чи ввімкнено збирання сміття для підключення, назва віддаленого процесу, який встановив підключення, а також кілька накопичених лічильників продуктивності для підключення: кількість послідовних читань [виконаних підключенням з моменту його початку], кількість індексованих читань, кількість вставок, оновлень і видалень, а також backout, purge та expunge записів.
За замовчуванням деякі стовпці підключень вимкнені, щоб показувати лише найважливішу інформацію.
Звичайно, щоразу, коли ви натискаєте на підключення, ви можете перейти до транзакцій, що виконуються всередині нього, а потім до запитів. У лівому верхньому куті вкладок «Транзакції» та «Запити» є прапорець, який керує цією поведінкою - коли він позначений, будуть показані лише транзакції та запити, позначені ID вибраного підключення.
Транзакції
Вкладка «Транзакції» показує активні транзакції в момент знімка. Якщо прапорець «Link to selected attachment» увімкнено, будуть показані лише транзакції для вибраного підключення, інакше показуються всі транзакції.
Однією з найважливіших характеристик є час життя транзакцій: оскільки Firebird розроблений для роботи з короткими транзакціями запису, важливо тримати їх якомога коротшими. FBMonLogger виділяє транзакції з режимами ізоляції та налаштуваннями читання-запису, які утримують найстарішу активну транзакцію і тому спричиняють накопичення надмірних версій записів, які не очищаються. Якщо ви бачите таку транзакцію і вона почалася деякий час тому, це означає, що вона може бути відповідальною за надмірні версії записів.
Відсортуйте за стовпцем «started at» і шукайте старі транзакції, позначені червоним: усі транзакції запису та знімки лише для читання утримують найстарішу активну транзакцію та спричиняють утримання надмірних версій записів. Визначте, де почалися ці транзакції (клацніть правою кнопкою миші та виберіть «View parent attachment»), і виправте свій код, щоб фіксувати цю транзакцію раніше.
Інструкції
Вкладка «Statements» показує запити, активні на момент знімка: якщо потрібно перехопити всі запити, слід використовувати FBPerfMon або FBScanner (усі ці інструменти є частиною IBSurgeon Optimization Pack).
Якщо увімкнено опцію «Link to selected attachment», відображатимуться лише запити для конкретного підключення, інакше в списку будуть усі активні запити.
Деякі запити не мають пов’язаного ідентифікатора транзакції (=0): ці запити підготовлені, але не виконані.




