#Симптом и границы применимости
Автоматический VACUUM PostgreSQL убирает мёртвые версии строк и делает место пригодным для повторного использования внутри таблицы, но обычно не уменьшает размер её файла на диске. Выбор действий зависит от того, нужны ли свободные страницы или возврат места файловой системе.
#Как отличить возможные причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Свободное место внутри отношенияСтраницы освобождены для новых строк, но файл сохранён. | Размер файла прежний, повторные вставки не растят его так быстро | Не вмешиваться |
| Очистку удерживают транзакцииДолгий снимок мешает убирать старые версии строк. | Долгие xact_start или n_dead_tup | Найти причину долгих транзакций |
| Нагрузка мешает обслуживаниюАвтоочистка отстаёт от обновлений. | Растёт n_dead_tup, мало autovacuum | Проверить настройку обслуживания |
#Пошаговая диагностика и безопасное исправление
- 1. Определите, чего именно хотите добитьсяРазделите две цели: освободить место для последующих INSERT/UPDATE внутри таблицы или вернуть гигабайты файловой системе. Обычный VACUUM чаще решает первую задачу.
- 2. Измерьте размер конкретной таблицыВ psql проверьте pg_total_relation_size для нужного объекта и сохраните значение до действий. Оно включает индексы и TOAST, а pg_relation_size — только основное хранилище.
- psql, чтение; app.orders — примерSQLКомандаpsql, чтение; app.orders — пример.
SELECT pg_size_pretty(pg_relation_size('app.orders')) AS heap, pg_size_pretty(pg_total_relation_size('app.orders')) AS total;
- 3. Посмотрите статистику удаления строкИз pg_stat_user_tables прочитайте n_dead_tup, last_autovacuum и last_vacuum. Эти оценки не равны точным байтам свободного пространства, но помогают понять, выполнялась ли очистка.
- psql; только чтение статистикиSQLКомандаpsql; только чтение статистики.
SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum FROM pg_stat_user_tables WHERE schemaname='app' AND relname='orders';
- 4. Найдите мешающие транзакцииПроверьте старые xact_start, в том числе idle in transaction, и на сервере репликации — долгие снимки и слоты. Не завершайте чужие сессии без проверки источника и бизнес-операции.
- 5. Проверьте обычный VACUUM на копииЕсли очистка действительно отстаёт, на тестовой копии под владельцем таблицы выполните VACUUM (VERBOSE, ANALYZE) app.orders и сравните статистику. Операция создаёт I/O и не гарантирует уменьшение файла.SQLС осторожностьюПрава администратораpsql, только тестовая база; изменяет состояние обслуживания и статистику, не переписывает таблицу целиком.
VACUUM (VERBOSE, ANALYZE) app.orders;Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 6. Оцените цену возврата места файловой системеVACUUM FULL переписывает таблицу, требует дополнительное дисковое пространство и эксклюзивную блокировку. На почти заполненном диске он может лишь усугубить ситуацию. Рассмотрите его только в плановом обслуживании с копией и запасом места.
- 7. Проверьте повторное использование свободных страницВ тесте удалите и вставьте контролируемое число строк, наблюдая за размером таблицы. Если объём не растёт прежними темпами, VACUUM работает ожидаемо, даже когда размер самого файла не уменьшается.
- 8. Настройте наблюдение вместо ручной очистки «по расписанию»Контролируйте рост n_dead_tup, возраст долгих транзакций, длительность autovacuum и объём свободного диска. Только после подтверждения причины меняйте пороги autovacuum для конкретных таблиц.
#Как проверить, что проблема устранена
Очистка не мешает работе приложения, повторные записи используют свободное место, а требования по внешнему свободному диску оценены отдельно.
#Если исправление не помогло
Если диску срочно не хватает места, сначала проверьте другие каталоги, журналы и временные файлы; не запускайте VACUUM FULL с нулевым запасом места.