Защелки. (Latching)

Защелки используются для защиты структур памяти от записи другим процессом. По смыслу это тоже самое что и локировка, но защелка имеет более ограничивающий характер – eсли процесс залокировал от записи ресурс памяти с помощью защелки, то другие процессы не могут даже читать этот ресурс. Защелка также более простая структура, за счет отсутствия поддержки очередей ожидания. Здесь также используются простые и атомарные операции работы с CPU (tests and sets, load and clear, compare and swap). Благодаря этому, использование защелки требует мало ресурсов и поэтому эффективнее других механизмов защиты памяти.

Защелка применяется в основном для защиты памяти SGA, там где требуется скорость, но по причине эксклюзивного доступа, защелка не должна быть использована продолжительно. (Эксклюзивный доступ как пример источника проблем хорошо иллюстрирует проблемы с парсингом shared pool’a, где защелка держится на весь период парсинга)

Если процесс хочет получить доступ к ресурсам защищаемым защелкой, то используются два режим ожидания: willing to wait или immediate. В первом случае, процесс предполагает что ресурс скоро освободится, поэтому он решает ждать. В этом случае, для ожидания, процесс делает холостую нагрузку на процессор. Для операционной системы, однако, эта нагрузка вполне реальная загрузка процессора которая влияет на работу всей системы. Зачем же тогда для ожидания использовать процессор таким влияющим на работу другим способом? Почему бы просто не освободить процессор и сделать его доступным для других процессов?

Дело в том, что бы освободить процессор необходимо переключение контекста процессора. Переключение контекста – дорогостоящая операция: освобождение значений регистров, их сохранение, поиск следующего процесса и заполнение значений регистров, поиск и изменение структур ядра, которые защищены локировками оп. системы. Поэтому в большинстве случаев, простое ожидание на CPU, выгоднее чем переключение контекста (кончно, в случае когда выполняется условие кратковременности использования защелки).

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

Oracle On Windows

Основная проблема в различии между реализацией oracle под windows и linux. На Linux и других Unix операционных системах, каждому процессу выделяется процесс OS. В windows же это сделано через multithreading, т.е. есть один процесс и под ним создаются треды – подпроцессы.

В 32 битных приложениях, ограничения адресации в 4GB (3GB под пользовательские процессы) накладываются на уровне процесса. В Linux/Unix это еще не так страшно, так как может быть создано много oracle процессов. Однако в Windows только один oracle процесс, и соответственно эти ограничения накладываются на весь oracle.

Существуют способы как добраться до памяти сверх 3GB, через PAE или AWE, однако этот способ снижает производительность (из-за конвертации адресов). К тому же, некоторые критичные структуры памяти не могут использовать верхнюю память вообще. В результате, низкая производительность есть следствие ограничений кеша и структур памяти, что позволяет не больше 2000 одновременный пользователей (dedicated mode).

C выходом oracle 10g2 64 bit под windows и windows 2003 64 bit, эти ограничения преодолены. Кроме того у multithreading архитектуры есть свои преимущества (нет переключений контекста), которые в некоторых ситуациях позволяют oracle под winodws работать даже быстрее чем под linux. Это делает использование OS Windows приемлемым для работы с Oracle.

Однако, необходимо также учитывать надежность работы OS на протяжении длительного времени. Это предмет дальнейших наблюдений и исследований.