Цим невеликим постом хотілося б розвіяти одне непорозуміння, пов'язане з аналізом баз даних AWR, що працюють на Oracle Exadata. Майже 10 років я постійно стикаюся з питанням: який внесок Exadata Software у продуктивність? Або з використанням новостворених слів: наскільки «екзадатна» робота тієї чи іншої бази даних?
Часто на це правильне питання, як на мене, дається неправильна відповідь з посиланням на статистику AWR. У ній представлений метод системних очікувань, що трактує час відгуку як суму часу процесорів (DB CPU) і часу очікувань різних класів.
З появою Exadata у статистиці AWR з'явилися специфічні системні очікування, пов'язані із роботою Exadata Software. Як правило назви таких очікувань починаються зі слова "cell" (осередком називається Exadata Storage сервер), з них найчастіше зустрічаються очікування з назвами "cell smart table scan", "cell multiblock physical read" і "cell single block physical read".
У більшості випадків частка таких Exadata-очікувань загалом відгуку мала, і тому вони навіть не потрапляють у секцію Top10 Foreground Events by Total Wait Time (у цьому випадку їх потрібно шукати в розділі Foreground Wait Events). Ми насилу виявили у наших замовників приклад добового AWR, в якому Exadata-очікування потрапили в секцію Top10 і в сумі склали близько 5%:
Event
Чекає
Total Wait Time (sec)
Avg Wait
% DB time
Wait Class
DB CPU
115.2K
70.4
SQL*Net more data from dblink
670,196
5471.5
8.16ms
3.3
мережу
cell single block physical read
5,661,452
3827.6
676.07us
2.3
User I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Інше
cell multiblock physical read
759,885
2252
2.96ms
1.4
User I/O
direct path read
374,368
1811.3
4.84ms
1.1
User I/O
SQL*Net message from dblink
7,983
1725
216.08ms
1.1
мережу
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
User I/O
direct path read temp
520,211
808.4
1.55ms
0.5
User I/O
enq: TM - contention
652
795.8
1220.55ms
0.5
додаток
З подібної AWR статистики часто роблять такі висновки:
1. Внесок магії Exadata у продуктивність бази даних не високий – не перевищує 5 %, а база даних «екзадатиться» погано.
2. Якщо таку базу перенести з Exadata на класичну архітектуру «сервер + масив», продуктивність зміниться не сильно. Тому що навіть якщо цей масив виявиться втричі повільнішим за систему зберігання Exadata (що навряд чи можливо для сучасних All Flash масивів), то помноживши 5% на три ми отримаємо збільшення частки очікувань введення-виведення до 15% — така база даних напевно переживе!
Обидва ці висновки неточні, навіть вони спотворюють розуміння ідеї, закладеної в Exadata Software. Exadata не просто забезпечує швидке введення-виведення, вона працює принципово інакше в порівнянні з класичною архітектурою «сервер + масив». Якщо робота бази даних справді «екзадатіться», то на систему зберігання переноситься SQL-логіка. Storage сервери завдяки ряду спеціальних механізмів (насамперед Exadata Storage Indexes, але не тільки) самі знаходять потрібні дані та пересилають DB північ. Вони роблять це досить ефективно, тому частка характерних Exadata-очікувань загалом відгуку мала.
Як зміниться ця частка поза Exadata? Як це позначиться на продуктивності бази даних загалом? Найкраще на ці питання відповість тестування. Наприклад, очікування “cell smart table scan” поза Exadata може перетворитися на такий важкий Table Full Scan, що введення-виведення займе весь час відгуку та продуктивність погіршиться драматично. Саме тому неправильно при аналізі AWR вважати сумарний відсоток очікувань Exadata вкладом її магії у продуктивність і тим більше використовувати цей відсоток для прогнозування продуктивності поза Exadata. Щоб зрозуміти наскільки «екзадатна» робота бази потрібно вивчати статистики AWR секції “Instance Activity Stats” (там багато статистик з назвами, що говорять) і порівнювати їх між собою.
А щоб зрозуміти, як почуватиметься база даних поза Exadata, найкраще зробити з бекапа клон бази на цільовій архітектурі та проаналізувати продуктивність цього клону під навантаженням. Така можливість у власників Exadata зазвичай є.
Автор: Олексій Струченко, керівник напряму БД «Інфосистеми Джет»
Джерело: habr.com