title

text

Александра Кузнецова
Александра Кузнецова Postgres Professional Младший разработчик
16:15 20 июня
22 мин

Агент мониторинга Mamonsu: обзор инструмента, его возможности

Mamonsu - активный агент мониторинга PostgreSQL на базе Zabbix. Агент активно продолжает развиваться: появляются новые уникальные метрики, возможности визуализации. Но помимо непосредственно сбора метрик, Mamonsu обладает и другим полезным функционалом. В докладе я кратко опишу возможности утилиты (также известные как "Mamonsu tools"), преимущества перед другими средствами мониторинга и процесс установки.

Слайды

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

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

  • А
    Александр, Бычков ООО "Эльбрус-2000" Аналитик
    Н
    Николай Глазков ООО "Эльбрус-2000" инженер
    22 мин

    Миграция учетной системы ФГУП «Госкорпорация по ОрВД» с СУБД Oracle на Postgres Pro

    В докладе будет рассказано о проекте миграции учетной системы, отвечающей за финансовые операции ФГУП «Госкорпорация по ОрВД» в части взимания аэронавигационных сборов за использование воздушного пространства с СУБД Oracle на СУБД Postgres Pro.

  • Павел Лузанов
    Павел Лузанов Postgres Professional Руководитель образовательных программ
    45 мин

    PostgreSQL 15: MERGE и другие

    Заморозка кода 15-й версии была в апреле, первая бета-версия PostgreSQL 15 уже доступна. Кратко расскажу о самых интересных новинках версии. В том числе о MERGE, команде с не простой историей реализации.

  • Андрей Зубков
    Андрей Зубков Postgres Professional Руководитель группы систем мониторинга
    45 мин

    Хотите ли вы знать, чем занимался VACUUM?

    В Postgres Professional ведется разработка механизма сбора детальных данных о работе вакуума в statistics collector. Я расскажу о некоторых проблемах, которые это поможет решать и покажу как это выглядит на примере расширения pgpro_pwr.

  • Павел Толмачев
    Павел Толмачев Postgres Professional Специалист образовательного отдела
    45 мин

    Коллапс в планах запросов. Достигаем и управляем

    Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.