kznalp

kznalp

Эксперименты по анализу и оптимизации производительности PostgreSQL. Вначале любая оригинальная теория признается абсурдной, потом — верной, потом — самоочевидной и незначительной, и, наконец, столь важной и самобытной, что бывшие критики присваивают ее себе. — Уильям Джеймс (1842–1910) Эксперименты по анализу и оптимизации производительности PostgreSQL. Оперативно-тактический комплекс мониторинга СУБД PostgreSQL - PG_HAZEL "Орешник". https://t.me/pg_hazel https://dzen.ru/kznalp
Пикабушник
в топе авторов на 370 месте
30К рейтинг 144 подписчика 16 подписок 427 постов 35 в горячем
2

PG_HAZEL "Орешник" - Революционный комплекс для анализа производительности СУБД PostgreSQL

PG_HAZEL "Орешник" - Революционный комплекс для анализа производительности СУБД PostgreSQL Субд, Postgresql, Пресс-релиз, Длиннопост

Слон может немного отдохнуть в тени орешника.

📅 Дата публикации: 15 сентября 2025 года
📍 Место: Россия

Новая веха в мониторинге и диагностике производительности PostgreSQL

Комплекс PG_HAZEL представляет собой инновационное решение для глубокого анализа производительности СУБД PostgreSQL. Этот инструмент сочетает в себе методы статистического анализа, мониторинга в реальном времени и причинно-следственного моделирования, что позволяет точно определять корневые причины инцидентов производительности и прогнозировать потенциальные сбои.

PG_HAZEL использует методы корреляционного анализа для установления взаимосвязей между:

  • Метриками ОС (iostat, vmstat, использование CPU, памяти, дискового I/O).

  • Ожиданиями СУБД PostgreSQL (типы ожиданий IO, IPC, LWLock, и др.).

  • Показателями производительности СУБД (операционная скорость, ожидания СУБД, индикатор деградации производительности СУБД).

💡 Ключевые особенности PG_HAZEL

  1. Тактический и оперативный анализ
    PG_HAZEL работает на тактическом уровне, анализируя влияние отдельных SQL-запросов на производительность СУБД. Он идентифицирует запросы, которые оказывают наибольшее негативное воздействие, и связывает их с конкретными типами ожиданий (IO, IPC, LWLOCK).

  2. Многомерный анализ производительности
    PG_HAZEL интегрирует данные из различных источников, включая метрики ОС (iostat, vmstat), события ожидания PostgreSQL и статистику выполнения SQL-запросов. Это позволяет построить единую модель производительности и количественно оценить вклад каждого фактора в общую производительность СУБД.

  3. Планируемое направление развития : причинно-следственный анализ и прогнозное моделирование, визуализация и интерактивные дашборды
    Используя методы причинности по Грэнджеру и байесовские сети, комплекс поможет выявляет не просто корреляции, а реальные причинно-следственные связи между метриками. Например, он может определить, что рост времени отклика диска (await) вызывает увеличение времени ожидания ввода-вывода в PostgreSQL, что приводит к деградации производительности. Используя методы ARIMA и машинного обучения возможно будет прогнозировать инциденты производительности СУБД PostgreSQL , таких как исчерпание дискового пространства или достижение критической нагрузки на CPU. Это позволит администраторам СУБД заранее принимать превентивные меры.
    Тепловые карты(heatmaps) корреляций и дашборды, позволят быстро выявлять аномалии и анализировать их в контексте всех метрик.

🚀 Практическое применение

PG_HAZEL уже успешно применяется для анализа инцидентов производительности в реальных условиях.

Кроме того, комплекс используется для нагрузочного тестирования, помогая определить предельные значения нагрузки, которые СУБД может выдержать без деградации производительности.
📈 Преимущества подхода

Раннее обнаружение проблем

Анализ метрик ОС позволяет выявлять потенциальные проблемы до их воздействия на производительность СУБД:

  • Прогнозирование исчерпания дискового пространства

  • Выявление растущей нагрузки на CPU и память

  • Обнаружение деградации производительности дисковых подсистем

Снижение времени восстановления

Точное определение корневой причины инцидентов значительно сокращает время восстановления:

  • Четкое разграничение проблем ОС и проблем СУБД

  • Возможность фокусирования на реальной причине, а не симптомах

📊 Примеры использования:

1.Рост ожиданий типа IO в PostgreSQL:

В ходе анализа инцидента производительности PG_HAZEL выявил, что наибольшая корреляция наблюдается между ожиданиями типа IPC и снижением операционной скорости СУБД. Это указало на проблему взаимодействия между процессами, что позволило администраторам быстро устранить причину.

2.Рост времени отклика дисков в iostat:

  1. Начало инцидента: Рост утилизации CPU и значений iowait в метриках ОС

  2. Корреляционный анализ: Выявление высокой корреляции между:
    - Ростом времени ожидания записи для устройств хранения (/data и /wal)
    - Снижением производительности СУБД
    - Ростом ожиданий типа IO в PostgreSQL

  3. Заключение: Первичной причиной являлись проблемы на уровне дисковых подсистем

💬 Цитата разработчика

«PG_HAZEL — это не просто инструмент мониторинга, а экспертная система, которая превращает разрозненные метрики в понятные и осуществимые предложения. Наша цель — сделать диагностику производительности PostgreSQL максимально автоматизированной и точной».

🔮 Планы развития

В ближайших планах развития PG_HAZEL — разработка и внедрение методов причинно-следственного анализа и прогнозного моделирования.

📌 О компании

Разработчик PG_HAZEL специализируется на создании решений для мониторинга и анализа производительности СУБД PostgreSQL.

Наша миссия — помогать компаниям поддерживать высокую производительность и надежность их баз данных.

📞 Контакты для СМИ

Для получения дополнительной информации обращайтесь:
Имя: Сунгатуллин Ринат Раисович
Телефон: +7 927 245 80 49
Email: kznalp@yandex.ru
Веб-сайт: https://dzen.ru/kznalp

💎 Заключение

PG_HAZEL устанавливает новый стандарт в мониторинге и диагностике производительности PostgreSQL. Его способность объединять данные из различных источников, выявлять корневые причины проблем и прогнозировать инциденты делает его незаменимым инструментом для администраторов баз данных и IT-специалистов.

Для получения более подробной информации посетите https://dzen.ru/kznalp.

PG_HAZEL : комплексное решение для мониторинга и анализа производительности СУБД PostgreSQL.

Показать полностью

Это хорошая новость - Max

✔ Платформа Max от VK получила статус национального мессенджера.
Главное о платформе:

▪Премьер-министр РФ Михаил Мишустин 15 июля подписал документ о создании национального мессенджера. Этим сервисом станет Мax, его разработала компания "Коммуникационная платформа", которая принадлежит холдингу VK.

Инфраструктура Max находится на территории РФ, что гарантирует надежное хранение данных и защиту пользователей.

▪Мессенджером пользуются уже более 2 миллионов человек. Он включен в реестр российского ПО и доступен в мобильной, веб- и ПК-версиях.

▪В Max доступны групповые видеозвонки и чаты, отправка файлов до 4 ГБ, денежные переводы, ИИ-помощник GigaChat 2.0, мини-приложения, а также информационные каналы.

▪В ближайшее время пользователям станет доступно подключение к "Госуслугам", использование "Цифрового ID" для подтверждения личности, сервис "Госключ" для подписания документов и образовательные сервисы.
https://t.me/tass_agency/325432


P.S. Самое примечательное в новости - очередной повод для раздражения желчегонов 😉


Это хорошая новость - Max Российское производство, IT, Мессенджер, Текст, Telegram (ссылка)

Показать полностью 1
4

Влияние агрессивного autovacuum на производительность СУБД для малой и большой СУБД

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Влияние агрессивного autovacuum на производительность СУБД для малой и большой СУБД Инженер, Субд, Postgresql, Настройка, Тестирование, Длиннопост

Общие принципы работы одинаковы, но размер имеет значение.

Задача

Проанализировать влияние размера и ресурсов СУБД на изменение производительности СУБД при агрессивной настройке autovacuum.

Малая СУБД

CPU = 2

RAM = 2GB

Размер тестовой БД = 10GB

Тестовая таблица ~60 000 000 строк

Влияние настройки autovacuum на производительность СУБД

Операционная скорость

Влияние агрессивного autovacuum на производительность СУБД для малой и большой СУБД Инженер, Субд, Postgresql, Настройка, Тестирование, Длиннопост

Ось X - точка наблюдения .Ось Y - операционная скорость

Операционная скорость за весь период теста

  • Средняя относительная разница операционной скорости в экспериментах 1 и 2 составила : -3%

Операционная скорость при малой нагрузке ( до 10 соединений)

  • Средняя относительная разница операционной скорости в экспериментах 1 и 2 составила : 4%

Операционная скорость при высокой нагрузке ( свыше 10 соединений)

  • Средняя относительная разница операционной скорости в экспериментах 1 и 2 составила : -6%

Большая СУБД

CPU = 200

RAM = 1TB

Размер тестовой БД = 10TB

Тестовая таблица ~70 000 000 000 строк

Влияние агрессивного автовакуума на производительность большой СУБД

Влияние агрессивного autovacuum на производительность СУБД для малой и большой СУБД Инженер, Субд, Postgresql, Настройка, Тестирование, Длиннопост

Ось X - точка наблюдения. Ось Y - операционная скорость

  • Средний прирост производительности в эксперименте-7 по сравнению с экспериментом-1 составил 13.30%

  • Максимальный прирост производительности в эксперименте-7 по сравнению с экспериментом-1 составил 35.83%

Вывод

Для обеспечения эффективного обслуживания и повышения производительности СУБД необходимо запланировать ресурсы - в частности на выполнение регулярных операций autovacuum.

Показать полностью 2
1

Современный стиль разработки это

Разработчики и менеджеры пытаются решить проблему деградации производительности информационной системы, заливая инфраструктуру ресурсами, не исправляя кривой код приложения.

Современный стиль разработки это Нейронные сети, Контент нейросетей, IT юмор
Показать полностью 1
2

Классические этапы разработки проекта - триптих

Часть 1 - Начало.

Классические этапы разработки проекта - триптих Контент нейросетей, Арты нейросетей, Юмор, IT юмор

Команда амбициозных манагеров и разрабов с энтузиазмом начинает новый проект .
Все полны энтузиазма и надежд на будущее.
Мир прекрасен , всё впереди.


Часть 2 - Всё не так радужно

Классические этапы разработки проекта - триптих Контент нейросетей, Арты нейросетей, Юмор, IT юмор

Разработка и тестирование в полном разгаре. Все складывается не так, как хотелось. Требования ТЗ не выполняются , кругом костыли и заплатки.
Всеобщее уныние и депрессия.
Мы переоценили свои силы .


Часть 3 - финал.

Классические этапы разработки проекта - триптих Контент нейросетей, Арты нейросетей, Юмор, IT юмор

Менеджеры и PR рапортуют об отличных результатах . Пресса наполнена хвалебными откликами.
Пользователи и инженеры пытаются понять - как с этим работать.
Награждение непричастных, наказание невиновных.


Показать полностью 2
3

"Черное зеркало" , сезон - 3 , эпизод 6 - уже скоро фантастика перестанет быть фантастикой

Китайские ученые заявили о прорыве в области нейротехнологий: им удалось создать первого в мире киборга-пчелу, оснащенную ультралегким имплантированным контроллером мозга. Это устройство весит менее одного грамма и позволяет дистанционно управлять поведением насекомого.
https://www.gazeta.ru/social/news/2025/07/11/26249432.shtml


"Черное зеркало" , сезон - 3 , эпизод 6 - уже скоро  фантастика перестанет быть фантастикой Китай, Черное зеркало, Киборги

Мой самый любимый эпизод сериала . Ну после первого, разумеется.


Показать полностью 1
Отличная работа, все прочитано!