Какое количество переключений контекста (показатель cs , утилиты vmstat) является критичным для СУБД PostgreSQL при ресурсах CPU=2 и RAM=2GB при экспоненциальном росте нагрузки с 5 до 115 сессий pgbench ?
Цитата из ответа:
График TPS: Сначала растет линейно, затем выходит на плато, а после пика (~20-30 сессий) резко падает вниз.
График cs: Сначала пологий, затем его рост резко ускоряется, и он уходит в вертикальный взлет как раз в точке, где TPS начинает падать.
Эти два графика зеркальны друг другу.
Реальные данные эксперимента:
Итог
Реальные данные полностью противоположны выводам нейросети.
Информации много, важно правильно интерпретировать результаты.
Предисловие
PostgreSQL представляет собой мощную систему управления базами данных, обладающую множеством инструментов мониторинга производительности. Однако стоит отметить одну важную деталь: несмотря на обширные возможности по сбору статистики, PostgreSQL не имеет встроенного механизма явного определения типа ожидания CPU, которое возникает во время выполнения запросов.
Ожидания – это ситуации(события), когда выполнение запроса временно блокируется или замедляется из-за внешних факторов, таких как доступ к дисковым ресурсам (IO wait) или получение блокировки (LOCK wait) и т.п. Важность отслеживания типов ожиданий заключается в том, что они позволяют точно идентифицировать узкие места системы и оптимизировать производительность базы данных.
В отличие от некоторых других систем управления базами данных (например, Microsoft SQL Server или Oracle Database), где есть четко выделенные типы ожиданий, такие как «CPU», «I/O» и «Locking», PostgreSQL изначально не поддерживает такого рода детализацию через стандартные инструменты отчетности.
Почему важна классификация ожиданий?
Правильная идентификация типа ожидания помогает более эффективно диагностировать проблемы производительности. Например, если большинство времени тратится на операции ввода-вывода («I/O»), то внимание следует уделить улучшению файловой подсистемы или увеличению объема оперативной памяти. Если же основной причиной задержки является процессорное время («CPU»), то анализ может привести к необходимости оптимизации самих запросов или улучшения индексации таблиц.
Однако, поскольку PostgreSQL не разделяет эти категории явно, важно понимать, какие именно данные отражают состояние использования ресурсов.
Интерпретация показателя "On CPU" в отчётах pgpro_pwr
Отчёт pgpro_pwr предлагает показатель под названием «On CPU». Этот параметр часто интерпретируют неверно, полагая, что он отражает непосредственное использование центрального процессора сервером.
На самом деле значение «On CPU» указывает лишь на тот факт, что запрос активно выполняется и использует ресурсы сервера без видимых задержек со стороны I/O операций или блокировок. Другими словами, данный показатель сигнализирует об отсутствии очевидныхпричин замедления выполнения запроса за пределами непосредственно самой обработки SQL-команды.
Таким образом, необходимо помнить, что ожидание «On CPU» не говорит напрямую о том, насколько интенсивно используется центральный процессор в момент выполнения конкретного запроса. Вместо этого оно информирует нас о том, что другие возможные причины простоя (ожидания ввода/вывода, получения блокировок и т.п.) отсутствуют, а сама обработка идёт своим чередом.
Как правильно анализировать нагрузку на CPU?
Для того чтобы понять реальную нагрузку на процессор, вызванную выполнением запросов, рекомендуется использовать сторонние средства диагностики операционной системы, такие как утилиты `top`, `htop` или аналогичные решения. Эти инструменты предоставляют точные показатели загрузки каждого ядра процессора и дают возможность сопоставлять статистику процессов с результатами работы PostgreSQL.
Кроме того, дополнительный/косвенный мониторинг запросов можно организовать путём периодического сбора и анализа значений столбца total_time таблицы pg_stat_statements , которая содержит информацию о суммарном времени выполнения всех вызовов различных SQL-операторов.
Сравнивая изменения этих показателей между разными промежутками времени, можно сделать предварительные выводы о нагрузке на процессор.
Итог
В завершении следует подчеркнуть, что отсутствие чёткого разделения типов ожиданий в PostgreSQL требует внимательного подхода к диагностике проблем производительности.
Три слона на черепахе смогут удержать СУБД в океане бурь и штормов.
Основа и фундамент PG_HAZEL
Методы и инструменты статистического анализа данных о СУБД и инфраструктуре .
PG_HAZEL : Первая часть
Методы оценки и анализа производительности СУБД.
PG_HAZEL : Вторая часть
Методология корреляционного анализа ожиданий СУБД.
PG_HAZEL : Третья часть
Инструменты сбора и анализа показателей производительности инфраструктуры (сервера СУБД) с точки зрения операционной системы и анализ связи и влияния инфраструктуры на производительность СУБД .
Открытая система управления базами данных занимает первое место по популярности, уровню удовлетворенности, а еще — лидирует среди систем, с которыми хотят работать респонденты.
➡️ Главное про открытую СУБД по итогам исследования Stack Overflow рассказали в карточках.
