AWR: насколько «экзадатится» работа базы данных?
Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом 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 | Waits | 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 | Network |
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 | Other |
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 | Network |
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 | Application |
Из подобной 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, как правило, есть.
Автор: Алексей Струченко, руководитель направления БД «Инфосистемы Джет»
