Гипотеза о влиянии относительного соотношения ожиданий СУБД на производительность СУБД
О направлении исследований на ближайший месяц.
Итак, имеем — в ходе работы СУБД возникают события ожидания. Известно , что само по себе событие ожидания без конкретного уточнения типа ожидания и контекстной связи с показателем производительности не несёт никакой полезной информации. Например — самое большое количество ожиданий это тип Activity или Client. Более того, в результате наблюдений и статистического анализа установлено, что даже большое количество ожиданий , например типа IO совсем не является показателем проблем производительности .
Напомню, что производительность СУБД, в общем случае, считаем количество блоков информации обработанных за единицу времени.
Предпосылка очень простая — если СУБД не обрабатывает информацию, то СУБД ждёт освобождения или предоставления какого либо ресурса.
В результате была сформирована гипотеза:
События ожидания делятся на 2 группы: влияющие и не влияющие на производительность СУБД.
Отношение количества событий ожидания к общему количеству ожиданий, не влияющих на производительность СУБД, в ходе штатной работы СУБД будет примерно постоянное .
Рост относительного количества событий ожидания , влияющих на производительность СУБД, в случае возникновения инцидента производительности будет расти.
Таким образом для получения надежной метрики и оповещения о возникновении инцидента производительности необходимо получить относительные значения событий ожидания .
Предварительно, к ожиданиям не влияющим на производительность СУБД отнесены :
-Activity: Серверный процесс простаивает. Это состояние показывает, что процесс ожидает активности в основном цикле обработки.
-Client: Серверный процесс ожидает в сокете некоторую активность пользовательского приложения.
-Timeout: Серверный процесс ожидает истечения определённого времени.
Соответственно , остальные ожидания будем считать — влияющими на производительность СУБД.
Если гипотеза окажется верна , то можно будет резко сократить круг информации для анализа в случае деградации производительности и еще быстрее установить причину, проведя корреляционный анализ конкретных событий ожидания и запросов при выполнении которых эти ожидания возникают.
P.S. Также, как побочный результат, будет сохранено рабочее время в связи с ненужностью очередного объяснения очередному разработчику о том , что большое количество ожиданий типа »Client» в отчете pgpro_pwr не означает проблем с СУБД.
