Ситуация, когда небольшая по объему база данных 1С (например, файловая копия весит всего пару гигабайт) при переходе в клиент-серверный режим на PostgreSQL начинает быстро поглощать десятки гигабайт дискового пространства на системном накопителе, встречается достаточно часто. Проанализируем основные причины этой проблемы и разберем по шагам, как локализовать утечку места и навести порядок на сервере.
Прежде чем вручную очищать каталоги, выясним точную структуру распределения занятого пространства. Для этого запустим специализированную утилиту-анализатор диска с правами администратора.
Администратор (это критически важно, чтобы утилита смогла прочитать закрытые системные каталоги и профили всех терминальных пользователей).Как правило, виновниками оказываются четыре основные категории: файлы журнала регистрации 1С, журналы и раздувание СУБД PostgreSQL, временные файлы терминальных сессий пользователей и системные отчеты Windows.
Одной из наиболее частых причин взрывного роста размера каталогов 1С является журнал регистрации. При активной работе пользователей и включенной детальной фиксации событий журнал разрастается до десятков гигабайт.
srvinfo проверим размер подкаталогов баз. Если журнал переведен в новый формат SQLite, обратим внимание на файл 1Cv8.lgd и сопутствующий файл упреждающей записи 1Cv8.lgd-wal. При высокой нагрузке или блокировках файл wal может не успевать сжиматься.Сервер баз данных PostgreSQL может занимать избыточное пространство по нескольким независимым причинам. Рассмотрим подробнее каждую из них.
pg_wal (или pg_xlog в старых версиях). Если в конфигурационном файле postgresql.conf включен параметр archive_mode = on, но архивация archive_command падает с ошибкой, файлы WAL не удаляются и непрерывно заполняют диск. Убедимся в корректности команды архивации либо отключим ее, если резервное копирование выполняется иным способом.log (или pg_log). Если активированы параметры детальной трассировки, например log_statement = all или задан низкий порог log_min_duration_statement, СУБД способна генерировать гигабайты логов за несколько дней. Настроим параметры ротации log_rotation_age и log_rotation_size.autovacuum не справляется с очисткой «мертвых» строк (dead tuples) из-за зависших пользовательских транзакций, реальный размер таблиц на диске может многократно превышать полезный объем данных. В технологическое окно выполним регламентное обслуживание базы с помощью команды VACUUM FULL или переиндексацию REINDEX.При терминальной работе нескольких пользователей на одном сервере накапливаются временные файлы сессий и кэш метаданных.
AppData\Local\Temp в профиле каждого пользователя, а также в системном каталоге C:\Windows\Temp при аварийных завершениях сеансов скапливаются файлы с маской v8_*.tmp. Удалим устаревшие временные файлы.AppData\Local\1C\1Cv8 и AppData\Roaming\1C\1Cv8 у каждого пользователя. Очистим каталоги с буквенно-цифровыми GUID-именами.logcfg.xml в папке conf. Если технологический журнал включен, он непрерывно сохраняет события на диск. Также проверим каталоги на наличие файлов аварийных дампов *.dmp, создаваемых процессами rphost или ragent при сбоях.1Cv8FTxt могут разрастаться при интенсивном изменении данных. Выполним регламентное слияние или очистку индекса полнотекстового поиска через пользовательский интерфейс 1С:УНФ в разделе администрирования.Если каталоги 1С и PostgreSQL не показывают аномального размера, проверим системные службы операционной системы.
C:\Windows\Logs\CBS процесс Makecab.exe может непрерывно создавать временные архивы cab_* в каталоге C:\Windows\Temp, забивая все свободное пространство. Очистим эту папку и удалим устаревшие объемные логи CBS.System Volume Information. Скорректируем максимальный объем, выделяемый под защиту системы.Чтобы избежать повторения проблемы в будущем, реализуем следующие меры:
Temp при завершении терминальных сессий.