Менеджер блокировок как источник конкуренции
В этом разделе мы объясним, почему при типичных рабочих нагрузках OLTP в традиционных системах менеджер блокировок является одним из первых конфликтных компонентов и препятствием на пути к масштабируемости.
Типичная рабочая нагрузка OLTP состоит из большого числа параллельных кратковременных транзакций, каждая из которых обращается к небольшой части (от одной до десяти записей) крупного набора данных. Каждая транзакция независимо выполняется в отдельном потоке управления. Для обеспечения целостности данных транзакции входят в большое число критических участков, координирующих доступ к совместно используемым ресурсам. Одним из совместно используемых ресурсов являются блокировки. Менеджер блокировок отвечает за поддержку изоляции параллельно выполняемых транзакций, обеспечивая транзакциям интерфейс для запросов (request), повышения уровня (upgrade) и освобождения (release) блокировок. Скрытым образом менеджер блокировок также обеспечивает получение транзакциями соответствующих блокировок намерений (intention lock) и выполняет действия для предотвращения и выявления синхронизационных тупиков (deadlock).
Опишем менеджер блокировок сервера хранения данных Shore-MT [14]. Хотя детали реализации менеджеров блокировок в коммерческих системах в основном неизвестны, мы полагаем, что они устроены аналогичным образом. Они могут различаться только реализацией защелок. В Shore-MT для этого используется допускающий вытеснения (preemption-resistant) вариант MCS-спинлоков с очередями. (MCS происходит от фамилий авторов алгоритма – Меллора-Крамми (Mellor-Crummey) и Скотта (Scott); см. их оригинальную статью. Прим. переводчика.) При использовании аппаратуры нашего испытательного стенда Sun Niagara II и при той загрузке процессора, которая применялась в нашем исследовании (<120%), реализации на основе спинлоков превосходят про производительности любое другое известное нам решение, включая блокирование (blocking) [12].
В Shore-MT каждая логическая блокировка представляется структурой данных, содержащей режим блокировки, указатель на начало списка запросов этой блокировки (удовлетворенных или ожидающих удовлетворения), а также защелку.
Когда транзакция пытается получить некоторую блокировку, менеджер блокировок сначала убеждается в том, что эта транзакция удерживает требуемые блокировки намерений более высокого уровня, автоматически запрашивая их в случае надобности. Если обнаруживается подходящая удерживаемая транзакцией блокировка более высокого уровня, то запрос немедленно удовлетворяется. Иначе менеджер блокировок зондирует хэш-таблицу, чтобы найти требуемую блокировку. После обнаружения блокировки она "защелкивается", и к списку запросов добавляется новый запрос. Если этот запрос несовместим с текущим режимом блокировки, транзакция блокируется. В конечном счете, защелка с блокировки снимается, и выполняется возврат из менеджера блокировок. В каждой транзакции поддерживается список всех ее запросов блокировок в порядке их получения. При завершении транзакции она по очереди освобождает блокировки, начиная с первой полученной блокировки. Для освобождения блокировки менеджер блокировок "защелкивает" ее и выбирает из списка запросов соответствующий запрос. Прежде чем снять защелку, менеджер просматривает список запросов для определения нового режима блокировки и нахождения всех отложенных запросов, которые теперь могут быть удовлетворены.
Объем работы, требуемой для удовлетворения запросов на получение или освобождения блокировок, восрастает по мере роста числа активных транзакций, поскольку удлиняются списки запросов блокировок. Для часто требуемых блокировок, таких как блокировки таблиц, в любой момент времени будет иметься много запросов. Для выявления синхронизационных тупиков требуются дополнительные обходы списков запросов. В совокупности удлиняющиеся списки запросов блокировок и возрастающее число потоков управления, выполняющих транзакции и конкурирующих за блокировки, приводят к пагубным для производительности результатам.
Рис. 3. Распределение времени внутри менеджера блокировок Shore-MT при выполнении тестового набора TPC-B и повышении уровня загрузки процессора.
Рис. 3 показывает, на что тратится время внутри менеджера блокировок Shore-MT при выполнении тестового набора TPC-B (коэффициент использования системы возрастает по оси абцисс). В общее время включается время, тратящееся на получение блокировок, на освобождение блокировок и на обслуживание конкуренции за выполнение этих операций. Когда система загружена слабо, более 85% времени работы менеджера блокировок тратится на выполнение полезной работы. Однако по мере возрастания загрузки начинает доминировать время, уходящее на обслуживание конкуренции. При стопроцентной загрузке процессора 85% времени работы менеджера блокировок тратится на обслуживание конкуренции (циклическое опрашивание (spinning) защелок).
Мы используем термин логические блокировки (logical locking), а не просто блокировки (locking), чтобы подчеркнуть их отличие от защелок (latching). Защелки используются для поддержки физической согласованности структур данных в основной памяти; логические блокировки позволяют поддерживать логическую согласованность ресурсов базы данных, таких как записи и таблицы.
