Итог исследования проблемы аномальной утилизации диска
Миграция на новую версию СУБД обещает прирост производительности или как минимум стабильность. Но что делать, если после обновления дисковая подсистема неожиданно «взбесилась», время запросов выросло в разы, а штатные отчёты не дают прямого ответа? В этой статье — хроника реального расследования, растянувшегося на несколько недель: от первых сигналов тревоги до обнаружения двух скрытых причин и выработки рекомендаций с использованием отчётов pgpro_pwr, методологии PG_EXPECTO , философской инструкция для нейросети и главного принципа - «доверяй, но проверяй». https://dzen.ru/a/afCW7TXdcRrN9Ur1
· 29.04
хроники таких расследований это ценный контент - большинство постов про базы данных теоретические, а тут реальный кейс с несколькими неделями копания. принцип "доверяй но проверяй" применительно к нейросети в диагностике это интересно - ai может дать правдоподобное объяснение которое окажется неверным. две скрытые причины после одного обновления это классика - мигрируешь одно, ломается два несвязанных места
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 29.04
Да удачно получилось. Впервые реализован многопроходный анализ. В следующей аварии будет больше интересного . Лично для меня главный вывод по итогам - наконец-то получилась инженерная методика применения отчетов pgpro_pwr для анализа производительности СУБД
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён