Комментарии 2
Спасибо за познавательную статью Ринат. Не очень понятен момент, как Вы смогли сформулировать гипотезу об обратной корреляции. Не могли бы раскрыть ход мысли, как от отсутствия корреляции между событием ожидания и деградацией БД , Вы пришли к тому, что на самом то деле, есть отрицательная корреляция.
Спасибо за конструктивный комментарий.
как Вы смогли сформулировать гипотезу об обратной корреляции
Основания для данной гипотезы очень простые и базируются на следующих аксиомах:
1) События ожидания при работе СУБД есть всегда .
2) Количество событий ожидания не означает проблемы в СУБД .
Первая аксиома очень проста и вряд ли вызывает какие либо возражения. Самая интересная вторая аксиома.
В ходе реальной аварии(снижения производительности замеченной пользователями) ИС снимаются статистические данные о количестве событий ожидания . Затем рассчитывается коэффициент корреляции (используя функцию PostgreSQL )
corr(Ydouble precision,Xdouble precision) →double precisionВычисляет коэффициент корреляции.
Y - выборка метрики производительности , X - выборка количества ожидания данного типа .
И вот в ходе наблюдений получены, например, такие данные:
Корреляция же между ожиданиями и производительностью выглядит так :
Данная ситуация "отсутствие корреляции по долгим ожиданиям и наличие корреляции по не долгим" - повторяется регулярно в ходе наблюдений и после анализа собранных данных во время инцидентов производительности СУБД .
Поэтому и была выдвинута гипотеза - наибольшее влияние на деградацию производительности оказывают события ожидания имеющие отрицательную корреляцию с метрикой производительности СУБД.
Реальный вывод из гипотезы - во время аварии не надо искать ожидания попадающие в отчеты типа Top Wait Events, нужно искать события оказывающие влияние на изменение производительности.
В настоящее время идут эксперименты , сбор и анализ данных .
Корреляционный анализ для решения инцидентов производительности СУБД