О направлении исследований на ближайший месяц.

Итак, имеем - в ходе работы СУБД возникают события ожидания. Известно, что само по себе событие ожидания без конкретного уточнения типа ожидания и контекстной связи с показателем производительности не несёт никакой полезной информации. Например — самое большое количество ожиданий это тип Activity или Client. Более того, в результате наблюдений и статистического анализа установлено, что даже большое количество ожиданий, например типа IO совсем не является показателем проблем производительности.

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

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

Далее.

События ожидания разделим можно на 2 группы: влияющие и не влияющие на производительность СУБД.

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

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

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

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

Предварительно , к ожиданиям не влияющим на производительность СУБД отнесены:

• Activity: Серверный процесс простаивает. Это состояние показывает, что процесс ожидает активности в основном цикле обработки.

• Client: Серверный процесс ожидает в сокете некоторую активность пользовательского приложения.

• Timeout: Серверный процесс ожидает истечения определённого времени.

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

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

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

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

P. S.Также, как побочный результат, будет сохранено рабочее время в связи с ненужностью очередного объяснения очередному разработчику того, что большое количество ожиданий типа «Client» в отчете pgpro_pwr не означает проблем с СУБД.