В процессе эксплуатации связки 1С:Предприятие и PostgreSQL на операционных системах семейства Windows системные администраторы часто сталкиваются с критической ситуацией: дисковое пространство на системном разделе (диск C:) стремительно исчезает. Виновником обычно оказывается папка по адресу C:\Users\postgres\AppData\Local\Temp, объем которой может достигать сотен гигабайт, значительно превышая размер самой базы данных. Разберем причины этого явления и пошагово внедрим методы решения проблемы.
Для начала проанализируем механику работы СУБД. В PostgreSQL существует понятие временных файлов (temporary files). Они создаются в тех случаях, когда оперативной памяти, выделенной под конкретную операцию (например, сложную сортировку ORDER BY, соединение таблиц Hash Join или создание индексов), не хватает для выполнения задачи целиком в RAM. В этом случае сервер «сбрасывает» промежуточные данные на диск.
Поскольку в Windows служба PostgreSQL чаще всего запускается от имени специально созданной локальной учетной записи (традиционно с именем postgres), система перенаправляет стандартные запросы на создание временных файлов в профиль этого пользователя. Если в 1С выполняются тяжелые отчеты или неоптимизированные запросы, объем таких файлов начинает расти в геометрической прогрессии.
Как показывает практика и обсуждение на форумах, одной из самых быстрых мер является изменение настроек ведения журналов. Выясним, как это влияет на ситуацию. Параметр log_temp_files управляет записью сообщений в лог о каждом удаленном временном файле, если его размер превышает заданное значение.
Проанализируем ситуацию: если параметр установлен в значение 0 (или другое положительное число), сервер записывает в лог информацию о каждом чихе системы с временными файлами. При интенсивной работе 1С это порождает гигантские текстовые логи, которые могут храниться рядом с временными данными.
Рассмотрим порядок действий для исправления:
postgresql.conf (обычно находится в папке data вашего экземпляра сервера).log_temp_files.-1, чтобы полностью отключить логирование создания временных файлов:
# Отключаем логирование временных файлов
log_temp_files = -1
Важный момент: Если вы установите log_temp_files = 0, вы будете видеть в логах абсолютно все временные файлы, что полезно для отладки, но плохо для свободного места. Значение -1 — это полное игнорирование данных событий в журнале.
Чтобы временные файлы в принципе создавались реже, нам необходимо увеличить объем оперативной памяти, доступной для одного процесса. За это отвечает параметр work_mem. Разберем, как его правильно настроить.
Если у вас установлено стандартное значение (например, 4MB или 8MB), то практически любая выборка из 1С, превышающая этот объем, заставит PostgreSQL создавать файлы в той самой папке Temp. Проанализируем ресурсы сервера и увеличим этот лимит.
Пример настройки в postgresql.conf:
# Увеличиваем память для сортировок и соединений
work_mem = 64MB
Внимание: Будьте осторожны. work_mem выделяется на каждый запрос в рамках одного соединения. Если у вас 100 активных пользователей, и каждый выполнит сложный запрос, сервер может попытаться занять 100 * 64MB = 6.4GB оперативной памяти сверх того, что потребляет shared_buffers.
Если мы не можем полностью избавиться от создания временных файлов (например, из-за специфики работы 1С с большими объемами данных), мы можем хотя бы убрать их с системного диска C:, чтобы не парализовать работу Windows. Посмотрим на алгоритм настройки табличных пространств для временных объектов.
D:\PG_Temp).
CREATE TABLESPACE fast_temp LOCATION 'D:\PG_Temp';
postgresql.conf:
temp_tablespaces = 'fast_temp'
После перезагрузки службы PostgreSQL папка AppData\Local\Temp перестанет расти, так как все временные данные уйдут на диск D:.
Чтобы ситуация с «забиванием» диска на 130 ГБ не повторилась, мы можем установить жесткий лимит. Рассмотрим параметр temp_file_limit. Он ограничивает общий объем временных файлов, который может создать один процесс. Если запрос от 1С попытается создать файл больше этого лимита, он будет прерван с ошибкой, но диск останется целым.
# Ограничиваем максимальный размер временных файлов для одного процесса (в килобайтах)
# Например, лимит 10 ГБ:
temp_file_limit = 10485760
Выясним еще одну причину: почему файлы не удаляются сами? В норме PostgreSQL удаляет временный файл сразу после закрытия сессии 1С. Однако, если происходит аварийное завершение процесса (crash), обрыв питания или некорректная остановка службы, файлы остаются «сиротами» (orphan files).
Рекомендация по очистке: Безопасно удалять содержимое папки AppData\Local\Temp можно только при остановленной службе PostgreSQL. Если удалять файлы «на горячую», это может привести к ошибкам в активных сессиях пользователей 1С.
Проанализируем ситуацию со стороны 1С. Часто причиной безумного роста временных файлов является неэффективный план запроса. Если статистика базы данных устарела, планировщик PostgreSQL может решить, что в таблице 100 строк (хотя там миллион) и выберет метод сортировки на диске вместо использования индекса.
Убедимся, что выполняются следующие действия:
ANALYZE (автоматически через autovacuum или вручную по расписанию).Подведем итог: для решения проблемы разрастания папки Temp нам необходимо действовать комплексно — ограничить логирование, предоставить серверу чуть больше оперативной памяти и, в идеале, вынести временные файлы на отдельный физический носитель.