Сейчас в Конгресс-холле идет открытие конференции. На сцене менеджеры HL2019 с презентацией. Вот ее краткий пересказ:
Будет телемост для Новосибирска и Санкт-Петербурга.
Пожалуйста, выключите звук на мобильных, чтобы не мешать другим слушателям.
Официальный хэштег #HighLoad2019 — обязательно снабжайте им свои посты, мы всё мониторим и шарим!
Вопросы задавайте в чате (@HighLoadTalks) и смотрите канал (@HighLoadChannel) — да это же мы! :)
Еще раз напоминаем о чат-боте (@hlconf_bot) и мобильном сайте. Они помогут вам с расписанием, навигацией, да и с массой других вопросов по конференции.
Доклады проходят в залах Конгресс-холл, Дели + Калькутта, Пекин + Шанхай, Москва, Сингапур, Найроби + Касабланка, Мумбай, Рио-де-Жанейро, Кейптаун. В этих залах ведется видеозапись.
Митапы проходят в Калининграде, I1.3, R1.6, R1.7, A1.2, A1.3, A1.5 — тут видеозаписи не будет! Поэтому если вы выбираете между докладом и митапом, выбирайте митап. Доклад потом посмотрите в записи.
Кстати, можно организовывать собственные митапы! Просто подходите к баннерам возле митапошных и вписывайте название своего мероприятия в свободный слот. Мы позаботимся о том, чтобы о нем рассказать участникам HL++.
Бухгалтерия находится в I1.4.
Бывает так, что в зале не остается свободных мест на докладах. Для этого мы приготовили выносные зоны возле залов, где вы можете посмотреть видеотрансляцию доклада. А потом ловите докладчика в дискуссионной зоне.
В ваших программках возле каждого доклада указан номер — это страница в брошюре с описанием этого доклада. Очень удобно.
После каждого доклада вопросы докладчику можно задать в дискуссионной зоне возле зала, где он будет находиться какое-то время после своего выступления.
У нас будет богатая вечерняя программа! И Премия HighLoad++!
Будет телемост для Новосибирска и Санкт-Петербурга.
Пожалуйста, выключите звук на мобильных, чтобы не мешать другим слушателям.
Официальный хэштег #HighLoad2019 — обязательно снабжайте им свои посты, мы всё мониторим и шарим!
Вопросы задавайте в чате (@HighLoadTalks) и смотрите канал (@HighLoadChannel) — да это же мы! :)
Еще раз напоминаем о чат-боте (@hlconf_bot) и мобильном сайте. Они помогут вам с расписанием, навигацией, да и с массой других вопросов по конференции.
Доклады проходят в залах Конгресс-холл, Дели + Калькутта, Пекин + Шанхай, Москва, Сингапур, Найроби + Касабланка, Мумбай, Рио-де-Жанейро, Кейптаун. В этих залах ведется видеозапись.
Митапы проходят в Калининграде, I1.3, R1.6, R1.7, A1.2, A1.3, A1.5 — тут видеозаписи не будет! Поэтому если вы выбираете между докладом и митапом, выбирайте митап. Доклад потом посмотрите в записи.
Кстати, можно организовывать собственные митапы! Просто подходите к баннерам возле митапошных и вписывайте название своего мероприятия в свободный слот. Мы позаботимся о том, чтобы о нем рассказать участникам HL++.
Бухгалтерия находится в I1.4.
Бывает так, что в зале не остается свободных мест на докладах. Для этого мы приготовили выносные зоны возле залов, где вы можете посмотреть видеотрансляцию доклада. А потом ловите докладчика в дискуссионной зоне.
В ваших программках возле каждого доклада указан номер — это страница в брошюре с описанием этого доклада. Очень удобно.
После каждого доклада вопросы докладчику можно задать в дискуссионной зоне возле зала, где он будет находиться какое-то время после своего выступления.
У нас будет богатая вечерняя программа! И Премия HighLoad++!
highload.ru
HighLoad++ 2019. ТЕЛЕМОСТ между Москвой, Санкт-Петербургом и Новосибирском
В 10:00 вас ждут доклады: Почему вам нужна платформа межсервисного взаимодействия и как ее построить уже сегодня? / Артемий Рябинков (Авито) — Конгресс-холл по мнению Андрея Шорина, этот доклад зайдет любому: и хардкорщику, и джуну
Основы велосипедостроения при репликации данных между дата-центрами / Евгений Кузовлев (EcommPay IT) — Дели + Калькутта
Хардкор-трек от Романа Ивлиева:
Базы данных на GPU – архитектура, производительность и перспективы использования / Денис Тишков (Технологический Центр - Deutsche Bank) — Пекин + Шанхай
Блокировки в PostgreSQL / Егор Рогов (Postgres Professional) — Сингапур
Распределенная система, которая работает везде и на всем. Как работает крупный непродуктовый Retail / Олег Филиппов (WiseAdvice) — Рио-де-Жанейро
MySQL Replication vs Galera: что лучше для твоей нагрузки? / Николай Ихалайнен (Percona) — Кейптаун
В залах Москва, Найроби + Касабланка, Мумбай и Калининград пока докладов не будет.
Основы велосипедостроения при репликации данных между дата-центрами / Евгений Кузовлев (EcommPay IT) — Дели + Калькутта
Хардкор-трек от Романа Ивлиева:
Базы данных на GPU – архитектура, производительность и перспективы использования / Денис Тишков (Технологический Центр - Deutsche Bank) — Пекин + Шанхай
Блокировки в PostgreSQL / Егор Рогов (Postgres Professional) — Сингапур
Распределенная система, которая работает везде и на всем. Как работает крупный непродуктовый Retail / Олег Филиппов (WiseAdvice) — Рио-де-Жанейро
MySQL Replication vs Galera: что лучше для твоей нагрузки? / Николай Ихалайнен (Percona) — Кейптаун
В залах Москва, Найроби + Касабланка, Мумбай и Калининград пока докладов не будет.
Обратите внимание на доклад Николая Ихалайнена из Percona в зале Кейптаун. Его очень рекомендует посетить Константин Осипов из ПК (да, тот, что сделал Tarantool).
Go!Go!Go! Fire in the Hole!
Сегодня GamerStadium проводит для нас турнир по CS:GO! С утра и до 18:30 записывайтесь и играйте в CS:GO в зоне Бразилия — возле Рио-де-Жанейро. А в 19:30 после вручения Премии две команды, вышедшие в финал, сразятся на главной сцене за звание чемпиона!
Сегодня GamerStadium проводит для нас турнир по CS:GO! С утра и до 18:30 записывайтесь и играйте в CS:GO в зоне Бразилия — возле Рио-де-Жанейро. А в 19:30 после вручения Премии две команды, вышедшие в финал, сразятся на главной сцене за звание чемпиона!
SberCity – город для разработчиков, где всегда рады провести экскурсию для путешественников. На улицах нашего города будут спрятаны пасхалки, поиск которых поможет переключить внимание и проверить свои знания. А ещё вас ждут:
• Викторина, за прохождение которой топ-50 первых участников получат powerbank
• IT-версии игр «змейка» и «бомбочка» (худи и эко-сумки для сильнейших игроков)
• Весь день – мягкиe пуфы и PlayStation
#sberteam #sbercity
• Викторина, за прохождение которой топ-50 первых участников получат powerbank
• IT-версии игр «змейка» и «бомбочка» (худи и эко-сумки для сильнейших игроков)
• Весь день – мягкиe пуфы и PlayStation
#sberteam #sbercity
Ура! Совсем скоро начинаются доклады:) Мы начинаем нашу первую трансляцию из Сингапура! У микрофона Иван Глушков!
Тема хардкорная: Блокировки в PostgreSQL, Егор Рогов(Postgres Professional)
Если вам не хватило мест, или вы опоздали, то рядом с большими залами есть выносная зона! Оттуда тоже можно смотреть и слушать трансляцию)
Тема хардкорная: Блокировки в PostgreSQL, Егор Рогов(Postgres Professional)
Если вам не хватило мест, или вы опоздали, то рядом с большими залами есть выносная зона! Оттуда тоже можно смотреть и слушать трансляцию)
Егор рассказывает зачем же нужны блокировки? Мы без них не можем корректно работать, но при этом блокировки - это проблема:) Сейчас узнаем, как они устроены)
Всем привет. Итак, блокировки.
Блокировки используются в БД очень широко, на разных уровнях.
Легких блокировок очень много, одна из самых важных - для работы с буферным кэшем.
Блокировка “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) — Калининград (двухчасовой доклад)
в зале Мумбай докладов не будет