Шрифт:
| none | null | Shared Read | Protected Read | Shared Write | Protected Write | Exclusive | |
| попе | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| null | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| SR | 1 | 1 | 1 | 1 | 1 | 1 | 0 |
| PR | 1 | 1 | 1 | 1 | 0 | 0 | 0 |
| SW | 1 | 1 | 1 | 0 | 1 | 0 | 0 |
| PW | 1 | 1 | 1 | 0 | 0 | 0 | 0 |
| EX | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
Когда соединение желает заблокировать объект, оно подает запрос на блокировку, который определяет блокируемый объект и желаемый уровень блокировки.
Обычно если объект, который какое-то соединение желает заблокировать, уже блокирован другим соединением, то выстраивается очередь доступа, причем соединения, которые желают получить уровень блокировок ниже, чем тот, что уже наложен на объект, продвигаются вперед очереди. То есть если объект был заблокирован с уровнем Protected Read, то следующие соединения, которые запрашивают на этот объект блокировку Protected Read или ниже, передвинутся в начало очереди (точнее, пройдут без очереди), а соединения, которые запрашивают блокировки уровнем выше (например, Shared Write), будут "топтаться" в очереди. Если загрузка базы данных очень велика, такое поведение может привести к тому, что соединения, которые требуют высоких уровней блокировок, могут ждать неопределенно долго, потому что новые читающие соединения (которые запрашивают низкие уровни блокировки) будут постоянно прибывать и "лезть без очереди".
Показания к изменению параметра
Если ваши операции по записи данных имеют более низкий приоритет по сравнению с операциями чтения, включение сортировки блокировки улучшит производительность чтения, особенно в течение длинных читающих транзакций. Но необходимо помнить, что даже только читающие транзакции изменяют базу данных.
– по крайней мере они записывают информацию о состоянии своих транзакций.
LOCK HASH SLOTS
Параметр lock hash slots был удален из конфигурационного файла InteiBaseGx. no крайней мере в SuperSener под NT Однако исходный KOI д 1я того, чтобы прочитать и интерпретировать этот параметр, все еще существует.
Параметры в ibconfig
LOCK_HASH_SLOTS 101
Действие
Этот параметр определяет ширину хэш-таблицы, которая используется для поиска блокировок. По умолчанию значение этого параметра 101. Число должно быть простым, чтобы хэш-алгоритм производил хорошее распределение.
Он может быть в диапазоне от 101 до 2048
Объяснение
Представьте себе, что хэш-таблица - это одномерный массив с цепочками, которые "свисают" из каждой ячейки этого массива. Менеджер блокировок кэширует имя объекта и затем вычисляет остаток от целочисленного деления этой величины на число хэш-слотов в массиве, таким образом он определяет ячейку, на которую надо "подвесить" блокировку данного объекта.
Когда менеджер блокировок ищет определенную блокировку, он определяет ячейку кэш-массива аналогичным образом, а затем спускается вниз по цепочке, подвешенной к данной ячейке, и ищет объект с правильным именем. Если находится более одного объекта с этим именем, он проходит по цепочке "однофамильцев", которая подвешивается к первому объекту, который соответствует искомому имени
Что получается в итоге. Чем длиннее будут цепочки, подвешенные к каждому слоту, тем медленнее будет работать менеджер блокировок. В среднем каждая цепочка должна иметь не более 10 ячеек.
Показания к изменению параметра
Первым признаком для изменения этого параметра должна быть общая низкая производительность системы с большим количеством пользователей и страниц в кеше Запустите инструмент iblockpr из директории %INTERBASE%\Bin для печати блокировок Если средняя длина более 10, увеличьте число этого параметра Для начала умножьте среднюю длину цепочек на число слотов и поделите на 9, а затем возьмите простое целое число, большее полученного значения (но меньшее 2048). Если вы производите подобную настройку на SuperServer, то необходимо также увеличить размер таблицы блокировок.
DEADLOCK TIMEOUT
Параметры в ibconfig
DEADLOCK_TIMEOUT 10
Действие
Этот параметр определяет число секунд, в течение которых менеджер блокировок будет ожидать разрешения обнаруженного конфликта, а по истечении этого срока конфликт будет рассмотрен как потенциальный deadlock (взаимная блокировка)
Объяснение
Применение этого параметра интенсивно тестировали около двух лет назад на системах, которые были такими медленными, что сегодня они не могли бы работать даже в посудомоечной машине. На данное время 10 с являются оптимальным интервалом Рели установить меньший интервал, то проверки на deadlock перегрузят компьютеры, а если более длинный, то пользователи ворвутся в вашу лабораторию и разгромят компьютеры.
Показания к изменению параметра
Deadlock очень редко встречаются в InterBase Обычная ошибка deadlock, ошибка обновления (Update Conflict) не является тем deadlock, который обнаруживается менеджером блокировок. Представляет интерес запрограммировать действительный случай возникновения deadlock (когда А изменяет строк) 1, В изменяет строку 2, затем А пытается изменить строку 2, а В - строку 1, причем все это без подтверждения изменений - без commit), а затем поэкспериментировать с различными интервалами DEADLOCK_TIMEOUT, чтобы увидеть, как изменяется производительность.