PostgreSQL *

В продолжении темы - "время отклика СУБД" https://habr.com/ru/posts/827054/

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

Допустим имеется OLTP нагрузка на СУБД - большое количество коротких запросов. В результате, имеем некоторое значение метрики "Среднее время отклика" = sum(total_exec_time) / sum(calls).

И вот , ситуация изменилась - запросов OLTP стало меньше , но появились аналитические/долгие запросы .

В результате значение метрики увеличивается - запросов стало меньше , общее время выполнения увеличилось.

Является ли данная ситуация алертом для создания инцидента о деградации производительности СУБД ?

Конечно же - нет.

Более того - в этом случае резко увеличится количество обрабатываемых блоков разделяемой области.

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

P.S. Использование данной метрики оправдано только в одном сценарии - нагрузочное тестирование инфраструктуры при обязательном условии постоянства нагрузки на СУБД.

О мониторинге СУБД.

Классическая метрика -"Время отклика СУБД" - в реальной жизни бесполезна.

Причина - подверженность ошибке 1-го и 2-го рода.

1) Во время аварии отклик СУБД может не только не расти, но даже уменьшаться.

2) Рост времени отклика может быть вызван снижением нагрузки на СУБД.

Утилита pgpro_pwr имеет одну очень серьезную проблему - жестко установленное расписание сбора снимков с помощью take_sample.

Чтобы получить выборки со всех включённых серверов, вызовите функцию take_sample(). Обычно достаточно получать одну-две выборки в час. Для выполнения этой функции по расписанию можно воспользоваться планировщиком cron или подобным.

Последствия:

1)Невозможно собрать статистику производительности и состояния СУБД во время инцидента производительности . Например, если снимки собираются по рекомендации, указанной в документации - каждые полчаса , то практически нельзя ничего сказать о состоянии СУБД в течении 5-10 минут, в которые было зафиксировано снижение производительности в середине 30-ти минутного промежутка.

2) Ожидания в разделе "Top waits" не коррелированы с показателями производительности СУБД. Отчет показывает ожидания отсортированные по времени. И только за весь период снимка. Установить, какое именно ожидание/ожидания (и следовательно запрос/запросы) повлияло/повлияли на деградацию производительности СУБД во время инцидента - практически невозможно.

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

• 11:10 - 13:20 : Нисходящий тренд (снижение производительности )

• 13:30 - 15:40 : Восходящий тренд ( рост производительности )

Казалось бы, в период 11:10-13:20 - инцидент деградации производительности.

НО.

Корреляционный анализ событий ожиданий и показателей производительности показал – корреляция между событиями ожидания и изменением производительности в период 11:10 – 13:20 - отсутствует.

Вероятнее всего, из данного факта следуют следующие выводы:

1. Аномалии СУБД в период 11:10 - 13:20 – отсутствуют

2. Снижение производительности СУБД вызвано внешними причинами (снижение количества подключений, изменение характера запросов, снижением числа запросов и т.д. и т.п. ) .  Т.е. причинами, находящимися вне зоны ответственности DBA.

Обновление библиотеки asyncpg-lite до версии 0.3.1.1

Рад сообщить, что библиотека asyncpg-lite обновлена до версии 0.3.1. Все предыдущие версии были удалены и больше не доступны для установки. Для корректной работы, пожалуйста, удалите старые версии с помощью следующей команды:

pip uninstall asyncpg-lite

Чтобы установить последнюю версию, используйте:

pip install --upgrade asyncpg-lite

Актуальная версия: 0.3.1.1

Вы можете найти страницу библиотеки на GitHub по следующему адресу: asyncpg-lite на GitHub.

Что нового в версии 0.3.1.1

В этой версии все методы библиотеки были переписаны. Если ранее библиотека работала исключительно с чистым asyncpg, то теперь asyncpg используется как асинхронный драйвер для взаимодействия с PostgreSQL, а все запросы выполняются через SQLAlchemy.

Причины обновления

Основная причина переписывания библиотеки — улучшение безопасности. Старые версии имели определенные уязвимости, которые теперь устранены.

Подробный разбор новой версии библиотеки я постараюсь опубликовать завтра в формате статьи.

Благодарю за ваше внимание и поддержку!

Все те кто пользовался библиотекой asyncpg-lite. Сообщаю, что завтра вечером будет выпущено обновление библиотеки asyncpg-lite. В новой версии библиотека будет полностью переписана с использованием SQLAlchemy и asyncpg (в старой версии использовался чистый asyncpg), при этом базовый синтаксис останется практически неизменным.

Такое решение принято из-за ограничений чистого asyncpg в предотвращении SQL-инъекций. Вместо разработки собственного решения я решил воспользоваться проверенными инструментами ORM, которые предоставляет SQLAlchemy, но, при этом, я постарюсь максимально сохранить ту простоту в использовании, которая была в старых версиях asyncpg-lite.

Начиная с версии asyncpg-lite 0.3, библиотека будет основываться на SQLAlchemy и драйвере asyncpg для работы с PostgreSQL. Версии ниже 0.3 будут сняты с доступности для скачивания и установки с завтрашнего дня.

С выходом asyncpg-lite 0.3 настоятельно рекомендуем удалить старые версии библиотеки и установить актуальную.

Вместе с новой версией библиотеки будет опубликована сопроводительная статья, подробно описывающая все изменения в синтаксисе.

Благодарю за внимание! 🚀

Статистический анализ производительности СУБД - первые итоги : быстрый поиск аномалий, в первую очередь с целью избежать непродуктивной траты времени в ответ на очередную иллюзию манагеров -"мы упёрлись в СУБД". Нет, коллеги с СУБД все в порядке, разбирайтесь с вашими альтернативно одаренными разработчиками и приложением.

1) Статистика производительности СУБД- скользящие средние , стандартное отклонение , дисперсия : полезно для оценки текущего состояния и подготовки baselines и оповещений по проблемам производительности.

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

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

4)Быстрые/медленные скользящие средние, тренды, свечи, уровни поддержки - это просто красиво :-) Манагерам нравятся красивые картинки.

asyncpg-lite обновлена до версии 0.2.2.1!

В новой версии:

• Убран флаг dsn_flag (теперь достаточно не передавать данные в параметр dns и состояние этого флага будет автоматически сброшено на dsn_flag = False)

• Параметр deletion_password теперь обязательный (это сделано для безопасного выполнения критических операций - используйте надежный пароль)

• Добавлен флаг debug: bool во все методы (по умолчанию его значение False)

• Исрпавлены ошибки и улучшены логи (теперь там больше полезной информации)

Зачем нужен флаг debug?

Установив этот флаг в методе вы сможете вывести в консоль дополнительную информацию, такую как параметры запроса и сам SQL-запрос.

На уровень всего класса DatabaseManager не выводил, чтоб не перегружать консоль информацией.

С библиотекой вы сможете ознакомиться тут: asynpg-lite: Простой асинхронный менеджер для PostgreSQL на Python

Благодарю за обратную связь. Обязательно оставляйте свои замечания и пожелания к новым дополнениям к библиотеке.

Приглашаем на новый бесплатный вебинар «PostgreSQL: один за всех?».

Рассмотрим несколько классов задач, для которых в последние годы применяют отдельные СУБД, и обсудим, как можно их решить, не выходя из PostgreSQL. Поговорим про варианты использования PostgreSQL в не самых типичных для реляционной СУБД ролях. И ответим на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных или можно обойтись одним PostgreSQL?

📅 Дата: 20.06.2024

⏰ Время: 14:00-15:00 (Мск)

На вебинаре рассмотрим:

✔️ Виды СУБД.

✔️ Способы расширения PostgreSQL.

✔️ Как хранить и искать документы.

✔️ Как хранить и работать с временными рядами.

✔️ Как хранить эмбеддинги и быстро их искать.

✔️ Как строит многомерные кубы.

✔️ Когда все это стоит делать, а когда нет.

👨‍🎓 Спикер: Брейман Александр — эксперт Учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.

💥 Зарегистрироваться 💥

Мысли вслух - DBA ремесло или наука ?

Судя по полному отсутствию найденных материалов по применению математического аппарата для задач администрирования баз данных - современные администраторы баз данных в лучшем случае художники , а как правило ремесленники.

Обсуждение с коллегами показало - полное отсутствие интереса и полное непонимание - в чем сила и смысл использования математических методов.

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

Да, что там, даже нет четкого математического определения- что считается производительностью базы данных и как измерять.

А ведь в сущности нормальная работа администратора баз данных состоит в анализе результатов наблюдений. Странно , но почему то, стандартные методики анализа, успешно применяемые в других технических областях, в DBA - не используются.

Что ж , тем интереснее будет на чистом листе . Может , кому и пригодится и поможет в итоге. Для себя то уже есть первые результаты , но пока надо все аккуратно сформулировать и оформить. И конечно - набирать статистику наблюдений.

P.S.Пример из жизни - имеется пул соединений к СУБД - как определить, что характер нагрузки изменился ?

В продолжении предыдущего поста. Получены интересные результаты значений коэффициента корреляции между:

1. Количество событий ожидания и показателем производительности СУБД

2. Количество соединений с конкретного ip и показателем производительности СУБД

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

IO ControlFileSyncUpdate -0,155750768

Client ClientWrite -0,132699875

LWLock XactSLRU -0,123296926

...

Отрицательная корреляция между количеством соединений с конкретного ip и показателем производительности СУБД - умеренная:

XX.XXX.XXX.1 -0,43280346

XX.XXX.XXX.2 -0,41262827

XX.XXX.XXX.3 -0,409033529

XX.XXX.XXX.4 -0,388472

XX.XXX.XXX.4 -0,376145747

...

Теперь начинается самое интересно - сбор статистики наблюдений и интерпретация результатов корреляционного анализа .

Или я плохо ищу или действительно , тема корреляционного анализа производительности СУБД , еще не исследовалась.

Например было бы очень интересно установить - какой из факторов оказывает максимальное влияние на производительность СУБД или наоборот - как производительность СУБД влияет на показатели СУБД и инфраструктуры :

• Количество соединений

• Утилизация CPU

• Утилизация RAM

• Утилизация I/O

• Количество ожиданий СУБД

• Показатели CPU (iowait и т.п)

• Показатель Cache Hit Ratio

• Объем обработанных блоков shared_buffer

• Что-то еще из огромного списка метрик

Postgres Professional представила новую лицензию СУБД Postgres Pro для пользователей «1С: Предприятие».

Клиенты компании теперь могут приобрести СУБД Postgres Pro Enterprise для 1С без включенного первого года стандартной технической поддержки. При этом доступ к обновлениям и новым версиям сохраняется.

По словам компании, такой вариант лицензии сокращает затраты на покупку ПО до 25%.

По поводу тестирования встроенного пула Postgres Pro, ситуация складывается странная : при использовании параметра "--connect" , если размер пула меньше чем "clients" - pgbench зависает. Все соединения имеют состояние 'Idle in transaction'.

Пока не разобрался это бага или фича.

Видимо, придется делать свой скрипт для оценки влияния пула на производительность приложений работающих по схеме "новая транзакция - новое соединение".

Update: Вопрос закрыт - pgbench не предназначен для тестирования нагрузки с использованием пула соединений. Придется сочинять свой инструмент.

Приглашаем на новый бесплатный вебинар «Oracle PL/SQL и PostgreSQL PL/pgSQL: сходства, различия и переход с первого на второй»!

Дата: 12.04.2024
Время: 14:00-15:00 (МСК)

Многие бизнес-приложения используют Oracle для хранения данных и обработки их с помощью хранимых процедур. Но для снижения рисков и выполнения требований по импортозамещению необходимо переходить на другие СУБД. В этом случае PostgreSQL становится отличным вариантом. На вебинаре рассмотрим основные моменты, на которые нужно обратить внимание при миграции.

В рамках вебинара:
• обсудим общее устройство языков;
• поговорим про сходства и различия в типах данных;
• расскажем про большие объекты и временные таблицы;
• поговорим про автономные транзакции;
• обсудим секционирование;
• подискутируем про средства отказоустойчивости.

Спикер вебинара: Брейман Александр — эксперт учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.

Регистрация по ссылке.

#PostgresPro #PgConf2024 большое спасибо за приглашение. Это было очень круто !!!.

Отличная атмосфера, шикарные доклады. Два дня пролетели как одно мгновение. Общение с интересными людьми, возможность пообщаться коларуарах с экспертами postgres и не только и узнать ответы на свои вопросы. Завести новые знакомства

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

P.s. Было настолько интересно и увлекательно, что только по дороге домой я понял, что не сделал не одной фотографии на фоне РgConf Russia 2024

В продолжении темы "Как измерить производительность СУБД" https://habr.com/ru/posts/787966/

В ходе анализа результатов установлено, что, хотя используемый вектор: (N1, N2, N3), где:

• N1 - количество активных сессий

• N2 - количество транзакций

• N3 - количество запросов к СУБД в секунду.

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

Было принято решение изменить методику расчета, используя вектор:(N1, N2, N3, N4, N5), где:

• N1 - количество страниц shared_buffer , прочитанных в секунду

• N2 - количество страниц shared_buffer, записанных в секунду

• N3 - количество страниц shared_buffer, измененных в секунду

• N4 - количество завершенных запросов в секунду

• N5 - количество зафиксированных транзакций в секунду

Метрика , как и в предыдущем варианте будет считаться как модуль вектора.

Мысли вслух

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

Влияние и эффект тонкого тюнинга параметров СУБД на итоговую производительность информационной системы настолько незаметны, что все эксперименты носят исключительно академический характер.

Разумеется, при условии правильной начальной настройке СУБД: work_mem, shared_buffers, autovacuum, etc.

P. S. Особенно вредно и абсолютно непродуктивно менять параметры СУБД во время аварийной ситуации(что как раз и очень любят настойчиво требовать разнообразные манагеры).

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

• Проводить оценку производительности при реальной нагрузке в продуктивном контуре, а не на тестовом стенде.

• Не иметь метрик производительности информационной системы, оценивать производительность по обратной связи пользователей — «ой стало медленно работать».

• Не проводить тестирование последствий изменений инфраструктуры на тестовом стенде, сразу проводить изменения в продуктиве.

Мысли вслух

А, что если сделать скрипт, который по cron, каждую минуту собирает результаты запросов к системным представлениям pg_stat_activity/pg_locks/etc., в течении последнего часа? Некий аналог черного ящика в самолете.

А при возникновении предаварийной/аварийной ситуации — глубину хранения увеличить.

Наверное, должно сильно помочь, при установлении корневой причины аварии информационной системы.