session lock что это

Блокировки сессий в веб-проектах — выбираем эффективное оружие

В последнее время, в связи с бурным ростом и усложнением фронт-эндов, аяксами и т.п. — все чаще проявляется проблема блокировки сессий во время эксплуатации сайтов на PHP. PHP по умолчанию создает для сессии файл и процесс эксклюзивно его блокирует. Остальные процессы, пытающиеся открыть сессию (аяксы, табы в браузере) — выстраиваются в очередь. Не всегда логика приложения, особенно если она сложная, позволяет эффективно ограничить время блокировки конкурирующих за сессию процессов.

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

К сожалению, разработчики/сисадмины не всегда могут сразу понять, что дело в блокировке сессии — и ищут проблемы в других частях проекта, теряя время.

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

Я сознательно не усложняю статью и не рассказываю о теории и практике написания кастомных обработчиков сессии PHP — это отдельная интересная тема. Сосредоточимся на конкретной задаче и попытаемся ее решить.

Диагностика

Рассмотрим, что происходит внутри операционной системы, если одновременно попытаться открыть в браузере (можно в разных вкладках) один засыпающий файл и несколько просто стартующих сессию скриптов:

Страницы будут дожидаться освобождения сессии (30 секунд) и займет это ой ой ой времени, при этом будут забиты слоты веб-сервера. Примерно то же самое случается, когда аякс запускает в сессии веб-клиента тяжелую задачу и остальные аяксы и другие элементы интерфейса зависают в ожидании (либо когда открывается несколько вкладок под одной авторизацией).

Процессы веб-сервера, в данном случае httpd, но то же самое происходит и с php-fpm — пытаются эксклюзивно заблокировать файл сессии, что видим с помощью lsof:

Обращаем внимание на 4 колонку. Число — это номер дескриптора файла в процесе, а дальше — тип блокировки. «uW» — веб-сервер заблокировал файл эксклюзивно для записи. Остальные — ждут и нервно курят в сторонке:-) Как только процесс 7079 закончит свою работу, блокировку «uW» возьмет другой процесс. В это время, понятно, выстраивается очередь и веб-интерфейс заметно тормозит. Еще веселее если несколько процессов заблокируют сессию на единицы секунды — интерфейс вообще станет колом.

Посмотрим теперь с другой стороны, чем занимаются процессы:

Во второй колонке видим, что все, кроме одного, заняты в функции «flock_lock_file_wait». А чем?

Правильно, в системном вызове c запросом эксклюзивной блокировки.

Полезный скрипт

Чтобы постоянно отслеживать на веб-серверах появление такого «паровозика», забивающего PHP-воркеры, я написал простой скриптик на AWK:

Отображает длину «паровозика» и процесс — создающий затор.

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

Если же очень лень ( неужели я один такой 🙂 ), можно раскомментировать «kill» и отстреливать процессы веб-сервера, создающие коллапс и наслаждаться реакцией клиентов и менеджеров технической поддержки 🙂 Но правильнее конечно, купить 2-3 баночки пива и сходить в гости к разработчикам — с собранной подобным образом через cron в файлик статистикой и договориться о рефакторинге 🙂

Всем удачи и успехов!

По просьбе преподавателей русского языка и программистов с филологическим образованием заменил слово «локировка» на «блокировка».

Поддерживая большие проекты нашей компании, нам приходится постоянно создавать инструменты и методики для быстрого анализа проблем с производительностью и их решения. GNU/Linux содержат большой набор полезных инструментов, но, к сожалению, далеко не все ими умеют пользоваться. Надеюсь подобные практические статьи будут полезны не только системным администраторам, но и веб-разработчикам.

Источник

Session lock

There are numerous utilities to lock the screen of a session. But it is important to note that the utility to use is highly dependent on the environment you are in, either the virtual console, or a specific display server (Xorg or Wayland).

Contents

By environment

This article or section is a candidate for merging with List of applications#Screen lockers.

Virtual console

You can use vlock or physlock to lock a virtual console.

There are many ways to lock the session under Xorg, so this section is likely to be incomplete. Some methods however include:

Most desktop environments come with some way to lock the session.

Wayland

Triggering the lock

You can lock a session using different methods:

The last point (triggering a lock from an event) is the trickiest, because you can do it in one of two ways:

Shell triggers

To execute a command after terminal inactivity, you can use the TMOUT environment variable.

You can combine it with a trap on the ALARM signal to execute the lock. Without a trap, it will just terminate the shell.

You might want to detect if you are in a graphical environment, otherwise your GUI terminals might start disappearing without you understanding why.

Xorg triggers

xss-lock

xss-lock is triggered by one of two things:

The advantage of this is that you can control a lock issued manually, by inactivity, and by a suspend command at the same place.

To execute an action on one of those events:

systemd events

To configure DPMS signaling timeout:

DPMS signaling can also be configured in /etc/X11/xorg.conf.d/ in the Monitor section.

Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen. For example (from xss-lock(1) ):

xautolock

Wayland triggers

swayidle

swayidle listens for idle activity from the Wayland compositor, as well as systemd events, and executes commands accordingly. See Sway#Idle.

D-Bus notification

Inactivity

Note that this is for a global system (so this is not ideal for a multi user environment).

Note also that «this requires that user sessions correctly report the idle status to the system».

Units

Before suspend or hibernate

Lid closing

You can use the lock action using the related ACPI Event.

Источник

Документация разработчика Hibernate – Глава V. Блокировки

Перевод статьи актуален для версии Hibernate 4.2.19.Final

Содержание
&nbsp5.1. Оптимистичные блокировки
&nbsp&nbsp&nbsp5.1.1 Выделенный номер версии
&nbsp&nbsp&nbsp5.1.2. Timestamp
&nbsp5.2. Пессимистичные блокировки

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

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

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

5.1. Оптимистичные блокировки

Вы можете хранить версионированные данные, когда ваше приложение использует долгоживущие транзакции или диалоги, покрывающие несколько БД-транзакций. Таким образом, если одна и та же сущность будет модифицироваться двумя диалогами, последний диалог, коммитивший изменения, будет оповещен о конфликте, и не перезапишет результаты другого диалога. Этот подход гарантирует некоторую степень изоляции, но при этом хорошо масштабируется, и довольно неплохо себя показывает в ситуациях Read-Often Write-Sometimes
Hibernate предоставляет два различных механизма для хранения версионной информации – выделенный номер версии, или временную метку (timestamp).

Номер версии
Временная метка

Свойство версии или временной метки не может быть null для отсоединенных (detached) объектов. Hibernate распознает любой экземпляр с версией ( или временной меткой) равной null как transient, в независимости от других стратегий unsaved-value* которые вы указываете. Объявление null-ового свойства версии или временной метки – легкий способ избежать проблемы с транзитивным повторным соединением(transitive reattachment) в Hibernate, являющееся особенно полезным в случаях, где вы используете присоединенные (assigned) идентификаторы или композитные ключи.

* unsaved-value – стратегия определения операции UPDATE или INSERT для синхронизации с БД, зависящая от значения свойства, проецирующегося с помощью id, version, или timestamp (прим. перев.)

5.1.1. Выделенный номер версии

Механизм номера версии для оптимистичных блокировок предоставляется аннотацией Version.

Пример 5.1. Аннотация Version

Здесь свойство версии маппится на колонку OPTLOCK, а менеджер сущностей (entity manager) использует ее для выявления конфликтующих обновлений, и предотвращения потери обновлений, которые были бы перезаписаны стратегией last-commit-wins

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

Вашему приложению запрещено изменять номер версии, проставленный Hibernate. Чтобы искусственно увеличить номер версии, см. описание свойств LockModeType.OPTIMISTIC_FORCE_INCREMENT или LockModeType.PESSIMISTIC_FORCE_INCREMENT в документации по Hibernate Entity Manager. Если номер версии сгенерирован базой данных, например триггером, используйте аннотацию org.hibernate.annotations.Generated(GenerationTime.ALWAYS).

Пример 5.2. Объявление свойства версии в hbm.xml

5.1.2. Timestamp

Временные метки (timestamps) — менее надежный способ оптимистичных блокировок чем номера версий, который также может быть использован приложениями для других целей. Временные метки используются автоматически, если вы используете аннотацию Version на свойстве типа Date или Calendar.

Пример 5.3. Использование временных меток для оптимистичных блокировок

Hibernate может извлечь значение временной метки из базы данных или JVM, прочитав значение аннотации org.hibernate.annotations.Source. Значение может быть либо org.hibernate.annotations.SourceType.DB, либо org.hibernate.annotations.SourceType.VM. Поведение по-умолчанию – это использование БД, также используемое, если вы не укажете аннотацию.
Временная метка также может быть сгенерирована базой данных вместо Hibernate, если вы используете аннотацию org.hibernate.annotations.Generated(GenerationTime.ALWAYS).

Пример 5.4. Элемент timestamp в hbm.xml

5.2. Пессимистичные блокировки

Класс LockMode определяет различные уровни блокировок, которые может захватывать Hibernate.

Источник

База данных Oracle Database для начинающих: основы базы данных

База данных Oracle использует блокировки (lock) для обеспечения того, что изменение указанного фрагмента данных в каждый конкретный момент времени может совершать максимум одна транзакция. По существу блокировки — это механизмы, которые разрешают параллельную обработку; без применения какой-либо модели блокировки для предотвращения, например, одновременных обновлений одной и той же строки, многопользовательский доступ к базе данных был бы невозможным.

Ниже описаны некоторые важные свойства блокировки Oracle.

В следующих нескольких разделах данной статьи вы узнаете больше о методах и типах блокировки, используемой механизмом управления параллелизмом Oracle.

Методы блокировок Oracle

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

Гранулированностью (granularity) в контексте блокировок называется размер единицы данных, заблокированный механизмом блокировки. Oracle использует гранулированность уровня строки для блокировки объектов, которая представляет собой наиболее мелкий уровень гранулированности (наиболее крупный уровень — блокировка таблицы). Некоторые базы данных, включая Microsoft SQL Server, предлагают только блокировку уровня страницы, а не строки. Страница — это нечто похожее на блок данных Oracle, и она может хранить группу строк, поэтому блокировка уровня страницы означает, что на время обновления несколько строк будут заблокированы в дополнение к тем, что подлежат обновлению; если другим пользователям понадобятся заблокированные строки, которые не участвуют в обновлении, им придется ждать, пока блокировка страницы не будет снята. Например, если размер страницы составляет 8 Кбайт, а средняя длина строки — 100 байт, то в страницу уместится 80 строк. Если одна из них будет обновляться, то блокировка уровня страницы также распространится на остальные 79 строк. Блокировка на уровне выше строки ограничивает параллельный доступ к данным.

На заметку!

Типы блокировок Oracle

Блокировки, как было показано, предотвращают деструктивное взаимодействие между транзакциями, обеспечивая последовательный доступ к ресурсам. Этими ресурсами могут быть как объекты базы данных, наподобие таблиц, так и другие разделяемые структуры базы данных, находящиеся в памяти. Блокировки Oracle могут быть приблизительно разделены на следующие типы, в соответствии с блокируемыми объектами:блокировки DML, блокировки DDL, защелки, внутренние блокировки и распределенные блокировки. Все эти типы блокировок описаны ниже.

Блокировки DML

Блокировки DML — это блокировки, устанавливаемые Oracle для защиты данных в таблицах и индексах. Всякий раз, когда оператор DML собирается модифицировать данные в таблице, Oracle автоматически устанавливает блокировку уровня строки на модифицируемые строки таблицы. (Это исключает, к примеру, возможность того,что группа продавцов сможет продать “последний” билет более чем одному клиенту.) Блокировки DML уровня строки гарантируют, что читатели данных не станут ожидать записи данных и наоборот. Писатели должны будут подождать только в том случае, если они хотят обновить некоторые строки, которые в данный момент модифицируются другими транзакциями.

Любой режим блокировки Oracle допускает запросы к таблице. Запрос никогда не заблокирует обновление, удаление или вставку, и наоборот. Монопольная блокировка (exclusive lock) разрешает только запросы к таблице, но предотвращает любую другую активность пользователей, подобную обновлению или удалению данных. Монопольная блокировка строки, с другой стороны, допускает параллельный доступ к таблице для обновления, удаления и вставки данных, но предотвращает блокировку всей таблицы любым пользователем в монопольном режиме. Существуют и другие режимы блокировки, но для наших целей достаточно будет сосредоточиться на двух базовых режимах блокировки Oracle.

Блокировки таблицы могут варьироваться от сильно ограничивающих до ограничивающих в минимальной степени. Oracle устанавливает монопольную блокировку строки таблицы; это указывает на то, что транзакция, удерживающая блокировку, выполнила обновление одной или более строк таблицы. Другим транзакциям разрешено параллельно выбирать, вставлять, обновлять, удалять или блокировать строки в той же таблице. Однако другие транзакции не могут установить монопольную блокировку всей таблицы для выполнения собственных операций чтения и записи. Все операторы INSERT, UPDATE и DELETE устанавливают неявные монопольные блокировки строк.

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

Подведем краткий итог наиболее частого использования транзакциями Oracle средств блокировки Oracle.

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

Блокировки DDL

Как уже было показано, Oracle автоматически устанавливает блокировки DML на таблицы, которые находятся в процессе модификации их строк со стороны транзакции. В дополнение такая транзакция одновременно удерживает DDL-блокировку уровня таблицы, что предотвращает изменение или удаление этой таблицы другими DML-транзакциями, которые еще не завершены.

Блокировки DDL можно также поместить на таблицы при выполнении простых операций DDL вне какой-либо сопровождающей транзакции DML.

Установка ожидания блокировок DML для блокировок DDL

По умолчанию запрос блокировки DDL не ожидает блокировки DML. То есть запрос блокировки DDL автоматически получает отказ, если не может немедленно установить блокировку DML на таблице. Однако с помощью параметра инициализации ddl_lock_timeout можно задать период времени, в течение которого оператор DDL будет ожидать блокировки DML.

Явное блокирование таблицы

Каждый раз, когда вы добавляете столбец к таблице, база данных должна установить монопольную DML-блокировку на этой таблице. Можно указать, что команда DDL должна ожидать определенный период времени перед отказом, когда не удается установить блокировку DML. Оператор LOCK TABLE позволяет специфицировать максимальный период времени, который оператор DDL может ожидать возможности захвата DML-блокировки таблицы. Применяйте это средство при добавлении столбца, часто обновляемого пользователями.

Ниже приведен синтаксис оператора LOCK TABLE :

В операторе LOCK TABLE значения NOWAIT и WAIT параметр MODE означают следующее.

Защелки, внутренние и распределенные блокировки

Защелки (latch) — это внутренние механизмы, которые защищают разделяемые структуры данных в SGA. Например, вхождения словаря данных доступны в буфере для многих целей, и защелки контролируют процессы доступа к этим структурам памяти. Структуры данных, которые перечисляют блоки, находящиеся в данный момент в памяти, также часто читаются во время работы экземпляра Oracle, и серверные и фоновые процессы, которые нуждаются в изменении или чтении критичных структур данных вроде этих, должны устанавливать на них очень кратковременные блокировки (именуемые защелками). Реализация защелок, включая спецификацию длительности ожидания их, обычно специфична для операционной системы.

Блокировки словаря данных используются Oracle при каждой модификации объектов словаря. Распределенные защелки представляют собой специализированные механизмы блокировки, используемые в распределенной системе базы данных или среде Oracle Real Application Clusters (RAC). Внутренние блокировки используются Oracle для защиты доступа к таким структурам, как файлы данных, табличные пространства и сегменты отката.

Явное блокирование в Oracle

Oracle автоматически применяет необходимые блокировки к таблицам и другим объектам на основе транзакций, закодированных в приложениях. Механизм блокирования Oracle работает автоматически, гарантируя согласованность чтения на уровне оператора и параллелизм. В большинстве случаев стандартного скрытого механизма блокировок Oracle вполне достаточно, но иногда бывают ситуации, когда разработчику приложения лучше вручную блокировать таблицы. Иногда, когда транзакции нужно видеть согласованные данные между несколькими соединенными таблицами, разработчик приложения может прибегнуть к явному блокированию. Вдобавок, когда не нужно,чтобы значения данных изменялись на протяжении длительной транзакции, иногда разработчику приложения бывает необходимо установить явные блокировки.

Блокирующие замки

Далее приведен простой пример блокирующего сеанса: пользователь Nick Alapati издает следующий оператор DML, но не фиксирует его:

Пользователь Nina Alapati, между тем, выдает аналогичный оператор, который при выполнении зависает:

DML-оператор второго пользователя зависнет из-за того, что первый пользователь еще не зафиксировал свою транзакцию, и потому удерживает блокировку уровня строки, которую пытается изменить второй пользователь. Когда первый пользователь откатывает или фиксирует свою транзакцию, второй автоматически продолжает работу и завершает.

С помощью представления V$SESSION можно узнать, какие сеансы блокируют другие сеансы. Вот простой запрос, использующий это представление, который показывает блокирующий замок, вызванный предыдущими двумя операторами SQL:

Взаимные блокировки (взаимоблокировки)

Взаимные блокировки (deadlock) возникают в любой СУБД, когда два сеанса блокируют друг друга, ожидая от противоположного сеанса освобождения некоторого ресурса. Это ситуация из произведения “Уловка 22” (ссылка на роман Джозефа Хеллера под названием “Catch-22”), потому что данная патовая ситуация не может быть разрешена ни одним из сеансов в одностороннем порядке. В таких условиях Oracle прерывает один из сеансов и откатывает его операцию. Oracle быстро распознает возникновение взаимоблокировки между двумя сеансами и прерывает тот сеанс, который последним запросил блокировку. Это освобождает блокировку, снятия которой ждет другой сеанс. Фактически в случае возникновения взаимоблокировки ничего не нужно делать, хотя в каталоге дампа появится сообщения о наличии взаимоблокировки в базе данных.

Когда Oracle сталкивается с взаимоблокировкой между транзакциями, он записывает в файл трассировки идентификаторы участвующих сеансов, операторы SQL, выданные в транзакциях, а также имя конкретного объекта и строки, на которых удерживаются блокировки в каждом сеансе, принимающем участие в блокировке. Далее Oracle информирует, что взаимоблокировка не вызвана ошибкой Oracle, а вызвана ошибками в дизайне приложения или стала результатом определенных операторов SQL. Проектировщики приложений должны писать в своем коде обработчики исключений,чтобы откатывать прерванные транзакции и перезапускать их. Избежать взаимоблокировок можно, уделив этому вопросу внимание на фазе проектирования и определив правильную последовательность блокировки объектов.

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

Управление блокировками Oracle

Как упоминалось вsit, блокировки в Oracle обычно устанавливаются самим Oracle неявно, и на наименее ограничивающем уровне. Пользователи могут переопределить механизм блокирования Oracle по умолчанию, но вы не так часто столкнетесь с ситуациями, когда это может понадобиться. Большая часть управления блокировками в реальной базе данных сводится к проверке того, есть ли какие-то активные блокировки, которые мешают пользователям выполнять их операции DML. Для анализа блокировок в экземпляре можно использовать либо подход на основе сценариев, либо Oracle Enterprise Manager.

Использование SQL для анализа блокировок

На заметку!

В предыдущем примере идентификатор сеанса слева, равный 682, указывает на сеанс, которого ждет сеанс 363. Информация, выводимая справа от каждого сеанса,описывает блокировку, снятия которой он ожидает. Таким образом, сеанс 682, хотя и удерживающий блокировку, не показывает ничего (None) в столбцах, описывающих блокировки, потому что он никого не ждет. Однако строка сеанса 363 говорит о том, что этот сеанс запросил разделяемую (S) блокировку и ожидает от сеанса 682 освобождения его монопольной (X) блокировки строки таблицы.

В следующем примере из сценария utllockt.sql сеанс 9 ожидает сеанса 8, сеанс 7 ждет сеанса 9, а сеанс 10 ждет сеанса 9.

Информация блокировки справа от идентификатора сеанса описывает блокировку,освобождения которой ждет сеанс (а не которую удерживает он сам).

Рассмотрим пример простого запроса, который продемонстрирует использование представления V$SESSION для определения того, кто блокирует определенный сеанс:

Приведенный выше запрос показывает, что пользователь с SID 24 заблокирован пользователем с SID 32. Столбец EVENT указывает тип блокировки, которую удерживает блокирующий сеанс.

Использование интерфейса Database Control для управления блокировками сеансов

На странице Blocking Sessions отображаются идентификаторы блокирующих и блокируемых сеансов (рис. 1). Блокирующий сеанс можно прервать, выбрав его и щелкнув на кнопке Kill Session (Уничтожит сеанс).

Когда в экземпляре происходит жесткая конкуренция за блокировки, страница Hang Analysis помогает быстрее идентифицировать проблемы, чем запуск сценария SQL, который сам по себе может еще более ухудшить ситуацию.

Источник