Чистка сервера 1С: что удалять, что трогать нельзя и как автоматизировать

Диск сервера 1С заполнился, базы тормозят, а в каталоге кластера сотни гигабайт непонятных файлов. Чтобы почистить сервер 1С без последствий, нужно знать, какие каталоги безопасно чистить, а какие нельзя трогать вообще. Ниже порядок действий: от замера места до скрипта по расписанию.

Чаще всего диск съедают четыре вещи: журналы регистрации и технологический журнал, временные файлы сеансов, старые копии баз и разросшийся журнал транзакций СУБД. Начнём с того, что позволит ничего не сломать.

Что сделать до очистки: копия и замер места

Первое правило: удаляете только то, что точно знаете. Всё остальное сначала замеряете.

Резервная копия и точка отката

Перед любой чисткой сделайте копию баз и каталога кластера, если есть сомнения в каталогах. Для файловых баз достаточно скопировать каталог базы. Для клиент-серверных — выгрузка .dt или бэкап средствами СУБД.

Что занимает место

Найдите самые тяжёлые каталоги. Не гадайте, замерьте.

На Windows удобны утилиты вроде WinDirStat или TreeSize, из консоли — PowerShell:

Get-ChildItem "D:\srvinfo" -Directory | ForEach-Object {
  $s = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
  [pscustomobject]@{Папка=$_.Name; ГБ=[math]::Round($s/1GB,2)}
} | Sort-Object ГБ -Descending

На Linux хватит du:

du -h --max-depth=2 /home/usr1cv8/.1cv8 | sort -hr | head -20

Запишите цифры «до». Они понадобятся в конце, чтобы показать, сколько освободили.

Временные файлы и кэш: безопасный старт

Это самая безопасная чистка, поэтому начинайте с неё.

Временные файлы службы сервера

Рабочие процессы сервера создают временные файлы в каталоге временных файлов пользователя, под которым запущена служба. На Windows это обычно профиль USR1CV8 или системная учётная запись, на Linux — /tmp и домашний каталог usr1cv8.

Порядок такой:

1. Предупредите пользователей и завершите сеансы через консоль кластера.
2. Остановите службу сервера 1С.
3. Удалите содержимое временного каталога службы, сам каталог оставьте.
4. Запустите службу.

Кэш клиентов на терминальном сервере

Если пользователи работают через терминальный сервер , мусор копится не на сервере 1С, а на терминале. Кэш конфигураций и внешних данных лежит в профилях пользователей: AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8. Для запуска с очисткой кэша клиенту добавляют параметр /ClearCache.

Удалять содержимое этих каталогов можно только у тех, кто сейчас не в 1С. Первый запуск после чистки будет заметно дольше: клиент заново получит конфигурацию.

Логи кластера: журнал регистрации и технологический журнал

Здесь обычно и лежат сотни гигабайт. Два разных журнала чистятся по-разному.

Журнал регистрации

Журнал регистрации хранится у каждой базы отдельно. Формат бывает двух видов: набор текстовых файлов (.lgp и .lgx) или единый файл SQLite (.lgd). Удалять файлы вручную из каталога базы не стоит: можно оставить журнал в неконсистентном состоянии.

Правильный путь — через настройки самой базы:

1. Откройте базу в режиме Конфигуратора.
2. В меню Администрирование выберите Журнал регистрации.
3. Сократите журнал: задайте дату, до которой записи удаляются (кнопка сокращения журнала).
4. В параметрах журнала включите ограничение по сроку хранения, если оно есть в вашей версии платформы.

Для рабочей базы хватает хранения за 3-6 месяцев. Дольше нужно, только если этого требует регламент аудита.

Технологический журнал

Технологический журнал включается файлом logcfg.xml в каталоге conf платформы. Он создаёт самые большие объёмы данных, особенно с событиями CALL, SDBL и DBMSSQL без фильтров. Сам он ничего не удаляет, за этим следит настройка хранения.

В logcfg.xml у элемента log задайте атрибут history — срок хранения в часах:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_techlog" history="72">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

В примере хранятся только события-исключения и только трое суток. Для диагностики этого хватает. Если журнал включали «на время» и забыли, просто удалите старые подкаталоги в location: сервер создаст новые сам.

Где найти забытый журнал

Если не знаете, куда пишется технологический журнал, откройте logcfg.xml и найдите location. Если файла в conf нет, а диск растёт, ищите подкаталоги с именами вида rphost_<номер процесса>: именно так журнал раскладывает данные по процессам.

Копии баз и старые версии: политика хранения

Копии на самом сервере съедают диск незаметно. Типичная картина: ночной бэкап каждый день, а удаляет старые никто.

Что оставлять

Разумная схема хранения на примере базы, чья копия весит 20 ГБ:

Ежедневные копии за каждый день года дали бы 365 × 20 = 7 300 ГБ, то есть больше 7 ТБ. Схема с ротацией отличается в 36 раз. Копии старше нужного срока храните на другом носителе, не на диске сервера.

Старые базы и тестовые копии

Проверьте список баз в консоли кластера. Часто там живут тестовые базы бывших проектов, которыми никто не пользуется. Порядок:

1. Убедитесь, что к базе не было подключений минимум 3 месяца (смотрите журнал регистрации и сеансы).
2. Сделайте последнюю выгрузку .dt и уберите её на архивный носитель.
3. Удалите базу из кластера с удалением данных СУБД.

Если базу просто убрать из списка кластера, файлы на сервере СУБД останутся и продолжат занимать место.

Журнал транзакций СУБД

Для баз на MS SQL Server журнал транзакций (.ldf) растёт, если режим восстановления полный, а резервных копий журнала нет. Файл может весить больше самой базы. Лечится не удалением файла, а регулярным бэкапом журнала либо переводом базы в простой режим восстановления, если точка отката на момент времени вам не нужна. Для PostgreSQL аналог — рост каталога WAL при неработающей архивации.

Оптимизация кластера: что даёт чистка после чистки

Освобождённое место — половина результата. Вторая половина — скорость.

Рабочие процессы и перезапуск

Рабочие процессы rphost со временем накапливают память. Для этого в свойствах кластера есть перезапуск рабочих процессов по расписанию. Задайте интервал, например 86 400 секунд (раз в сутки), и допустимый объём памяти. Перезапуск идёт «мягко»: сеансы завершаются штатно, новые подключения уходят на свежий процесс.

Сеансы и соединения

Зависшие сеансы тоже мусор. В консоли кластера на вкладке Сеансы смотрите время последней активности. Сеансы без активности больше нескольких часов обычно принадлежат пользователям, которые закрыли окно, не выйдя из программы. Для автоматической очистки задайте в базе завершение «спящих» сеансов, а в консоли — отключение по таймауту.

Из командной строки сеансы смотрит утилита rac:

rac cluster list
rac session list --cluster=<идентификатор кластера>

Обслуживание СУБД

После чистки данных выполните регламентные операции в самой СУБД: пересоздание или реорганизацию индексов и обновление статистики. Без них запросы 1С могут идти по устаревшим планам, и после удаления данных скорость даже падает. Регламентные задания базы в 1С (Администрирование → Обслуживание) закрывают часть этой работы, но индексы и статистику на стороне MS SQL или PostgreSQL надо вести отдельным заданием.

Отдельно раз в квартал полезно запустить тестирование и исправление информационной базы. Делайте это в окно обслуживания и только после копии.

Автоматизация: скрипт и планировщик

Ручную чистку забывают через месяц. Выносите её в расписание.

Скрипт для Windows

Пример удаляет файлы старше 3 суток из каталога технологического журнала и старые бэкапы старше 14 дней. Пути замените на свои.

$techlog = "D:\1c_techlog"
$backups = "E:\1c_backups"
$log     = "D:\scripts\cleanup.log"

$before = (Get-PSDrive D).Free
Get-ChildItem $techlog -Recurse -File |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-3) } |
  Remove-Item -Force -ErrorAction SilentlyContinue
Get-ChildItem $backups -Filter *.bak -File |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } |
  Remove-Item -Force -ErrorAction SilentlyContinue
$after = (Get-PSDrive D).Free

"{0} освобождено {1} ГБ" -f (Get-Date), [math]::Round(($after-$before)/1GB,2) | Add-Content $log

Запустите сначала с параметром -WhatIf у Remove-Item: скрипт покажет, что удалил бы, но ничего не тронет.

Скрипт для Linux

#!/bin/bash
find /var/log/1c_techlog -type f -mtime +3 -delete
find /backup/1c -name "*.dt" -type f -mtime +14 -delete
find /tmp -user usr1cv8 -type f -mtime +1 -delete

Положите его в /usr/local/bin, сделайте исполняемым и добавьте задание в cron, например на 03:30 каждую ночь.

Планировщик

На Windows создайте задачу в Планировщике заданий: триггер — ежедневно ночью, действие — запуск powershell.exe с параметром -File и путём к скрипту. Запускайте от учётной записи с правами на нужные каталоги, но без прав администратора домена.

Проверка результата и контроль после чистки

После чистки сверьте цифры и убедитесь, что сервер работает.

1. Снова замерьте каталоги и сравните с записанными цифрами «до».
2. Откройте консоль кластера: все базы доступны, сеансы подключаются.
3. Войдите в базу под обычным пользователем и откройте тяжёлый отчёт. Время должно быть не хуже прежнего.
4. Проверьте журнал событий ОС и журнал регистрации на ошибки доступа к файлам.

Чтобы проблема не вернулась, настройте оповещение о месте. Порог в 20% свободного места на диске с кластером даёт запас, чтобы вмешаться до остановки баз. Для постоянного контроля подойдут системы мониторинга (Zabbix и аналоги) или простое задание в планировщике, которое шлёт письмо, когда свободно меньше порога.

Если после чистки что-то пошло не так, смотрите таблицу.

Частые вопросы