|
|
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
Есть большое подозрение, что навернулась одна из таблиц или её часть, или данные каких-то системных таблиц, относящиеся к ней, или какие-то из индексов по ней. В чём это выражается: некоторые запросы с фильтрацией по индексированным колонкам виснут намертво. Причём не только Select, но и explain. Если ли в самом Postgresql какие-то средства мониторинга таких проблем? Или может это можно увидеть по каким то системным таблицам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 11:34 |
|
||
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
Kr_Yury Есть большое подозрение, что навернулась одна из таблиц или её часть, или данные каких-то системных таблиц, относящиеся к ней, или какие-то из индексов по ней. В чём это выражается: некоторые запросы с фильтрацией по индексированным колонкам виснут намертво. Причём не только Select, но и explain. Если ли в самом Postgresql какие-то средства мониторинга таких проблем? Или может это можно увидеть по каким то системным таблицам? hmm сделайте сначала vacuum analyze по таблице потом если проблема не уйдёт - есть штатное расширение amcheck для проверки индексов. PS: вы случайно не удаляли много из этой таблицы последнее время? Таблица то большая? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 13:32 |
|
||
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
explain без analyze зависает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 13:39 |
|
||
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
Guzya explain без analyze зависает? В некоторых особых случаях если 1)таблица большая 2)из неё много удаляли очень последнее время (из начала или конца таблицы) 3)autovacuum по ней не отработал до сих пор (или сломан) 4)диски медленные (механика или сетевой storage) explain может не то чтобы зависнуть но задуматься очень на долго (десятки минут) если же реально зависает - то это уже gdb/perf/strace в руки и низкоуровневая отладка проблемы. (ну и amcheck полезно прогнать да) -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 13:43 |
|
||
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk Guzya explain без analyze зависает? В некоторых особых случаях если 1)таблица большая 2)из неё много удаляли очень последнее время (из начала или конца таблицы) 3)autovacuum по ней не отработал до сих пор (или сломан) 4)диски медленные (механика или сетевой storage) explain может не то чтобы зависнуть но задуматься очень на долго (десятки минут) если же реально зависает - то это уже gdb/perf/strace в руки и низкоуровневая отладка проблемы. (ну и amcheck полезно прогнать да) -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru А может объяснить почему? Как я считаю, explain(без параметров) берет имеющуюся статистику и на основе ее "считает" планы. Т.е. ни какие "движущиеся" части не трогаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 13:53 |
|
||
|
Мониторинг целостности БД
|
|||
|---|---|---|---|
|
#18+
Guzya Maxim Boguk пропущено... В некоторых особых случаях если 1)таблица большая 2)из неё много удаляли очень последнее время (из начала или конца таблицы) 3)autovacuum по ней не отработал до сих пор (или сломан) 4)диски медленные (механика или сетевой storage) explain может не то чтобы зависнуть но задуматься очень на долго (десятки минут) если же реально зависает - то это уже gdb/perf/strace в руки и низкоуровневая отладка проблемы. (ну и amcheck полезно прогнать да) -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru А может объяснить почему? Как я считаю, explain(без параметров) берет имеющуюся статистику и на основе ее "считает" планы. Т.е. ни какие "движущиеся" части не трогаются. Увы всё сложнее... для части индексированных полей и некоторых планов планировщик использует get_actual_variable_range() функцию для просмотра АКТУАЛЬНЫХ граничных значений поля в таблице (min/max). Что обычно по индексу быстро но в некоторых ситуациях типа вышеописанной мною - оказывается НЕбыстро (потому что по индексу находим значения а они уже удалены и так можно очень долго идти если (auto)vacuum по таблице с момента удаления не прошёл). Т.е. в некоторых ситуациях планировщик в реальную таблицу ходит а не только в стату. Поиск по https://www.postgresql.org/search/?m=1&q=get_actual_variable_range&l=&d=-1&s=d даёт много инфы на подумать. У меня и у самого downtimes были пару раз в таких ситуациях (и помогает только удаление по частям и регулярные vacuums в процессе если что то подобное происходит). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2021, 14:26 |
|
||
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1993766]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
14ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 199ms |
| 0 / 0 |
