Комментарии 12
@Kilorбольшое Вам спасибо!
Я давно мечтаю о подобном инструменте для мониторинга и детального анализа Query Plans.
Для анализа инцидентов производительности нужно смотреть не блокировки , а ожидания .
Ожидания и перехватываем из лога как следствие возникновения длительной блокировки.
Я извиняюсь , но ожидания это не блокировка. Например ожидания IO.
Если речь про DataFile* события ожидания, то проще говорить и о них как об ожидании доступа к заблокированному ресурсу. Не зря они в pg_locks отражаются.
Ожидание Data File Write - кто блокирует ресурс ?
Операционка. Полностью одновременно писать в один и тот же блок данных она все равно не позволит. В достаточно большой файл - да, в атомарный его блок - нет.
Я извиняюсь , но если на DBA вешать еще и анализ и мониторинг ОС - когда заниматься непосредственно вопросами СУБД ?
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме. Иначе получается "к пуговицам претензии есть?"
Но это определяется разделением обязанностей в организации. Например, ответственным за тупящий запрос можно назначить написавшего его разработчика , которого DBA научит, как его переписать эффективнее. Можно - DBA, заставляя его самостоятельно придумывать подходящие для запросов индексы. А можно - и "железячников", заставляя выделять больше аппаратных ресурсов для БД.
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме.
Очень дискуссионная и очень долгая тема . Вопросы возникают к каждому слову данного предложения.
Стандартная ситуация - запрос в psql выполняется за ms , но экранная форма приложения открывается минуты . Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". Стоит больших трудов и нервов объяснить ламерам, что СУБД в данном случае ни при чем. Если вы, чайники гоните на клиента сотни тысяч строк, то это ваши личные проблемы и ваше личное решение , не отдела администрирования баз данных. Мы, DBA, вам в данной ситуации ничем не поможем.
И таких ситуаций практически каждый день . Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA , отвлекая и не давая заниматься темами имеющими непосредственное влияние на СУБД.
Именно по этому , в свое время и начались работы по теме "Производительность СУБД". Сейчас я могу аргументированно , используя цифры , а не ощущения , доказать - "с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры". Это экономит кучу времени и нервов .
В результате - анализ и разбор инцидентов и кризисов в ходе промышленной эксплуатации ИС, проходит сильно по другому , чем буквально пару месяцев назад. Потому, что 99.999% аварий не вызваны причинами в СУБД и не требуют каких либо действий со стороны DBA.
это определяется разделением обязанностей в организации.
Именно. И поэтому данная тема в данном топике - явный оффтопик .
Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". ... Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA ...
Это существующая, но порочная практика, увы.
"с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры"
Это, правда, не менее порочная, с точки зрения бизнеса, которому важно "чтоб работало", а не "перевод стрелок".
Для исследования вопросов производительности приложения "в целом" правильно или команду специалистов собирать, или нужен "человек-оркестр"/performance engeneer, который проследит цепочку вызова от браузера через БЛ до БД и выявит конкретную проблему в конкретном месте.
Все именно так , согласен по каждому пункту. Тема не для данного топика.
К тому, же - изменить установленные даже не процессы а практики силами DBA -не реально. По крайней мере , я давно бросил попытки спасти этот мир и открыть глаза . Приходится приспосабливаться . Если судьба дала лимон - сделай лимонад. В результате скилы по performance engineering сильно растут . И это хорошо .
PostgreSQL, что в логе твоем?