Егор рассказывает зачем же нужны блокировки? Мы без них не можем корректно работать, но при этом блокировки - это проблема:) Сейчас узнаем, как они устроены)
Всем привет. Итак, блокировки.
Блокировки используются в БД очень широко, на разных уровнях.
Легких блокировок очень много, одна из самых важных - для работы с буферным кэшем.
Блокировка “buffer mapping lock”, для правок в кэш.
Плохое: только последовательно все процессы могут брать блокировку. Можно решить разбитием на несколько частей, чтобы независимо брат блокировку разными процессами. В 8.2 разделили на 16 частей, чуть позже (9.5) - на 128.
Еще одна проблема: большой поток читателей замедляет изменение, особенно на NUMA архитектурах.
Блокировки используются в БД очень широко, на разных уровнях.
Легких блокировок очень много, одна из самых важных - для работы с буферным кэшем.
Блокировка “buffer mapping lock”, для правок в кэш.
Плохое: только последовательно все процессы могут брать блокировку. Можно решить разбитием на несколько частей, чтобы независимо брат блокировку разными процессами. В 8.2 разделили на 16 частей, чуть позже (9.5) - на 128.
Еще одна проблема: большой поток читателей замедляет изменение, особенно на NUMA архитектурах.
Трансляцию для вас комментирует Иван Глушков, ведущий подкаста devzen http://devzen.ru
Иван занимается разработкой, пишет на erlang и golang. Говорит, что разбирается в распределенных системах и понимает, как работает Kubernetes, но, скорее всего, лукавит.
Иван занимается разработкой, пишет на erlang и golang. Говорит, что разбирается в распределенных системах и понимает, как работает Kubernetes, но, скорее всего, лукавит.
Блокировки, ч2
Второй вид блокировок: обычные (тяжелые) блокировки. Много типов, много режимов, и для разных задач.
В отличие от легких блокировок - честная очередь ожидания.
- pg_stat_activity - показывает очередь ожидания
- pg_lock - все блокировки
Один из примеров применения: подождать завершения какой-то транзакции.
Второй пример: расширение отношений (блокировка берется на время, пока происходит добавление страниц к таблице, индексу).
Третий пример: блокировка отношений. 8 режимов работы (например режим “Access Share” для запроса “SELECT”)
Честная очередь.
Невовремя выполненная команда парализует систему.
SELECT -> VACUUM FULL -> SELECT
Второй вид блокировок: обычные (тяжелые) блокировки. Много типов, много режимов, и для разных задач.
В отличие от легких блокировок - честная очередь ожидания.
- pg_stat_activity - показывает очередь ожидания
- pg_lock - все блокировки
Один из примеров применения: подождать завершения какой-то транзакции.
Второй пример: расширение отношений (блокировка берется на время, пока происходит добавление страниц к таблице, индексу).
Третий пример: блокировка отношений. 8 режимов работы (например режим “Access Share” для запроса “SELECT”)
Честная очередь.
Невовремя выполненная команда парализует систему.
SELECT -> VACUUM FULL -> SELECT
Блокировки, ч3
Блокировки на уровне строк. Это лучше, чем всю страницу блокировать.
Блокировка хранится в заголовке версии строки.
2 режима для изменения: update, no key update
2 режима для чтения: share, key share
Почему 4 режима, а не 2 как обычно? Потому что можно обновлять строку с изменением ключевых значений или без.
Очередь ожидания.
Когда происходит изменение строки, захват блокировки, изменение строки и отпускание блокировки происходит очень быстро, поэтому вы вряд ли ее увидите в списке блокировок.
Однако, если несколько транзакций одновременно будут пытаться записать - тут мы их и увидим.
При изменении первой версии строки мы создали вторую версию строки. И очередь на блокировку первой версии строки - становится бесполезна. Поэтому очередь ожидания рассыпается и снова выстраивается для блокировки второй версии. Получается, что порядок этой очереди может поменяться после каждого обновления.
Блокировки на уровне строк. Это лучше, чем всю страницу блокировать.
Блокировка хранится в заголовке версии строки.
2 режима для изменения: update, no key update
2 режима для чтения: share, key share
Почему 4 режима, а не 2 как обычно? Потому что можно обновлять строку с изменением ключевых значений или без.
Очередь ожидания.
Когда происходит изменение строки, захват блокировки, изменение строки и отпускание блокировки происходит очень быстро, поэтому вы вряд ли ее увидите в списке блокировок.
Однако, если несколько транзакций одновременно будут пытаться записать - тут мы их и увидим.
При изменении первой версии строки мы создали вторую версию строки. И очередь на блокировку первой версии строки - становится бесполезна. Поэтому очередь ожидания рассыпается и снова выстраивается для блокировки второй версии. Получается, что порядок этой очереди может поменяться после каждого обновления.
Хочется поговорить и есть что сказать? Найди свободную аудиторию и организуй митап:) Записывайтесь в пустые комнаты маркером на доске!
Блокировки, ч4.
Взаимные блокировки, “тупики”. Процесс1 ждет процесс2, тот ждет процесс3, тот ждет процесс1.
Поиск взаимноблокировок строит граф зависимостей блокировок, и ищет замкнутый контур. Контур найден - есть проблема, надо лечить.
Чаще всего взаимные блокировки вызваны ошибками в приложении, но не обязательно.
Например, две команды UPDATE могут взаимозаблокироваться из-за разного порядка блокировки строк: Index Scan меняется на Bitmap Index Scan после отработки автоанализа. И новые команды UPDATE будут идти по другому control flow, и могут заблокироваться со старыми UPDATE.
Взаимные блокировки, “тупики”. Процесс1 ждет процесс2, тот ждет процесс3, тот ждет процесс1.
Поиск взаимноблокировок строит граф зависимостей блокировок, и ищет замкнутый контур. Контур найден - есть проблема, надо лечить.
Чаще всего взаимные блокировки вызваны ошибками в приложении, но не обязательно.
Например, две команды UPDATE могут взаимозаблокироваться из-за разного порядка блокировки строк: Index Scan меняется на Bitmap Index Scan после отработки автоанализа. И новые команды UPDATE будут идти по другому control flow, и могут заблокироваться со старыми UPDATE.
Блокировки, ч5.
Пример. Большая система, 100 коннектов, 15000 записей в секунду, но постепенно замедляется до 0. Проблема: все больше процессов поиска взаимоблокировок с монопольным режимом, которые работают одновременно.
Причина: Расширение отношений.
Одновременно на несколько страниц (начиная с версии 9.6)
Однако, расширение индексов - только по одной странице. Это становится узкое место.
Почему? Потому что при UPDATE истекает время deadlock_timeout (из-за того, что происходит расширение индексов), что является сигналом для поиска взаимоблокировок. Это происходит постоянно, поэтому все больше процессов ищут блокировки. Есть патч, возможно скоро появится в ванильном postgresql.
Пример. Большая система, 100 коннектов, 15000 записей в секунду, но постепенно замедляется до 0. Проблема: все больше процессов поиска взаимоблокировок с монопольным режимом, которые работают одновременно.
Причина: Расширение отношений.
Одновременно на несколько страниц (начиная с версии 9.6)
Однако, расширение индексов - только по одной странице. Это становится узкое место.
Почему? Потому что при UPDATE истекает время deadlock_timeout (из-за того, что происходит расширение индексов), что является сигналом для поиска взаимоблокировок. Это происходит постоянно, поэтому все больше процессов ищут блокировки. Есть патч, возможно скоро появится в ванильном postgresql.
Блокировки, ч6.
Выводы:
1. Правильное проектирование системы. Нужно понимать внутреннее устройство. Простейший пример - избегать “горячих точек” (постоянно изменять одну строку не стоит)
2. Организационные меры. Можно снизить нагрузку, с которой система не справляется, если разделить систему на несколько подсистем.
3. Можно покупать поддержку у разработчиков postgresql. Это иногда единственный способ починить вашу проблему.
Есть пост на habr, который содержит гораздо более детальную информацию.
https://habr.com/ru/company/postgrespro/blog/462877/
Выводы:
1. Правильное проектирование системы. Нужно понимать внутреннее устройство. Простейший пример - избегать “горячих точек” (постоянно изменять одну строку не стоит)
2. Организационные меры. Можно снизить нагрузку, с которой система не справляется, если разделить систему на несколько подсистем.
3. Можно покупать поддержку у разработчиков postgresql. Это иногда единственный способ починить вашу проблему.
Есть пост на habr, который содержит гораздо более детальную информацию.
https://habr.com/ru/company/postgrespro/blog/462877/
Хабр
Блокировки в PostgreSQL: 1. Блокировки отношений
Два предыдущих цикла статей были посвящены изоляции и многоверсионности и журналированию . В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе...
Блокировки, ч7
Вопросы из зала.
- Q: Вы говорили про разделение buffer mapping lock на 128 частей начиная с 9.5. Можно ли разделить на бОльшее количество кусков для высоконагруженной базы?
- A: Подобного параметра нет, это прописано прямо в коде БД. Если есть большое желание - можно поменять в исходниках и собрать самому.
- Q: Поможет ли увеличение dead_lock_timeout в том примере с высоконагруженной базой?
- A: Нет, база будет держаться чуть дольше, но все равно рано или поздно замедляется до 0.
Вопросы из зала.
- Q: Вы говорили про разделение buffer mapping lock на 128 частей начиная с 9.5. Можно ли разделить на бОльшее количество кусков для высоконагруженной базы?
- A: Подобного параметра нет, это прописано прямо в коде БД. Если есть большое желание - можно поменять в исходниках и собрать самому.
- Q: Поможет ли увеличение dead_lock_timeout в том примере с высоконагруженной базой?
- A: Нет, база будет держаться чуть дольше, но все равно рано или поздно замедляется до 0.
Итак, готовимся к следующему слоту докладов. В 11 часов начнется:
Кафка. «Описание одной борьбы» / Денис Карасик (Badoo) — Конгресс-холл
Хардкор-трек от Романа Ивлиева:
Хэши в S3: как мы ускоряли прокачку трафика с 30 до 300 Мб/с с одного ядра / Олег Кошовец (Mail.ru Cloud Solutions) — Дели + Калькутта
Распределенные транзакции в YDB / Семён Чечеринда (Яндекс) — Пекин + Шанхай
Игра на выживание: запуск трансляций Английской Премьер-лиги в новом формате / Алексей Голубев (Okko) — Москва
Энтерпрайзные вызовы для Postgres'а / Иван Панченко (Postgres Professional) — Сингапур
BpfTrace — наконец, полноценная замена Dtrace в Linux / Петр Зайцев (Percona) — Найроби + Касабланка
Автоназначение курьеров в Delivery Club или безопасные эксперименты в логистике / Денис Горев (Delivery Club) — Рио-де-Жанейро
Раскрытие секретов Group Replication в MySQL / Vittorio Cioe (Oracle - MySQL) — Кейптаун - Этот доклад рекомендует сам Константин Осипов
От заказной разработки к продуктовой, или Трансформация организации и масштабирование / Александр Зиза, Вирна Штерн (Aletheia Digital) — Калининград (двухчасовой доклад)
в зале Мумбай докладов не будет
Кафка. «Описание одной борьбы» / Денис Карасик (Badoo) — Конгресс-холл
Хардкор-трек от Романа Ивлиева:
Хэши в S3: как мы ускоряли прокачку трафика с 30 до 300 Мб/с с одного ядра / Олег Кошовец (Mail.ru Cloud Solutions) — Дели + Калькутта
Распределенные транзакции в YDB / Семён Чечеринда (Яндекс) — Пекин + Шанхай
Игра на выживание: запуск трансляций Английской Премьер-лиги в новом формате / Алексей Голубев (Okko) — Москва
Энтерпрайзные вызовы для Postgres'а / Иван Панченко (Postgres Professional) — Сингапур
BpfTrace — наконец, полноценная замена Dtrace в Linux / Петр Зайцев (Percona) — Найроби + Касабланка
Автоназначение курьеров в Delivery Club или безопасные эксперименты в логистике / Денис Горев (Delivery Club) — Рио-де-Жанейро
Раскрытие секретов Group Replication в MySQL / Vittorio Cioe (Oracle - MySQL) — Кейптаун - Этот доклад рекомендует сам Константин Осипов
От заказной разработки к продуктовой, или Трансформация организации и масштабирование / Александр Зиза, Вирна Штерн (Aletheia Digital) — Калининград (двухчасовой доклад)
в зале Мумбай докладов не будет
Forwarded from Алексей Обровец
Перед первым докладом пообщались с Питером и Новосибом. Новосиб на моё «скажите эй» грянул громко и кайфово. В зале народ зааплодировал! Тем временем Питер очень интеллигентно поздоровался и озвучил тему светской беседы: «Почему я смотрю трансляцию с коллегами, а не из офиса?»
Forwarded from Алексей Обровец
Открытие: пдф открылся не с первого раза. Неудивительно, компьютером без консоли тут никто пользоваться не умеет.
Forwarded from Алексей Обровец
Начали с музыки. Музыканты играли зажигательно и вскрикивали «э-эй» в ритмических паузах. «Кричите «в продакшен», у народа отзовётся», - подсказал я.
И еще через 10 минут у нас начинаются митапы. Кстати, митапы обычно длятся по два часа и, что самое главное, не записываются на видео! Так что если вы выбираете межды докладом и митапом, выбирайте митап. Доклад потом посмотрите в записи.
Вот вам список куда сходить:
R1.6: PVS-Studio / Илона Ильичева
R1.7: Обучение SELinux / Иван Агарков
A1.2: Обрабатываем 30+ миллионов событий в сутки, без магии и смс / Михаил Мазеин (ManyChat)
A1.3: Поиск «плохих» запросов на постоянной основе в PostgreSQL / DataEgret
A1.5: Getting Started with Kubernetes and MySQL / Николай Маржан
Вот вам список куда сходить:
R1.6: PVS-Studio / Илона Ильичева
R1.7: Обучение SELinux / Иван Агарков
A1.2: Обрабатываем 30+ миллионов событий в сутки, без магии и смс / Михаил Мазеин (ManyChat)
A1.3: Поиск «плохих» запросов на постоянной основе в PostgreSQL / DataEgret
A1.5: Getting Started with Kubernetes and MySQL / Николай Маржан
Любите ли вы мерч, так как любим его мы? Тогда соцсети в руки — и давай постить, а потом на стенд Онтико за призами. У нас есть: стикеры, кружки, картхолдеры и прикольные салфетки из микрофибры. Публикуйте посты, отзывы или конспекты с хэштегом #HighLoad2019 и приходите к нам!