НАСТРОЙКА СОПЕРНИЧЕСТВА
ГЛАВА 23
----------------------------------------------------------------
НАСТРОЙКА СОПЕРНИЧЕСТВА
Эта глава представляет Третий шаг процесса настройки: настройку
соперничества. Соперничество возникает, когда несколько
процессов пытаются обратиться к одному и тому же ресурсу.
Соперничество заставляет процессы ожидать доступа к ресурсу.
ORACLE предоставляет вам методы управления соперничеством. В
этой главе вы узнаете, как:
* обнаруживать соперничество, которое может влиять на
производительность
* сокращать соперничество
Ресурсы ORACLE, обсуждаемые в этой главе, включают:
* сегменты отката
* процессы многоканального сервера
* замки буфера журнала повторения
Настройка соперничества 23-1
----------------
Сокращение соперничества за сегменты отката
В этой секции вы узнаете, как уменьшать соперничество за
сегменты отката. Обсуждаются следующие вопросы:
* как идентифицировать соперничество за сегменты отката
* как создавать сегменты отката
* как назначать сегменты отката конкретным транзакциям
Идентификация соперничества за сегменты отката
----------------------------------------------
Соперничество за сегменты отката выражается как соперничество за
буфера, содержащие блоки сегмента отката. Вы можете определить,
ухудшает ли это соперничество вашу производительность, опрашивая
динамическую таблицу производительности V$WAITSTAT.
Таблица V$WAITSTAT содержит статистики, отражающие соперничество
за блоки. По умолчанию эта таблица доступна лишь пользователю
SYS, а также другим пользователям, имеющим системную привилегию
SELECT ANY TABLE, таким как SYSTEM. Соперничество за блоки
различных классов отражается следующими статистиками:
system undo header Значение этой статистики представляет
число ожиданий буферов, содержащих блоки
заголовков сегмента отката SYSTEM.
system undo block Значение этой статистики представляет
число ожиданий буферов, содержащих
блоки, отличные от блоков заголовков
сегмента отката SYSTEM.
undo header Значение этой статистики представляет
число ожиданий буферов, содержащих блоки
заголовков сегментов отката, отличных от
сегмента отката SYSTEM.
undo block Значение этой статистики представляет
число ожиданий буферов, содержащих
блоки, отличные от блоков заголовков,
для сегментов отката, отличных от
сегмента отката SYSTEM.
23-2 Руководство администратора
Отслеживайте эти статистики за некоторый период времени, пока
выполняется ваше приложение, с помощью следующего запроса:
SELECT class, count
FROM v$waitstat
WHERE class IN ('system undo header', 'system undo block',
'undo header', 'undo block')
Результат этого запроса может выглядеть следующим образом:
CLASS COUNT
------------------ ----------
system undo header 2089
system undo block 633
undo header 1235
undo block 942
Сравните количество ожиданий для каждого класса блоков с общим
числом запросов данных за тот же период времени. Вы можете
отслеживать общее число запросов данных за период времени с
помощью следующего запроса:
SELECT SUM(value)
FROM v$sysstat
WHERE name IN ('db vlock gets', 'consistent gets')
Вывод этого запроса может выглядеть следующим образом:
SUM(VALUE)
----------
929530
Если число ожиданий для любого класса блоков превышает 1% от
общего числа запросов, вы должны рассмотреть необходимость
создания дополнительных сегментов отката, чтобы сократить
соперничество.
Создание сегментов отката
-------------------------
Чтобы уменьшить соперничество за буфера, содержащие блоки
сегментов отката, создайте больше сегментов отката. Табл.23-1
показывает некоторые общие рекомендации для выбора количества
создаваемых сегментов отката в зависимости от числа
одновременных транзакций в вашей базе данных. Эти рекомендации
подходят для большинства смесей транзакций.
Табл.23-1
Выбор числа сегментов отката
г==============================T=====================¬
¦ Количество ¦ Рекомендуемое число ¦
¦ одновременных транзакций (n) ¦ сегментов отката ¦
¦==============================+=====================¦
¦ n < 16 ¦ 4 ¦
¦------------------------------+---------------------¦
¦ 16 <= n < 32 ¦ 8 ¦
¦------------------------------+---------------------¦
¦ 32 <= n ¦ n/4, но не более 50 ¦
L==============================¦=====================-
Для создания сегментов отката используйте команду CREATE
ROLLBACK SEGMENT.
Настройка соперничества 23-3
----------------
Сокращение соперничества за процессы многоканального сервера
В этой секции вы узнаете, как уменьшать соперничество за
следующие процессы, используемые архитектурой многоканального
сервера ORACLE:
* диспетчерские процессы
* разделяемые серверные процессы
Сокращение соперничества за диспетчерские процессы
--------------------------------------------------
Эта секция обсуждает следующие вопросы:
* как идентифицировать соперничество за диспетчерские
процессы
* как добавлять диспетчерские процессы
Идентификация соперничества за диспетчерские процессы
Соперничество за диспетчерские процессы проявляется следующими
симптомами:
* высокими долями ожиданий существующих диспетчерских
процессов
* постоянным увеличением времени ожидания ответов в
очередях ответов существующих диспетчерских процессов
ИССЛЕДОВАНИЕ ДОЛИ ОЖИДАНИЙ ДИСПЕТЧЕРСКИХ ПРОЦЕССОВ. Статистики,
отражающие активность диспетчерских процессов, поддерживаются в
динамической таблице производительности V$DISPATCHER. По
умолчанию эта таблица доступна лишь пользователю SYS, а также
другим пользователям, имеющим системную привилегию SELECT ANY
TABLE, таким как SYSTEM. Активность диспетчерских процессов
отражается следующими статистиками:
IDLE Этот столбец показывает время простоя для
диспетчерского процесса в сотых долях секунды.
BUSY Этот столбец показывает время занятости для
диспетчерского процесса в сотых долях секунды.
Отслеживайте эти статистики за некоторый период времени, пока
выполняется ваше приложение, с помощью следующего запроса:
SELECT network "Protocol",
SUM(busy) / ( SUM(busy) + SUM(ilde) ) "Total Busy Rate"
FROM v$dispatcher
GROUP BY network
23-4 Руководство администратора
Этот запрос возвращает общую долю занятости для диспетчерских
процессов каждого сетевого протокола, или процент времени, в
течение которого диспетчерские процессы каждого протокола были
заняты. Результат этого запроса может выглядеть следующим
образом:
Protocol Total Busy Rate
-------- ---------------
decnet .004589828
tcp .029111042
Из этого результата можно вывести следующие наблюдения:
* диспетчерские процессы DECnet заняты почти 0.5% времени.
* диспетчерские процессы TCP заняты почти 3% времени.
Если диспетчерские процессы для некоторого протокола заняты
более 50% времени, то вы можете попытаться улучшить
производительность для пользователей, соединяющихся с ORACLE
через этот протокол, путем добавления диспетчерских процессов.
ИССЛЕДОВАНИЕ ВРЕМЕНИ ОЖИДАНИЯ ДЛЯ ОЧЕРЕДЕЙ ОТВЕТОВ ДИСПЕТЧЕРСКИХ
ПРОЦЕССОВ. Статистики, отражающие активность очередей ответов
диспетчерских процессов, поддерживаются в динамической таблице
производительности V$QUEUE. По умолчанию эта таблица доступна
лишь пользователю SYS, а также другим пользователям, имеющим
системную привилегию SELECT ANY TABLE, таким как SYSTEM.
Активность очередей ответов диспетчерских процессов отражается
следующими статистиками:
WAIT Этот столбец показывает общее время ожидания в
сотых долях секунды для всех ответов, когда-либо
находившихся в очереди ответов.
TOTALQ Этот столбец показывает общее число всех
ответов, когда-либо находившихся в очереди
ответов.
Отслеживайте эти статистики за некоторый период времени, пока
выполняется ваше приложение, с помощью следующего запроса:
SELECT network "Protocol",
DECODE(SUM(totalq), 0, 'No Responses',
SUM(wait)/SUM(totalq) || ' hundredths of seconds')
"Average Wait Time per Response"
FROM v$queue q, v$dispatcher d
WHERE q.type = 'DISPATCHER'
AND q.paddr = d.paddr
GROUP BY network
Настройка соперничества 23-5
Этот запрос возвращает среднее время в сотых долях секунды,
которое ответ ожидает в каждой очереди ответов, пока
диспетчерский процесс направит его процессу пользователя. Этот
запрос использует таблицу V$DISPATCHER, чтобы сгруппировать
строки таблицы V$QUEUE по сетевым протоколам. Кроме того, этот
запрос использует синтаксис DECODE, чтобы распознать те
протоколы, для которых не было ответов в очередях ответов.
Результат этого запроса может выглядеть следующим образом:
Protocol Average Wait Time per Response
-------- ------------------------------
decnet .1739130 hundredths of seconds
tcp No Responses
Из этого результата вы можете вывести, что среднее время
ожидания ответа в очереди ответов для диспетчерских процессов
DECnet составляет примерно 0.17 сотых долей секунды, и что для
диспетчерских процессов TCP очередь ответов была пуста.
Если среднее время ожидания ответа для некоторого сетевого
протокола продолжает устойчиво расти по мере выполнения вашего
приложения, то вы можете попытаться улучшить производительность
для пользователей, соединяющихся с ORACLE через этот протокол,
путем добавления диспетчерских процессов.
Добавление диспетчерских процессов
Вы можете добавить диспетчерские процессы во время работы
ORACLE, используя один из следующих способов:
* диалоговое окно SQL*DBA Configure Multi-Threaded
Dispatchers
* параметр MTS_DISPATCHERS команды ALTER SYSTEM
Для дополнительной информации о добавлении диспетчерских
процессов см. главу 4 "Управление процессами ORACLE" этого
руководства.
Общее число диспетчерских процессов по всем протоколам
ограничивается параметром инициализации MTS_MAX_DISPATCHERS.
Вам может потребоваться увеличить значение этого параметра,
прежде чем добавлять диспетчерские процессы. Умалчиваемое
значение этого параметра равно 5, а максимальное значение
зависит от вашей операционной системы.
23-6 Руководство администратора
Сокращение соперничества за разделяемые серверные процессы
----------------------------------------------------------
Эта секция обсуждает следующие вопросы:
* как идентифицировать соперничество за разделяемые
серверные процессы
* как увеличить максимальное число разделяемых
серверных процессов
Идентификация соперничества за разделяемые серверные процессы
Соперничество за разделяемые серверные процессы может
проявляться как постоянный рост времени ожидания для запросов в
очереди запросов. Статистики, отражающие активность очередей
запросов для разделяемых серверных процессов, поддерживаются в
динамической таблице производительности V$QUEUE. По умолчанию
эта таблица доступна лишь пользователю SYS, а также другим
пользователям, имеющим системную привилегию SELECT ANY TABLE,
таким как SYSTEM. Активность очередей запросов разделяемых
серверных процессов отражается следующими статистиками:
WAIT Этот столбец показывает общее время ожидания в
сотых долях секунды для всех запросов,
когда-либо находившихся в очереди запросов.
TOTALQ Этот столбец показывает общее число всех
запросов, когда-либо находившихся в очереди
запросов.
Отслеживайте эти статистики за некоторый период времени, пока
выполняется ваше приложение, с помощью следующего запроса:
SELECT DECODE( totalq, 0, 'No Requests',
wait/totalq || ' hundredths of seconds')
"Average Wait Time per Request"
FROM v$queue
WHERE type = 'COMMON'
Этот запрос возвращает общее время ожидания для всех запросов и
общее число запросов в очереди запросов. Результат этого
запроса может выглядеть следующим образом:
Average Wait Time per Request
-----------------------------
.090909 hundredths of seconds
Из этого результата вы можете вывести, что среднее время
ожидания, которое запрос проводит в очереди перед его
обработкой, составляет 0.09 сотых долей секунды.
Настройка соперничества 23-7
Вы можете также определить, сколько разделяемых серверных
процессов работают в данный момент, выдав следующий запрос:
SELECT COUNT(*) "Shared Server Processes"
FROM v$shared_servers
WHERE status != 'QUIT'
Результат этого запроса может выглядеть следующим образом:
Shared Server Processes
-----------------------
10
Добавление разделяемых серверных процессов
Поскольку ORACLE автоматически добавляет разделяемые серверные
процессы, если нагрузка на существующие разделяемые серверные
процессы резко увеличивается, то вы вряд ли сможете улучшить
производительность просто за счет явного добавления
дополнительных разделяемых серверных процессов. Однако, если
количество разделяемых серверных процессов достигло лимита,
установленного параметром инициализации MTS_MAX_SERVERS, а
среднее время ожидания в очереди запросов по-прежнему растет, вы
можете улучшить производительность путем увеличения значения
MTS_MAX_SERVERS. Умалчиваемое значение этого параметра равно
20, а максимальное значение зависит от вашей операционной
системы. После этого вы можете либо позволить ORACLE
автоматически добавлять разделяемые серверные процессы, либо
явно добавить разделяемые серверные процессы, используя один из
следующих способов:
* параметр инициализации MTS_SERVERS
* диалоговое окно SQL*DBA Configure Multi-Threaded
Servers
* параметр MTS_SERVERS команды ALTER SYSTEM
Для дополнительной информации о добавлении разделяемых серверных
процессов см. главу 4 "Управление процессами ORACLE" этого
руководства.
23-8 Руководство администратора
----------------
Сокращение соперничества за замки буфера журнала повторения
Соперничество за доступ к буферу журнала повторения редко
ухудшает производительность базы данных. Однако ORACLE
предоставляет вам методы отслеживания и сокращения любого
соперничества за замки буфера журнала повторения, которое может
возникать. Эта секция объясняет:
* как обнаруживать и уменьшать соперничество за память в
буфере журнала повторения
* как обнаруживать соперничество за замки
* как сокращать соперничество за замки
Память в буфере журнала повторения
----------------------------------
Когда процесс LGWR пишет записи повторения из буфера журнала
повторения в файл журнала, пользовательские процессы получают
возможность записывать в этот буфер новые записи повторения
поверх старых записей, которые были записаны на диск. LGWR
обычно пишет достаточно быстро, чтобы гарантировать, что в
буфере всегда есть место для новых записей, даже при интенсивных
обращениях к журналу повторения.
Статистика redo log space requests отражает число раз, когда
процессу пользователя приходилось ожидать освобождения памяти в
буфере журнала повторения. Эта статистика доступна через
динамическую таблицу производительности V$SYSSTAT. По умолчанию
эта таблица доступна лишь пользователю SYS, а также другим
пользователям, имеющим системную привилегию SELECT ANY TABLE,
таким как SYSTEM. Отслеживайте эту статистику за некоторый
период времени, пока выполняется ваше приложение, с помощью
следующего запроса:
SELECT name, value
FROM v$sysstat
WHERE name = 'redo log space requests'
Значение "redo log space requests" должно быть близко к 0. Если
это значение постоянно растет, это значит, что процессам
приходится ожидать памяти в буфере. В этом случае увеличьте
размер буфера журнала повторения. Размер буфера журнала
повторения определяется параметром инициализации LOG_BUFFER.
Значение этого параметра выражается в байтах. Попытайтесь
увеличивать размер буфера журнала повторения приращениями по 5%,
пока значение "redo log space requests" не станет близко к 0.
Настройка соперничества 23-9
Замки буфера журнала повторения
-------------------------------
Доступ к буферу журнала повторения регулируется замками. Этот
доступ контролируется двумя типами замков:
* замок распределения
* замок копирования
Замок распределения
Замок распределения (redo allocation latch) контролирует
распределение памяти для записей повторения в буфере журнала
повторения. Чтобы распределить память в этом буфере,
пользовательский процесс ORACLE должен получить замок
распределения. Так как существует лишь один замок
распределения, всего один пользовательский процесс может
распределять память в буфере в каждый момент времени.
Единственность замка распределения выражает последовательную
природу записей в буфере повторения.
Распределив память в буфере повторения, пользовательский процесс
может копировать запись повторения в буфер, продолжая удерживать
замок распределения. Такое копирование известно как
"копирование под замком распределения". Процесс может
копировать под замком распределения лишь в том случае, если
размер записи повторения меньше порогового значения. Закончив
копирование под замком повторения, процесс освобождает этот
замок.
Максимальный размер записи повторения, которая может быть
скопирована под замком повторения, определяется параметром
инициализации LOG_SMALL_ENTRY_MAX_SIZE. Значение этого
параметра выражается в байтах. Минимальное, максимальное и
умалчиваемое значения варьируются в зависимости от операционной
системы.
Замки копирования
Если запись повторения слишком велика, чтобы ее можно было
скопировать под замком распределения, то пользовательский
процесс должен получить замок копирования (redo copy latch),
прежде чем копировать запись в буфер журнала повторения.
Получив замок копирования, пользовательский процесс копирует
запись повторения в распределенную ей память в буфере, после
чего освобождает замок.
Если ваш компьютер имеет несколько процессоров, ваш буфер
журнала повторения может иметь несколько замков копирования.
Множественные замки копирования позволяют нескольким процессам
одновременно копировать свои записи в буфер журнала повторения.
Количество замков копирования определяется параметром
инициализации LOG_SIMULTANEOUS_COPIES. Умалчиваемое значение
параметра LOG_SIMULTANEOUS_COPIES определяется как значение
параметра инициализации CPU_COUNT. ORACLE автоматически
устанавливает значение CPU_COUNT равным количеству процессоров,
доступных вашей инстанции ORACLE. Не изменяйте значение
CPU_COUNT.
На однопроцессорных компьютерах не должно быть замков
копирования, так как в каждый момент активным может быть лишь
один процесс. В этом случае все записи повторения копируются
под замком распределения, независимо от их размеров. ORACLE
устанавливает значение CPU_COUNT в 0.
23-10 Руководство администратора
Исследование активности журнала повторения
------------------------------------------
Интенсивный доступ к буферу журнала повторения может привести к
соперничеству за замки буфера журнала повторения. Это
соперничество может ухудшить производительность. ORACLE
собирает статистики активности для всех замков и поддерживает их
в динамической таблице производительности V$LATCH. По умолчанию
эта таблица доступна лишь пользователю SYS, а также другим
пользователям, имеющим системную привилегию SELECT ANY TABLE,
таким как SYSTEM.
Каждая строка в таблице V$LATCH содержит статистику для
отдельного типа замка. Столбцы таблицы отражают активность
различных типов запросов на этот замок. Отличие между двумя
типами запросов состоит в том, согласен ли запрашивающий процесс
ожидать замка, если тот недоступен:
willing-to-wait Если замок, запрашиваемый этим типом запроса,
недоступен, то запрашивающий процесс ждет
короткое время, а затем повторяет запрос. Этот
цикл ожидания и повторения запроса продолжается,
пока замок не будет получен.
immediate Если замок, запрашиваемый этим типом запроса,
недоступен, то запрашивающий процесс не ждет, а
продолжает работу.
Следующие столбцы таблицы V$LATCH отражают запросы типа
willing-to-wait:
GETS Этот столбец показывает количество успешных
запросов на замок.
MISSES Этот столбец показывает число раз, когда
первоначальный запрос был безуспешен.
SLEEPS Этот столбец показывает число раз, которое
процесс был вынужден повторить запрос после
первоначальной попытки.
Например, рассмотрим случай, когда процесс делает запрос типа
willing-to-wait на замок, который недоступен. Процесс ждет и
повторяет запрос, однако замок вновь недоступен. Процесс снова
ждет и повторяет запрос в третий раз, после чего получает замок.
Эти действия отразятся на статистиках следующим образом:
* Значение GETS увеличится на 1, потому что один запрос на
замок (третий запрос) был успешным.
* Значение MISSES увеличится на 1, потому что
первоначальный запрос на замок привел к ожиданию.
* Значение SLEEPS увеличится на 2, потому что запрос был
вынужден ждать дважды, - после первого и после второго
запросов.
Настройка соперничества 23-11
Следующие столбцы таблицы V$LATCH отражают запросы типа
immediate:
IMMEDIATE_GETS Этот столбец показывает количество
успешных запросов на замок.
IMMEDIATE_MISSES Этот столбец показывает количество
безуспешных запросов на замок.
Отслеживайте статистики для замков распределения и замков
копирования за период времени с помощью следующего запроса:
SELECT name, gets, misses, immediate_gets, immediate_misses
FROM v$latch l, v$latchname ln
WHERE ln.name IN ('redo allocation', 'redo copy')
AND ln.latch# = l.latch#
Вывод этого запроса может иметь следующий вид:
NAME GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES
--------------- ------ ------ -------------- ----------------
redo allocation 252867 83 0 0
redo copy 0 0 22830 0
Из результатов этого запроса вычислите долю ожидания для каждого
типа запросов замков.
Соперничество за замки может влиять на производительность при
любом из следующих условий:
* если отношение MISSES к GETS превышает 1%
* если отношение IMMEDIATE_MISSES к сумме IMMEDIATE_GETS и
IMMEDIATE_MISSES превышает 1%
Если для замка имеет место любое из этих условий, попытайтесь
сократить соперничество за этот замок.
Приведенные пороговые значения для соперничества применимы для
большинства операционных систем; однако некоторые
многопроцессорные компьютеры способны выносить и более высокий
уровень соперничества без падения производительности.
23-12 Руководство администратора
Сокращение соперничества за замки
---------------------------------
Большая часть случаев соперничества за замки происходит, когда
процессы ORACLE одновременно пытаются получить один и тот же
замок. Такое соперничество редко случается на однопроцессорных
компьюрерах, где в каждый момент может быть активным лишь один
процесс.
Сокращение соперничества за замок распределения
Чтобы уменьшить соперничество за замок распределения, вы должны
минимизировать время, в течение которого один процесс удерживает
этот замок. Для этого следует сократить копирование под замком
распределения. Уменьшение значения параметра инициализации
LOG_SMALL_ENTRY_MAX_SIZE уменьшает количество и размеры записей
повторения, копируемых под замком распределения.
Сокращение соперничества за замки копирования
На многопроцессорных компьютерах, множественные замки
копирования позволяют нескольким процессам одновременно
копировать свои записи в буфер журнала повторения. Умалчиваемое
значение параметра LOG_SIMULTANEOUS_COPIES определяется как
значение параметра инициализации CPU_COUNT. ORACLE
автоматически устанавливает значение CPU_COUNT равным количеству
процессоров, доступных вашей инстанции ORACLE. На
однопроцессорных компьютерах ORACLE устанавливает значение
CPU_COUNT в 0.
Если вы обнаружите соперничество за замки копирования, добавьте
больше таких замков. Для этого увеличьте значение параметра
LOG_SIMULTANEOUS_COPIES. Для вашей инстанции ORACLE имеет смысл
иметь число замков, вдвое превышающее количество доступных
процессоров.
Другой способ сократить соперничество за замки копирования -
сократить время, в течение которого каждый процесс удерживает
такой замок. Этого можно добиться, заставив пользовательские
процессы ORACLE "предсоздавать" записи повторения, прежде чем
получать замок копирования.
Запись повторения может состоять из множества кусков. Обычно
каждый кусок записи повторения копируется из памяти процесса в
буфер журнала повторения индивидуально, пока процесс удерживает
замок копирования. Такое индивидуавьное копирование порций
записи требует много операций записи в память. Однако, если
запись повторения "предсоздается", пользовательский процесс
собирает все эти куски вместе, прежде чем запрашивать замок.
После этого вся запись может быть скопирована в буфер журнала
повторения за одну операцию записи в память.
Пользовательские процессы "предсоздают" все записи, размер
которых не превышают порогового значения. Этот пороговый размер
определяется параметром инициализации
LOG_ENTRY_PREBUILD_THRESHOLD. Значение этого параметра
выражается в байтах. Умалчиваемое значение равно 0. Это
значение означает, что по умолчанию никакие записи не
предсоздаются.
Чтобы заставить ваши пользовательские процессы предсоздавать
большую часть из записей повторения, увеличьте значение
параметра LOG_ENTRY_PREBUILD_THRESHOLD.
Настройка соперничества 23-13
----------------
Назначение всем процессам ORACLE равных приоритетов
В работу ORACLE вовлечено множество процессов. Все эти процессы
обращаются к ресурсам разделяемой памяти в области SGA.
Обеспечьте, чтобы все процессы ORACLE, как переднего плана, так
и фоновые, имели одинаковый приоритет обработки в операционной
системе. Когда вы инсталлируете ORACLE, все фоновые процессы
получают умалчиваемый приоритет в вашей операционной системе.
Вы не должны изменять приоритеты фоновых процессов. Вы должны
также обеспечить, чтобы все пользовательские процессы имели
умалчиваемый приоритет операционной системы.
Назначение процессам ORACLE разных приоритетов может усилить
эффекты соперничества. Ваша операционная система может не
давать процессорного времени низкоприоритетному процессу, если
высокоприоритетный процесс также претендует на процессор. Если
высокоприоритетный процесс требует доступа к ресурсу памяти,
удерживаемому низкоприоритетным процессом, то этот
высокоприоритетный процесс может бесконечно долго ждать, пока
низкоприоритетный процесс получит управление и освободит ресурс.
23-14 Руководство администратора