зеркало из
https://github.com/iharh/notes.git
synced 2025-11-04 07:36:08 +02:00
22 строки
2.4 KiB
Plaintext
22 строки
2.4 KiB
Plaintext
Актуальная статистика очень важна для планировщика запросов PostgreSQL.
|
|
Если статистика устаревшая, то планировщик начнет строить неоптимальные планы запросов, что в свою очередь приведет к высокому потреблению CPU.
|
|
В такой ситуации уже будет даже не важно на сколько хорошо оптимизированы ваши запросы, если статистика сильно устаревшая, то планировщик все равно начнет ошибаться.
|
|
|
|
Информацию о том когда в последний раз собиралась статистика по таблице можно получить с помощью представления pg_stat_all_tables, выполнив вот такой запрос:
|
|
|
|
SELECT schemaname, relname, last_autoanalyze, last_analyze
|
|
FROM pg_stat_all_tables
|
|
WHERE relname = 'table_name';
|
|
|
|
Колонка last_autoanalyze покажет когда в таблицу приходил AUTOVACUUM и собрал статистику,
|
|
а колонка last_analyze покажет когда статистика собиралась вручную с помощью команды ANALYZE.
|
|
|
|
Соответственно, если вы увидели, что статистика по какой-то причине по таблице не собиралась очень давно, то ее надо срочно собрать вот такой командой:
|
|
|
|
ANALYZE table_name;
|
|
|
|
Это основные (на наш взгляд) причины высокого потребления CPU PostgreSQL.
|
|
Конечно могут быть и менее очевидные причины, например неисправности дисковой подсистемы, или какие-то очень сложные вычисления на стороне приложения,
|
|
которые сильно загрузили CPU.
|
|
В любом случае расследование таких проблем нужно начинать с нахождения неоптимальных запросов, так как это наиболее частая причина всех наших бед 😉.
|