PostgreSQL *

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

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., в течении последнего часа? Некий аналог черного ящика в самолете.

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

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

Мысли вслух

Если параметр для организации «честной/справедливой» очереди легковесных блокировок в Postgres Pro действительно позволяет решить проблему с ростом очереди ожиданий LWLock, почему значение параметра lwlock_shared_limit по умолчанию 0, а не 16?

Какие риски возникают при увеличении значения параметра lwlock_shared_limit?

Хорошо, если возможность проведения нагрузочного тестирования. Но, в продуктиве уже нет такой возможности.

И как оценить риски?

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

• Переживать за закрытие этапов договора , а не за качество, производительность и отказоустойчивость продукта .

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

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

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

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

И получить в результате постоянную очередь ожиданий и деградацию производительности в случае проблем с внешней системой и/или проблем с сетью.

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

• Воспринимать СУБД как черный ящик для хранения данных

• Не привлекать DBA к процессу дизайна и разработки

• Использовать ORM для взаимодействия с СУБД

• Не анализировать коды ошибок СУБД

• Не проводить нагрузочное тестирование

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

В общем, как в песне поется -"Раз-раз, и в продакшн"

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

Информационная система введена в промышленную эксплуатацию.

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

1. Проблемы с инфраструктурой.

2. Криворукие разрабы начали эксперименты в продуктивном контуре.

3. Администраторы системы не рассчитали систему на повышенную нагрузку со стороны пользователей.

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

А если так — какой смысл мониторить производительность СУБД?

Кроме чисто академического.

Как выяснилось, в 15-й версии PostgreSQL внесено новое изменение в инструкцию CREATE DATABASE (стратегия), существенно влияющее на поведение СУБД . Новая фича сделана по умолчанию, и для того, чтобы работало как раньше - нужно менять текст инструкции.

В результате, после обновления до 15-й версии , возникли очень существенные проблемы, вплоть до аварии СУБД.

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

В продолжении https://habr.com/ru/posts/787966/

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

Например классический сигнал на продажу - как сигнал о деградации производительности ?

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

Тут представлена попытка заNULLить значение, если оно равно чему-то.

Но ведь в PostgreSQL есть функция nullif, которая делает ровно то же самое:

NULLIF(значение1, значение2)

Функция NULLIF выдаёт значение NULL, если значение1 равно значение2; в противном случае она возвращает значение1. Это может быть полезно для реализации обратной операции к COALESCE. В частности, для примера, показанного выше:

SELECT NULLIF(value, '(none)') ...

В данном примере если value равно (none), выдаётся null, а иначе возвращается значение value.

То есть в примере выше стоит переписать короче и понятнее:

, nullif(sdate, '1900-01-01') sdate
, nullif(mdate, '1900-01-01') mdate

В своей лекции про "сложные" SELECT я уже рассказывал про возможности оператора CASE, а еще раньше - про возможности оптимизации выполнения запросов с его помощью.

Но иногда он вовсе не нужен! Обратите внимание на картинку сверху...

Посмотрим на использованный тут синтаксис CASE:

CASE
  WHEN условие THEN результат
  [WHEN ...]
  [ELSE результат]
END

Или еще конкретнее:

CASE
  WHEN условие THEN TRUE -- [условие IS TRUE]
  ELSE FALSE             -- [условие IS FALSE, IS NULL]
END

Хм... То есть результат этого CASE эквивалентен значению условия с точностью до NULL!

При обращении условия в NULL такой CASE вернет FALSE, но этого же поведения можно добиться с помощью coalesce:

coalesce(условие, FALSE)

Но если мы говорим о конкретном примере с условием EXISTS, то уж оно-то точно никак не может принимать значение NULL! Значит, coalesce-обертка нам тут не требуется и эту часть запроса можно сократить до одного лишь условия, без всяких CASE:

EXISTS(
  SELECT
    NULL
  FROM
    _inforg20687 t15
  WHERE
    t15._fld1329 = 0::numeric AND
    t15._fld20688rref = t6._idrref AND
    t15._fld20689_type = '\\010'::bytea AND
    t15._fld20689_rtref = '\\000\\000\\001\\010'::bytea AND
    t15._fld20689_rrref = t4._fld6883rref
)

В общем, пишите меньше SQL-кода - и ваши запросы "будут мягкими и шелковистыми"!