Продолжение по теме
Распределение значений бенчмарка

Вопрос : При условии постоянной нагрузки и неизменного тестового запроса , какое распределение значений бенчмарка производительности СУБД для СУБД PostgreSQL будет встречаться чаще ?

Ответ YandexGPT:

При постоянной нагрузке и неизменном тестовом запросе для PostgreSQL наиболее вероятными будут следующие типы распределений значений бенчмарка производительности:

Нормальное распределение (Гауссово) - наиболее часто встречается при стабильной работе системы. Характеризуется симметричным колоколом с преобладанием средних значений и постепенным убыванием частоты крайних значений.

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

Распределение Пуассона - может наблюдаться при подсчете количества операций за фиксированный период времени при редких событиях.
Факторы, влияющие на форму распределения:

Нагрузка на CPU и RAM
Состояние кэша
Конфигурация PostgreSQL
Тип и сложность запроса
Параллельность выполнения
При анализе производительности важно отслеживать не только среднее значение, но и дисперсию, медиану и квартили, так как даже при нормальном распределении могут возникать значимые отклонения из-за внешних факторов или особенностей работы СУБД.

Для получения более точных результатов рекомендуется проводить бенчмарки в течение длительного периода времени и учитывать различные процентили (например, 95-й и 99-й), а не только среднее значение.

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

Продолжение игр с большими языковыми моделями .

Вопрос : Расскажи мне про использование индикатора CPI при анализе производительности СУБД PostgreSQL

Ответ DeepSeek , не приводится , китаец как обычно , по данной теме, полную пургу несет.
Ответ YandexGPT:

**CPI** (Cycles Per Instruction) в контексте PostgreSQL представляет собой метрику производительности, которая рассчитывается как модуль вектора из трех показателей:

* **QPS** - количество запросов в секунду
* **TPS** - количество транзакций в секунду
* **RPS** - количество строк, полученных клиентом в секунду

Для измерения времени выполнения операций используются данные из системных представлений:
* **active_time** из pg_stat_database
* **total_exec_time** из pg_stat_statements

Дополнительно введены расширенные метрики:
* **CPI_VOLUME** - объем обработанных блоков распределенной памяти при выполнении SQL-операторов
* **CPI_RATIO** - отношение основной метрики производительности к объему обработанных блоков

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

При проведении анализа производительности рекомендуется следующий подход:
* Выполнить серию тестовых операций (SELECT, INSERT, UPDATE, DELETE)
* Создать необходимые индексы
* Повторить тестовые операции
* Проанализировать полученные результаты

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

Сразу бросается в глаза полное несоответствие описания и расчёта .

Но самое неприятное не в этом , а в том, что если вдруг кто то из поклонников "искусственного интеллекта" решит сэкономить время (ну это же заявлено как основная выгода ) он потеряет массу времени и соберет по пути все грабли и аномалии , потому что методика расчета, которую привел YandexGPT - неверная , устаревшая и давно неиспользуемая .
Т.е. в данном случае "искусственный интеллект" не помогает, а вредит.

Что делать ? Не доверять чат ботам, включать голову , искать и работать с первоисточниками и материалами самостоятельно .
Лучше с авторами.

Надысь , в процессе сёрфинга наткнулся на интересную реплику из зала под лозунгом "вся это ваша оптимизация производительности это шарлатанство "

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

Начало цитаты
Ну как бы "производительность БД" "по факту" не интересна никому...
Это интересное замечание , потому как использует стандартное обобщение "непонятно и неинтересно мне , а значить никому".
Всех "по факту" интересует "производительность прикладного приложения".
При этом никто(и это факт по крайней мере в окружающей реальности ) не знает и не умеет считать "производительность приложения".
Да есть связи между ними, но они "совсем не простые"... :-)
Астрология , магия и алхимия в начале 21го века . "Связи есть, но они не простые" Меркурий в третьем доме , блин , связан с Венерой в зодиаке 🤪
К примеру БД нагружается (выразимся так) "различными прикладными задачами".
Это очень интересный термин "нагружается". Ну , а что взяли тачку нагрузили чернозёмом . С БД также - "нагружается".
И у прикладных "задач" есть различные "требования" по времени ответа (от БД в том числе).
Требования есть только в волшебном лесу эльфов. В реальном мире нагрузочное тестирование проводят, чтобы подписать этап договора. Нет никаких требований, правило простое - закрыть этап, получить бабки , как то работает и ладно.
Если в БД нет "встроенных" средств "приотеризации" - это уже "не есть хорошо".
А зачем ?
Вот и получаем ситуацию когда один (для приложения не приоритетный) запрос в БД (который БД обрабатывает как бы быстро и оптимально) "убивает" производительность других приоритетных для приложения запросов.
И тут Остапа понесло. Понять это невозможно . Остаётся - простить.
Для PG это достаточно актуально.
Да уж.
Конец цитаты.

С одной стороны смешно и прикольно .

С другой стороны , вспоминается талантливый фильм "Такси-блюз":
- "Вань, да тебе радио хватит - во! (выше лба)".

Какой вам performance engineering и корреляционный анализ, мат.статистика и линия регрессии , вам Zabbixа воооо, с запасом, с головой, надолго хватит.
На дворе 21й век, а основная масса DBA как были ремесленниками так и остались

Вспомнилось из недавнего, на эту же тему

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