Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Hacking PostgreSQL. Лекция 1. Вводная лекция для начинающих разработчиков ядра PostgreSQL. Видео и площадка для обсуждения в блоге http://postgres-edu.blogspot.ru/2016/02/20160225.html
6. pg_dump
Снимок состояния данных
● Не возвращает в прежнее состояние
● Кроссплатформенность
● Большое время и сложность восстановления
7. репликация
● в PostgreSQL работает практически идеально
● не поможет от логической ошибки
● не является бэкапом (см пункт выше)
● не стоит бояться синхронной
8. checksums
Записанные и прочитанные данные могут содержать искажения:
● любой софт, в том числе и firmware содержит баги
● могут отключать только пользователи zfs, btrfs :)
● mdadm может сказать только что пора восстанавливать бакап
9. pg_basebackup && PITR
● восстановление быстрое, но не кроссплатформенное
● приемлемая нагрузка при снятии бэкапа (rsync)
● бэкап необходимо проверять (см пункт выше)
● доставка логов и PITR. REDO
12. Производительность
● Анализируйте происходящее!
● Логи запросов для статистического анализа (pgbadger)
● Снимайте метрики с системы и с PostgreSQL (OKMeter.IO, mamonsu, ...)
● Мы поговорим о внутреннем устройстве
13. Обработка запроса
update t
set y = y + 1 where x = 1
BACKEND
PARSER
PLANNER
EXECUTER
user=# d+ t
Table "user.t"
Column | Type
--------+---------+
x | integer |
y | integer |
Indexes:
"t_pkey" PRIMARY KEY, btree (x)
-[ RECORD 1 ]-------+---------
relid | 24639
schemaname | user
relname | t
seq_scan | 1
seq_tup_read | 0
idx_scan | 0
idx_tup_fetch | 0
n_tup_ins | 0
n_tup_upd | 0
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 0
n_dead_tup | 0
n_mod_since_analyze | 0
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0
-[ RECORD 1 ]-+-------
relid | 24639
indexrelid | 24642
schemaname | user
relname | t
indexrelname | t_pkey
idx_scan | 0
idx_tup_read | 0
idx_tup_fetch | 0
| t_xmin | t_xmax | x | y |
---------+---------+---+---+
| 1 | 2 | 1 | 1 |
---------+---------+---+---+
| 2 | 0 | 1 | 2 |
---------+---------+---+---+
Update on t
-> Index Scan using t_pkey on t
-> Index Cond: (x = 1)
14. Управление памятью
DISK STORAGE
OS CACHE
(hint: effective_cache)
SHARED BUFFERS
BACKEND (work_mem, temp_buffers)
BACKEND (work_mem, temp_buffers)
BACKEND (work_mem, temp_buffers)OS DIRTY
R/W PAGE
Write Ahead Log
15. Оптимальный размер Shared Buffers
pg_buffercache
-[ RECORD 1 ]----+------
bufferid | 331
relfilenode | 2654
reltablespace | 1663
reldatabase | 16432
relforknumber | 0
relblocknumber | 1
isdirty | f
usagecount | 5
pinning_backends | 0
● зависит от вашего железа
● зависит от типа нагрузки
● использовать pg_buffercache в бою
нельзя
● мы сделали правильную версию,
скоро будет
16. Ручки для управления памятью бакэнда
● work_mem
● maintenance_work_mem
● temp_buffers