Ограничьте степень параллелизма (DOP), доступную для любого запроса

В Oracle Exadata (11gR2) мы имеем относительно мудрую базу данных.

  • cpu_count - 24
  • parallel_server_instances - 2
  • parallel_threads_per_cpu is 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, но не имеют реального шаблона).

Как мы предотвращаем какой-либо один запрос из-за зависания всего доступного ресурса?

11 голосов | спросил grenade 29 22011vEurope/Moscow11bEurope/MoscowTue, 29 Nov 2011 19:23:41 +0400 2011, 19:23:41

1 ответ


8

Параллельные серверные наборы: 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 в зависимости от настроек вашей памяти.

Эти высокие цифры кажутся смешными для многих администраторов баз данных, но они действительно имеют большой смысл по следующим причинам:

  • Oracle параллельные серверы имеют меньший вес, чем большинство людей. (И вряд ли кто-либо когда-либо проверяет это, они просто находят одну ситуацию, когда большие причины DOP проблема и предположить, что высокий DOP всегда плох.)
  • Обычно запускается adhoc-запрос в GUI-инструменте, который извлекает только первые 50 строк, но все равно использует десятки параллельных серверов. Эти запросы НЕ потребляют значительных ресурсов, если PARALLEL_MAX_SERVERS слишком низок. Затем люди закричали за бег вполне разумные запросы, которые могут привести к некоторым уродливым ситуациям.
  • Очень большой DOP для одного запроса не всегда плох. Каждый предполагает, что если вы продолжите увеличивать DOP, накладные расходы будут слишком высокими, и производительность значительно снизится. Но на многих системах я обнаружил, что даже смехотворно высокая DOP приведет к повышению производительности, хотя есть определенно уменьшающаяся отдача, и это может быть очень несправедливо по отношению к другим сеансам. Но не просто догадайтесь, проверьте это; взять запрос и запустить его со всеми видами DOP, до 1000. Вы можете быть удивлены.
  • Да, слишком много параллелизма может быть плохим. Но что хуже для системы, имея чуть больше оптимального количества сеансов или принуждения запрос к серийному запуску и, в основном, убийство важной работы? Вы должны контролировать систему, прежде чем вводить произвольные ограничения.
ответил Jon Heller 30 32011vEurope/Moscow11bEurope/MoscowWed, 30 Nov 2011 12:58:19 +0400 2011, 12:58:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132