Квант для стандартной диспетчерской таблицы

Оценить
(0 голоса)

Квант для стандартной диспетчерской таблицы Solaris падает с 200 мсек для приоритета 0 до 20 мсек для приоритета 59. В результате эти кванты обычно приводят к хорошему функционированию процесса в среде рабочих станций, но к несколько худшей оптимизации в среде сервера БД.

Сравните с рисунком 15.7, на котором показаны последние 10 элементов диспетчерской таблицы Starfire.

Рисунок 15.7. Последние 10 элементов диспетчерской таблицы Starfire

По контрасту кванты для таблицы Starfire начинаются с 400 мсек для приоритета 0 и плавно сокращаются до 340 мсек для приоритета 59.

Рассмотрим случай, когда квант времени процесса истекает в то время, когда процесс все еще продолжает удерживать критическую защелку БД (определенный базой данных mutex - взаимоисключающий флаг, или взаимоисключающая блокировка, резервирующая доступ к критическому разделу кода или структуры). Если процесс контекстно-переключаемый (то есть, "освобождает ЦП", удерживая при этом защелку), остальные процессы, которым необходима эта защелка, будут "вхолостую прокручиваться" всякий раз, когда система планирует их выполнение. Здесь под термином вхолостую прокручиваться автор подразумевает порождение циклов ЦП, выполняющих непроизводительные команды в цикле. Идея заключается в том, чтобы остаться на данном ЦП в надежде, что процесс с защелкой будет запущен на другом ЦП и вскоре освободит эту защелку. Прокрутка вхолостую может показаться глупой затеей, однако в многопроцессорной среде обычно более эффективно нанести небольшой ущерб ресурсам ЦП и вновь возобновить попытку вместо того, чтобы переходить в режим бездействия, освобождать ЦП и платить за издержки, вызванные переключением контекста.

Рациональнее будет предоставить возможность процессу, удерживающему защелку, выполнить свою работу и освободить защелку прежде, чем он будет вытеснен, что позволит освободить как защелку, так и ЦП, полезный для других процессов.

Тесты, выполненные группой Database Engineering, показали, что для некоторых приложений оптимальное значение кванта составляет приблизительно 300 мсек для процессов с приоритетом 59, когда модифицированная диспетчерская таблица используется совместно с измененными приоритетами процессов.

Проблему можно намного облегчить, если базы данных будут использовать один из примитивов управления вытеснением, доступных, начиная с Solaris 2.6. Управление вытеснением позволяет процессу оповещать операционную систему о том, что он удерживает критический ресурс и не может быть вытеснен. Так происходит защита от непродуктивного сброса, описываемого ранее. В СУБД Oracle реализовано управление вытеснением, начиная с Oracle 8i (Solaris 2.6 или последующие версии также необходимы). Управление вытеснением рассматривается в разделе "Управление вытеснением" главы 3.

Подробнее в этой категории: « Управление рабочими нагрузками
Управление рабочими нагрузками
Домены
Наборы процессоров
Ключевое отличие между доменами и процессорными наборами
Управление ресурсами

Добавить комментарий


Защитный код
Обновить