Сначала — запас времени, потом причина
Заполненный диск может остановить запись документов 1С и работу PostgreSQL. Размер базы не объясняет весь расход. Нужно установить, какой том заполняется и что растёт.
При ошибках записи не запускайте инвентаризацию. Зафиксируйте время, свободное место и ошибки; подключите ответственных за СУБД и хранилище. Сначала согласуйте стабилизацию.
Нельзя удалять вручную файлы базы и pg_wal. Не используйте pg_resetwal как «очистку», не удаляйте слоты вслепую, не отключайте архивирование ради места. VACUUM FULL на заполненном диске — не аварийное решение: переписывание требует дополнительного пространства и блокирует таблицу.
Карта расхода: не всё относится к базе
Таблицы и индексы находятся в каталоге данных и табличных пространствах; TOAST хранит крупные значения. WAL в `pg_wal` нужен для восстановления и репликации: это не обычный текстовый лог. Архив WAL — отдельные копии сегментов, иногда на другом хранилище.
Временные файлы запросов попадают в `base/pgsql_tmp` и табличные пространства. Отдельно учитывайте логи PostgreSQL, техжурнал 1С и бэкапы. Проверьте также снимки хранилища.
Безопасный первый проход
Ниже — только чтение для уполномоченного администратора. Пути заменяют на реальные. SQL ориентирован на PostgreSQL 13–18; поля и права сверяют с точной версией и сборкой для 1С. Настройки и статистика могут требовать специальных прав; не выдавайте superuser ради проверки.
```sql SELECT version(), pg_is_in_recovery(); SHOW data_directory; SHOW temp_tablespaces; SHOW log_directory;
-- Linux: каждый фактический путь проверяют отдельно df -h /реальный/путь df -i /реальный/путь ```
Проверьте все тома из карты расхода. `df -i` выявляет исчерпание inode. Относительный log_directory отсчитывается от каталога данных; логи могут уходить в системный журнал. Сверьте пути и точки монтирования.
Не начинайте с `du` по всему серверу: обход миллионов файлов создаёт I/O. SQL-функции размера тоже обращаются к файловой системе. На почти полном или перегруженном диске сначала используйте имеющийся мониторинг и короткие выборки статистики; размер известных объектов уточняйте после стабилизации, без частого опроса и полного сканирования.
База или временные файлы?
```sql SELECT datname, temp_files, temp_bytes, stats_reset FROM pg_stat_database WHERE datname = current_database();
-- После стабилизации: только выбранная база SELECT pg_size_pretty( pg_database_size(current_database())); -- Для известной таблицы, не для всех объектов сразу SELECT pg_table_size('schema.table'::regclass), pg_indexes_size('schema.table'::regclass), pg_total_relation_size('schema.table'::regclass); ```
Замените schema.table на известный объект. pg_table_size включает TOAST, но не основные индексы; pg_total_relation_size уже включает таблицу и индексы. Не суммируйте повторно.
temp_bytes — накопленные записи во временные файлы, а не их текущий размер на диске. Сравнивайте два замера с временем и stats_reset; статистика обновляется не мгновенно. Рост во время отчёта или закрытия месяца — повод исследовать запросы, а не удалять активные файлы. Увеличивать work_mem всем сеансам опасно: память расходуют отдельные операции и параллельные процессы. temp_file_limit не является общим лимитом всего сервера и не ограничивает явные временные таблицы.
Обычный VACUUM обычно освобождает место для повторного использования внутри таблицы, а не возвращает весь объём ОС. Обслуживание и изменения индексов 1С согласуют после диагностики.
Если растёт WAL: архив, слоты, реплики
```sql SHOW archive_mode; SHOW max_wal_size; SHOW wal_keep_size; SHOW max_slot_wal_keep_size; SELECT archived_count, last_archived_time, failed_count, last_failed_time, stats_reset FROM pg_stat_archiver;
-- На primary, не на сервере в recovery SELECT slot_name, slot_type, active, restart_lsn, wal_status, safe_wal_size, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS retained_bytes FROM pg_replication_slots; ```
Если архивирование включено, сравните динамику успешных и неудачных попыток, прочитайте существующие ошибки и проверьте доступность архива. Рост failed_count — сигнал, но отсутствие новых ошибок не доказывает исправность: некоторые сбои архиватора в этот счётчик не попадают. Давний last_archived_time без генерации WAL сам по себе не авария.
Слот удерживает нужную потребителю историю. active = false означает отсутствие подключения, а не ненужность слота. Разность LSN — оценка диапазона WAL от restart_lsn, не точный размер каталога. Диапазоны слотов пересекаются: складывать retained_bytes нельзя.
На primary сопоставьте слоты с потребителями и `pg_stat_replication`: state, sent_lsn, write_lsn, flush_lsn, replay_lsn. Представление показывает подключённые реплики; отсутствие строки не означает, что отключённой реплики нет. Отставание воспроизведения отличается от отставания получения WAL. Реплика без слота не обязательно удерживает WAL на primary: важны настройки хранения и архив.
`max_wal_size` — не жёсткий потолок. Архивирование, слоты, wal_keep_size и нагрузка могут привести к превышению. В PostgreSQL 13+ max_slot_wal_keep_size ограничивает удержание слотами при checkpoint; значение −1 допускает неограниченное удержание. Это не лимит всего pg_wal. Потеря сегментов может потребовать переинициализации потребителя.
wal_status = lost означает непригодность слота; unreserved — риск удаления нужного WAL. safe_wal_size показывает запас генерации WAL до риска потери слота, а не свободный диск; NULL бывает при lost и при неограниченном удержании. В PostgreSQL 18 есть idle_replication_slot_timeout: он инвалидирует подходящие неактивные слоты при checkpoint, а не безопасно «чистит всё». В более ранних версиях его нет. Любые лимиты согласуют с владельцами реплик и восстановления.
Стабилизировать — не значит устранить причину
В аварии согласуют расширение тома с проверкой нижележащего хранилища, приостановку конкретного источника нагрузки или управляемую остановку сервиса, если продолжать работу опасно. Старые обычные логи и копии выводят только по утверждённой политике, проверив назначение и сохранность нужных данных. Архив WAL нельзя считать мусором: его удаление способно разорвать цепочку восстановления.
Затем устраняют причину: сбой доставки архива, недоступного потребителя, тяжёлые запросы, неконтролируемые логи или неверный срок хранения. Перед изменениями проверяют резервную копию и восстановление на изолированном тестовом контуре. Новую копию не пишут на заполненный том. Если резервирование сейчас невозможно, риск и порядок аварийных действий отдельно согласуют; копия не заменяет план отката и проверку реплик.
Предупреждать по скорости, а не только по проценту
Контролируйте байты и inode по томам, рост базы, temp_bytes, WAL, архив и слоты. Учитывайте нагрузку и сбросы статистики. Ориентир времени до заполнения — доступное место, делённое на чистую скорость расхода. Это оценка: обмены и обслуживание дают пики.
Порог выбирают под время реакции команды, расширения диска и пиковую нагрузку. Универсального «безопасного процента» нет. Оповещение должно приходить ответственному до исчерпания рабочего резерва.
- Установлены том, источник роста и темп расхода.
- Назначены ответственный и согласованные аварийные действия.
- Проверены архив, потребители слотов и состояние реплик.
- Подтверждены восстановление, запас места и мониторинг после изменений.
Аудит серверов и сопровождение 1С
WeProf проводит [аудит серверной инфраструктуры](https://weprof.ru/it-infrastructure-audit) и сопровождает инфраструктуру 1С удалённо по РФ: связываем расход диска с заданиями, репликацией и восстановлением, готовим план исправления и контроля. Передайте версии, схему томов и обезличенные замеры, без паролей и базы.
Официальные источники PostgreSQL
Основные ссылки — на ветку 17; различия 13 и 18 отмечены отдельно. Для установленной сборки используйте её документацию.
- [Расход диска](https://www.postgresql.org/docs/17/diskusage.html)
- [Файловая структура](https://www.postgresql.org/docs/17/storage-file-layout.html)
- [Функции размера и права](https://www.postgresql.org/docs/17/functions-admin.html)
- [Статистика, архиватор и репликация](https://www.postgresql.org/docs/17/monitoring-stats.html)
- [Архивирование и восстановление](https://www.postgresql.org/docs/17/continuous-archiving.html)
- [Параметры WAL](https://www.postgresql.org/docs/17/runtime-config-wal.html)
- [Память и временные файлы](https://www.postgresql.org/docs/17/runtime-config-resource.html)
- [Логи](https://www.postgresql.org/docs/17/runtime-config-logging.html)
- [Лимиты удержания WAL: PostgreSQL 13](https://www.postgresql.org/docs/13/runtime-config-replication.html)
- [Поля слотов: PostgreSQL 17](https://www.postgresql.org/docs/17/view-pg-replication-slots.html)
- [Тайм-аут слотов: PostgreSQL 18](https://www.postgresql.org/docs/18/runtime-config-replication.html)
Рядом по теме: [проверка восстановления из бэкапа](https://weprof.ru/blog/rezervnoe-kopirovanie-1s-serverov-vosstanovlenie) · [сервер для 1С](https://weprof.ru/blog/kogda-biznesu-dejstvitelno-nuzhen-otdelnyj-server-dlya-1c).
По теме статьи
Разберём причину роста диска
Аудит серверов и сопровождение инфраструктуры 1С: диагностика, согласованный план исправления, контроль восстановления. Работаем удалённо по РФ.