title

text

Андрей Зубков
Андрей Зубков ООО "Пармалогика" Администратор баз данных
17:00 04 февраля
45 мин

Простой инструмент исторического анализа производительности - pg_profile

В поиске проблем производительности администраторам баз данных необходим инструмент исторического анализа нагрузки. Особенно важен подобный инструмент в случаях, когда было зафиксировано время нехарактерного снижения производительности системы, и вам надо выяснить что больше всего нагружало вашу СУБД в это время. Это и поиск ресурсозатратных запросов, и поиск активных и растущих объектов в схеме данных, статистики использования пользовательских функций и использования temp. Существует несколько инструментов, так или иначе решающих эту задачу. Я расскажу об одном таком инструменте, который легко устанавливается в виде расширения к СУБД Postgres, легко настриавается и позволяет получить отчет о нагрузке за некоторый период в прошлом, который будет неплохой начальной точкой дальнейшего расследования.

Слайды

Видео

Другие доклады

  • Константин Евтеев
    Константин Евтеев X5 FoodTech Главный архитектор
    45 мин

    10 лет PostgreSQL в Avito

    PostgreSQL с момента старта Avito решает серьезные и важные задачи. Вокруг СУБД были построены основные компоненты архитектуры. За 10 лет проект активно развивался, изменилась архитектура и инфраструктура.

    Как вступление, сделаю обзор: эволюции архитектуры и инфраструктуры PostgreSQL в Avito; успешно решенных вызовов.

    В основной части расскажу о статусе PostgreSQL в Авито 2020: микросервисная архитектура; шардирование; проблемы коммуналок; DBaaS( Database discovery, управление доступом, failover, backup, archive, вопросы разделения ресурсов итд.); вопросы интеграции; эволюция команды.

    В заключение поделюсь нашим wishlist/нерешенными вопросами.

  • Shawn Kim
    Shawn Kim Apposha CEO
    45 мин

    Make Your PostgreSQL 10x Faster on Cloud in Minutes

    Cloud storage has some unique characteristics compared to traditional storage mainly because it is virtualized and controlled by software. One example is that AWS EBS shows higher throughput with larger I/O size up to 256 KiB without hurting latency. Hence, a user can get only about 4 MiB/sec with 1,000 IOPS EBS volume if the I/O request size is 4 KiB, whereas a user can get about 250 MiB/sec if the I/O request size is 256 KiB. This is because EBS consumes one I/O in a given IOPS budget for every I/O request regardless of the I/O size (up to 256 KiB). Unfortunately, PostgreSQL cannot exploit the full potential of cloud storage because PostgreSQL has designed without considering the unique characteristics of cloud storage.

    In this talk, I will introduce the AppOS extension that improves the throughput of a write-intensive workload by 10x by transparently making PostgreSQL cloud storage-native. AppOS works like a storage driver that efficiently exploits the characteristics of cloud storage, such as I/O size dependency to storage throughput and latency, atomic write support in cloud block storage, and fast, but non-durable local SSDs. To do this, AppOS comprises a Linux-compatible file I/O stack including virtual file system, page cache, block I/O layer, cloud storage driver. On top of the file I/O stack, syscall module supports registering pre- and post-handler for file I/O-related system calls in order to transparently work without modifying PostgreSQL codes.

    I will focus on presenting key use cases and performance results of the AppOS extension after explaining the internals. Specifically, I will show the performance results of OLTP and some batch workloads using standard benchmarking tools like pgbench and sysbench. I will also present performance results and implications on multiple clouds including AWS, GCP, and Azure.

  • Александр Кварацхелия
    Александр Кварацхелия БАРС Груп Архитектор программного обеспечения
    Александр Чирков
    Александр Чирков Барс Груп Архитектор ПО
    45 мин

    Миграция с Oracle на PostgreSQL с использованием автоматического конвертера

    В докладе мы хотим рассказать об опыте миграции одной большой системы с Oracle на PostgreSQL. Сама система построена на стеке PHP + Oracle, её отличительной особенностью было то, что вся бизнес-логика была реализована в PL/SQL коде. В СУБД - это более 3000 пакетов с 4-10 функциями (процедурами) в каждом. В PHP - более 10000 форм со вставками анонимных блоков, используемых для получения данных, обработки и сохранения результатов в Oracle.

    Для решения этой крайне объемной работы мы взяли ANTLR4 (синтаксический анализатор для чтения, обработки, выполнения или перевода структурированного текста), грамматику PL/SQL и создали автоматический конвертер, который позволяет преобразовать все объекты схемы и нашей системы из Oracle в рабочий код для PostgreSQL.

  • Максим Милютин
    Максим Милютин Ozon Ведущий разработчик ПО
    90 мин

    Patroni и stolon: инсталляция и отработка падений

    Patroni и Stolon - два наиболее известных и продвинутых решения для оркестрации PostgreSQL и обеспечения выскокой доступности (автофейловера) кластеров Leader-Followers конфигурации. Однако инженеры, переходящие со старых проверенных решений (Corosync&Pacemaker) и встроенных из других СУБД, сталкиваются со сложностями в инсталляции этих инструментов и непониманием ролей каждого из компонентов. В данном мастер-классе будет рассмотрен типичный процесс инсталляции кластеров Patroni и Stolon на виртуальных машинах (не в контейнерах), а также разобрано поведение этих кластеров при различных фейлах в инфраструктуре. Весь процесс будет демонстрироваться на трёх виртальных машинах под управлением vagrant с использованием предварительно подготовленных образов. При желании слушатель может следовать за процессом, предварительно подготовив своё окружение.