Go!Go!Go! Fire in the Hole!

Сегодня GamerStadium проводит для нас турнир по CS:GO! С утра и до 18:30 записывайтесь и играйте в CS:GO в зоне Бразилия — возле Рио-де-Жанейро. А в 19:30 после вручения Премии две команды, вышедшие в финал, сразятся на главной сцене за звание чемпиона!

SberCity – город для разработчиков, где всегда рады провести экскурсию для путешественников. На улицах нашего города будут спрятаны пасхалки, поиск которых поможет переключить внимание и проверить свои знания. А ещё вас ждут:
• Викторина, за прохождение которой топ-50 первых участников получат powerbank
• IT-версии игр «змейка» и «бомбочка» (худи и эко-сумки для сильнейших игроков)
• Весь день – мягкиe пуфы и PlayStation
#sberteam #sbercity

Ура! Совсем скоро начинаются доклады:) Мы начинаем нашу первую трансляцию из Сингапура! У микрофона Иван Глушков!
Тема хардкорная: Блокировки в PostgreSQL, Егор Рогов(Postgres Professional)
Если вам не хватило мест, или вы опоздали, то рядом с большими залами есть выносная зона! Оттуда тоже можно смотреть и слушать трансляцию)

Андрей Шорин - ведущий трека DevOps, погрузил всех в интимный полумрак;)

Егор Рогов начал нести postgres людям)

Егор рассказывает зачем же нужны блокировки? Мы без них не можем корректно работать, но при этом блокировки - это проблема:) Сейчас узнаем, как они устроены)

Всем привет. Итак, блокировки.
Блокировки используются в БД очень широко, на разных уровнях.
Легких блокировок очень много, одна из самых важных - для работы с буферным кэшем.
Блокировка “buffer mapping lock”, для правок в кэш.
Плохое: только последовательно все процессы могут брать блокировку. Можно решить разбитием на несколько частей, чтобы независимо брат блокировку разными процессами. В 8.2 разделили на 16 частей, чуть позже (9.5) - на 128.
Еще одна проблема: большой поток читателей замедляет изменение, особенно на NUMA архитектурах.

Трансляцию для вас комментирует Иван Глушков, ведущий подкаста devzen http://devzen.ru
Иван занимается разработкой, пишет на erlang и golang. Говорит, что разбирается в распределенных системах и понимает, как работает Kubernetes, но, скорее всего, лукавит.

Блокировки, ч2
Второй вид блокировок: обычные (тяжелые) блокировки. Много типов, много режимов, и для разных задач.
В отличие от легких блокировок - честная очередь ожидания.
- 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 как обычно? Потому что можно обновлять строку с изменением ключевых значений или без.

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

Хочется поговорить и есть что сказать? Найди свободную аудиторию и организуй митап:) Записывайтесь в пустые комнаты маркером на доске!

Блокировки, ч4.
Взаимные блокировки, “тупики”. Процесс1 ждет процесс2, тот ждет процесс3, тот ждет процесс1.
Поиск взаимноблокировок строит граф зависимостей блокировок, и ищет замкнутый контур. Контур найден - есть проблема, надо лечить.
Чаще всего взаимные блокировки вызваны ошибками в приложении, но не обязательно.
Например, две команды UPDATE могут взаимозаблокироваться из-за разного порядка блокировки строк: Index Scan меняется на Bitmap Index Scan после отработки автоанализа. И новые команды UPDATE будут идти по другому control flow, и могут заблокироваться со старыми UPDATE.

Блокировки, ч5.
Пример. Большая система, 100 коннектов, 15000 записей в секунду, но постепенно замедляется до 0. Проблема: все больше процессов поиска взаимоблокировок с монопольным режимом, которые работают одновременно.
Причина: Расширение отношений.
Одновременно на несколько страниц (начиная с версии 9.6)
Однако, расширение индексов - только по одной странице. Это становится узкое место.
Почему? Потому что при UPDATE истекает время deadlock_timeout (из-за того, что происходит расширение индексов), что является сигналом для поиска взаимоблокировок. Это происходит постоянно, поэтому все больше процессов ищут блокировки. Есть патч, возможно скоро появится в ванильном postgresql.

Блокировки, ч6.
Выводы:
1. Правильное проектирование системы. Нужно понимать внутреннее устройство. Простейший пример - избегать “горячих точек” (постоянно изменять одну строку не стоит)
2. Организационные меры. Можно снизить нагрузку, с которой система не справляется, если разделить систему на несколько подсистем.
3. Можно покупать поддержку у разработчиков postgresql. Это иногда единственный способ починить вашу проблему.

Есть пост на habr, который содержит гораздо более детальную информацию.
https://habr.com/ru/company/postgrespro/blog/462877/

Блокировки, ч7
Вопросы из зала.
- 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) — Калининград (двухчасовой доклад)

в зале Мумбай докладов не будет

Перед первым докладом пообщались с Питером и Новосибом. Новосиб на моё «скажите эй» грянул громко и кайфово. В зале народ зааплодировал! Тем временем Питер очень интеллигентно поздоровался и озвучил тему светской беседы: «Почему я смотрю трансляцию с коллегами, а не из офиса?»

Открытие: пдф открылся не с первого раза. Неудивительно, компьютером без консоли тут никто пользоваться не умеет.

Начали с музыки. Музыканты играли зажигательно и вскрикивали «э-эй» в ритмических паузах. «Кричите «в продакшен», у народа отзовётся», - подсказал я.