При администрировании связки 1С:Предприятие и PostgreSQL системные администраторы часто сталкиваются с парадоксальной ситуацией: физический размер базы данных составляет несколько десятков гигабайт (удобно через анализ структуры и объема данных в СУБД), в то время как счетчики временных файлов показывают сотни гигабайт. Еще больше вопросов возникает в процессе восстановления базы из бэкапа, когда процедура внезапно прерывается из-за нехватки свободного места на диске, объем которого значительно превышает размер самой базы. Разберем детально, откуда берутся эти цифры, как ими управлять и что на самом деле происходит в недрах СУБД.
Первым делом проанализируем ситуацию, когда в панели мониторинга pgAdmin мы видим пугающие цифры в колонке Temporary Files (или temp_bytes). Важно понимать природу этих данных. В большинстве случаев значение, которое вы видите, — это кумулятивный показатель. Это означает, что PostgreSQL суммирует объем всех временных файлов, которые когда-либо создавались в этой базе с момента её создания или последнего сброса статистики.
Рассмотрим пример: если за месяц работы база создала и удалила 100 временных файлов по 1 Гб каждый, счетчик будет показывать 100 Гб, даже если в данный момент на диске нет ни одного временного файла. Чтобы убедиться в этом и "обнулить" показания для получения актуальной картины, выполним следующую команду в консоли запросов:
SELECT pg_stat_reset();
Эта команда обнуляет статистику текущей базы данных. Если после её выполнения счетчик сбросился в ноль и не начал стремительно расти, значит, проблема была лишь в накопленной статистике, а не в реальном дефиците дискового пространства.
Теперь разберем более сложную ситуацию: почему при восстановлении базы размером 35 Гб требуется еще 100 Гб свободного места — решить проблему поможет инструмент сжатия и обрезки баз 1С. Проанализируем стандартный процесс восстановления через утилиту pg_restore. В отличие от бинарного бэкапа (как в MS SQL), pg_dump создает набор инструкций. При восстановлении происходит выполнение этих инструкций, что влечет за собой несколько ресурсоемких процессов.
1. Перестроение индексов. В файле бэкапа хранятся только "сырые" данные таблиц и команды на создание индексов. Во время восстановления PostgreSQL сначала загружает данные, а затем начинает строить индексы с нуля. Для сортировки данных при создании индексов СУБД создает временные файлы на диске. Если в базе много больших таблиц (что типично для 1С), объем этих временных файлов в процессе восстановления может в несколько раз превышать объем самих данных.
2. Журналы транзакций (WAL-логи). Каждая запись данных при восстановлении фиксируется в логах транзакций (папка pg_wal). Если настройки СУБД позволяют хранить большой объем логов перед их удалением, папка pg_wal может мгновенно разрастись до десятков гигабайт. Посмотрим на параметры max_wal_size и min_wal_size — именно они определяют аппетиты системы к дисковому пространству под логи.
3. Временные таблицы 1С. Платформа 1С активно использует временные таблицы СУБД (начинаются с tt). При массовых операциях во время восстановления или последующего обновления конфигурации эти таблицы могут занимать значительное место в папке pgsql_tmp внутри каталога данных PostgreSQL.
Чтобы минимизировать использование временных файлов на диске и ускорить процесс развертывания бэкапа, выполним тюнинг параметров PostgreSQL — для этого есть мониторинг производительности 1С и СУБД. Рассмотрим основные настройки, которые помогут нам в этом:
maintenance_work_mem определяет объем оперативной памяти, используемой для операций по созданию индексов и выполнению VACUUM. Если мы установим здесь достаточно большое значение (например, от 2 до 4 Гб), PostgreSQL сможет выполнять сортировку данных для индексов в памяти, не сбрасывая промежуточные результаты в медленные временные файлы на диске.max_wal_size. Слишком маленькое значение заставит систему часто делать контрольные точки (checkpoints), что замедлит восстановление. Слишком большое — заполнит диск логами. Для процесса восстановления оптимально установить значение около 4-8 Гб, чтобы сбалансировать скорость и место.autovacuum, чтобы он не конкурировал за ресурсы с процессом восстановления.Проанализируем пример команды для восстановления, которую использовал автор темы:
"C:\Program Files\PostgreSQL\11.5-7.1C\bin\pg_restore.exe" -c -h localhost -U postgres -d 123 "F:\backup\Backup_123\123_2021-02-20_14-44-33.backup"
Рекомендуем добавить параметр параллельности -j (если бэкап сделан в формате "directory" или "custom"), чтобы задействовать несколько ядер процессора. Однако помните, что каждый поток восстановления будет потреблять свою порцию maintenance_work_mem.
Важно не путать временные файлы, о которых сообщает PostgreSQL, и временные файлы самого сервера 1С. Рассмотрим их различия подробнее:
Временные файлы 1С обычно располагаются в профиле пользователя, под которым запущена служба сервера 1С (каталог AppData\Local\Temp или srvinfo). Они содержат кэш конфигурации, сеансовые данные и результаты пользовательских запросов. Эти файлы не попадают в бэкап PostgreSQL и не влияют на его размер. Очистить их можно простым удалением папок с идентификаторами баз при остановленной службе 1C:Enterprise Server.
Временные файлы PostgreSQL находятся строго внутри каталога данных (PGDATA) в подпапках pgsql_tmp. Они создаются самой СУБД для выполнения сложных SQL-запросов и построения индексов. Безопасно удалить их вручную можно только при полностью остановленной службе PostgreSQL. При работающей службе PostgreSQL сам удаляет эти файлы по завершении сессий, которые их породили — для управления сеансами подойдёт обработка завершения сеансов пользователей. Если файлы "зависли", это признак незавершенных транзакций или аварийного завершения процессов.
Проанализировав ситуацию, мы пришли к выводу, что "100 Гб временных файлов" в большинстве случаев являются лишь числом в статистике. Однако реальная потребность в дисковом пространстве при восстановлении обусловлена архитектурой PostgreSQL. Для успешной работы выполним следующие шаги:
SELECT pg_stat_reset(), чтобы видеть реальную картину использования ресурсов.maintenance_work_mem в файле postgresql.conf.pgsql_tmp, оставшихся после сбоев (проверяется при выключенной СУБД).Таким образом, понимание внутренних механизмов работы PostgreSQL позволяет избежать паники при виде больших цифр в мониторинге и правильно подготовить инфраструктуру к обслуживанию баз 1С:Предприятие.