Гипотеза о влиянии относительного соотношения ожиданий СУБД на производительность СУБД

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

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

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

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

В результате была сформирована гипотеза :

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

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

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

Таким образом, для получения надежной метрики и оповещения о возникновении инцидента производительности, необходимо получить относительные значения событий ожидания .

Предварительно , к ожиданиям не влияющим на производительность СУБД отнесены :
—Activity: Серверный процесс простаивает. Это состояние показывает, что процесс ожидает активности в основном цикле обработки.

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

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

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

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

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