Обмежте ступінь паралелізму (DOP), доступний для будь-якого запиту

На Oracle Exadata (11gR2) ми маємо відносно непогану базу даних.

• cpu_count - 24
• паралельний_сервер_речовини - 2
• paral_threads_per_cpu дорівнює 2

Ми помітили, спостерігаючи в Oracle Enterprise Manager (OEM), що продуктивність була жахливою через запити, які виконуються послідовно. Щоб вирішити це, всі таблиці, матеріалізовані погляди та індекси були змінені, щоб скористатися паралелізмом. наприклад:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

Система була змінена для включення паралелізації:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Це призвело до кращої продуктивності, але ми іноді в OEM зауважували, що один запит прив'язує DOP 96 (весь доступний ресурс). Це призвело до того, що наступні запити були зменшені до DOP 1 (немає паралелізації). Результатом є низька продуктивність, поки не завершиться запит.

Щоб вирішити це, ми намагалися обмежити доступний DOP до будь-якого запиту за допомогою:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Це не мало ефекту. Ми часто спостерігаємо запити, які використовуватимуть більше обмеження (як правило, 48 або 96, але немає реального шаблону).

Як ми не можемо за допомогою будь-якого запиту приєднати весь доступний ресурс?

Набори паралельних серверів: PARALLEL_DEGREE_LIMIT обмежує ступінь паралелізму, але якщо ваш запит сортує або групує, кількість паралельних процесів може бути вдвічі більшим (два серверні набори для включення міжпроцесорного паралелізму). Це пояснює, чому ви побачите 48 паралельних процесів навіть з обмеженням 24. Це також відбувається, якщо ви використовуєте диспетчер ресурсів для обмеження DOP.

Паралельні підказки: PARALLEL_DEGREE_LIMIT стосується лише тверджень, які використовують автоматичний ступінь паралелізму. Будь-які заяви, які використовують жорстко закодований ступінь або навіть будь-який тип паралельного підказки на рівні об'єкта, ігнорують обмеження. Якщо у вас є ці підказки, це могло б пояснити, чому ви бачите 96 разів.

Калібрування IO: Можливо, автоматичний DOP не використовується, і таким чином ліміт не дотримується, оскільки IO не був відкалібрований . Цей запит підкаже, чи був калібрований IO:

select * from V$IO_CALIBRATION_STATUS;

Я бачив, що це викликало проблеми раніше, але моя поточна система не відкалібрована, і автоматичний DOP, здається, працює нормально. Ви можете сказати, чи справді це проблема, переглянувши розділ Примітки плану пояснення. Якщо ви бачите щось на кшталт, - automatic DOP: Computed Degree of Parallelism is 2ви добре, але бачити не хочете automatic DOP: skipped because of IO calibrate statistics are missing.

Збільшити PARALLEL_MAX_SERVERS: Замість того, щоб турбуватися про відсутність паралельних серверів, я рекомендую вам значно збільшити PARALLEL_MAX_SERVERS. Вам слід принаймні спробувати повернутися до значення за замовчуванням , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, між 240 і 960, залежно від налаштувань вашої пам'яті.

Ці великі цифри звучать смішно для багатьох DBA, але вони насправді мають багато сенсу з наступних причин:

• Паралельні сервери Oracle мають меншу вагу, ніж вважає більшість людей. (І навряд чи хтось коли-небудь перевіряє це, вони просто знаходять одну ситуацію, коли великий DOP викликає проблеми і припускають, що високий DOP завжди поганий.)
• Зазвичай запускати запит adhoc в інструменті GUI, який отримує лише перші 50 рядків, але все ще використовує десятки паралельних серверів. Ці запити НЕ споживають значних ресурсів, якщо тільки PARALLEL_MAX_SERVERS занадто низький. Тоді люди кричать на виконання абсолютно розумних запитів, що може призвести до деяких потворних ситуацій.
• Дуже великий DOP для одного запиту не завжди є поганим. Усі припускають, що якщо ви продовжуватимете збільшувати DOP, накладні витрати стануть занадто високими, а продуктивність значно знизиться. Але в багатьох системах я виявив, що навіть смішно високий DOP призведе до кращої продуктивності, хоча виразно зменшуються прибутки, і це може бути дуже несправедливо щодо інших сесій. Але не просто здогадуйтесь, тестуйте це; візьміть запит і запустіть його з усіма видами DOP, до 1000. Ви можете бути здивовані.
• Так, занадто багато паралелізму може бути поганим. Але що гірше для системи, провівши трохи більше, ніж оптимальна кількість сеансів, або змусити серійний запит і в основному знищити важливу роботу? Ви повинні контролювати систему перед введенням довільних обмежень.