Кэш 1С на Linux: где лежит, чем забивается и как чистить без потерь

Кэш клиента 1С в Linux живёт в домашнем каталоге пользователя, под которым запущен 1cv8: папка ~/.1cv8/1C/1cv8/. Кэш сервера 1С лежит у пользователя службы, обычно usr1cv8, в /home/usr1cv8/.1cv8/ и в каталоге данных кластера reg_1541. Это две разные кухни: клиентский кэш чистят спокойно, серверный — только после остановки службы.

Способ зависит от симптома. Конфигурация открывается со старыми формами и «призраками» — чистят кэш клиента. Диск сервера растёт сам по себе — смотрят каталог кластера и временные файлы. Файловая база тормозит при нормальном диске — виноват, как правило, кэш на рабочих станциях, а не папка с базой.

Откуда берётся мусор: что 1С хранит на диске кроме базы

Платформа складывает на диск несколько видов данных, и называть всё это одним словом «кэш» не совсем честно. Полезно различать четыре группы.

• 🗂 Кэш метаданных и форм. Платформа копирует структуру конфигурации к себе, чтобы не читать её из базы при каждом запуске. Лежит рядом с клиентом.
• 📋 Списки баз и настройки. Файлы 1cv8.lst, 1cv8c.lst и пользовательские настройки окон. Это не мусор, их удалять не нужно.
• 🧾 Данные сеансов на сервере. Папки сеансовых контекстов в каталоге кластера, плюс служебные файлы реестра кластера.
• 🗑 Временные файлы. Выгрузки, промежуточные файлы печати, вложения, которые платформа распаковала для открытия. Их место — /tmp или каталог из переменной TMPDIR.

Сама база данных кэшем не является. В файловой базе это 1Cv8.1CD, в клиент-серверной — таблицы в PostgreSQL. Если вы удалите файл 1Cv8.1CD, пропадёт вся информация, а не «лишнее».

Кэш клиента: пути в домашнем каталоге

Клиент 1С (тонкий, толстый, конфигуратор) пишет данные в ~/.1cv8/1C/1cv8/. Внутри вы увидите:

• каталоги с именами-идентификаторами (GUID) — по одному на каждую базу, с которой работал пользователь. В них кэш метаданных конкретной базы;
• каталог conf с настройками платформы;
• служебные файлы со списком информационных баз.

Определить, какой GUID какой базе принадлежит, сразу не получится. Простой приём: запустите нужную базу, затем выполните ls -lt ~/.1cv8/1C/1cv8/ | head. Каталог с самым свежим временем изменения и есть ваша база.

Размер смотрим так:

du -sh ~/.1cv8/1C/1cv8/*/ | sort -h

Нормальный размер кэша одной базы — от десятков до нескольких сотен мегабайт. Если на рабочей станции их десятки по гигабайту, значит, к ней подключали много баз и никогда не чистили.

Когда чистить кэш клиента

Симптомы, при которых это помогает:

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

Если ни один из симптомов не про вас, чистить кэш «на всякий случай» бессмысленно: первый запуск после очистки будет медленным, платформа заново строит всё то, что вы удалили.

Серверный кэш: что лежит у пользователя usr1cv8

В клиент-серверном варианте кластер серверов хранит данные в каталоге, который задаётся ключом -d при запуске ragent. По умолчанию его создают в домашнем каталоге пользователя службы:

/home/usr1cv8/.1cv8/1C/1cv8/reg_1541/

Число 1541 — порт главного менеджера кластера. Если вы поднимали кластер на нестандартном порту, имя папки будет другим. Посмотрите фактический каталог по процессу:

ps -ef | grep [r]agent

В строке запуска найдите параметр -d: это и есть каталог данных.

Внутри reg_1541 лежат:

Не удаляйте реестр кластера и ничего не трогайте под работающей службой. Если ragent держит файл открытым, вы либо получите битый реестр, либо сломаете активные сеансы.

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

Рабочие процессы rphost пишут временные файлы туда, куда указывает TMPDIR в окружении службы. Если переменная не задана, это /tmp. На сервере с большим числом пользователей /tmp может оказаться на маленьком разделе и забиться за день. Решение — задать отдельный каталог на большом диске и прописать его в окружении юнита systemd.

Файловая база: кэш не в папке с базой

Частая ошибка новичка в Linux: «база файловая, значит, чистить надо рядом с 1Cv8.1CD». Рядом с файлом базы лежат:

• 1Cv8.1CD — сама база;
• каталог журнала регистрации 1Cv8Log;
• служебный файл блокировки 1Cv8.cdn, пока кто-то работает.

Кэша там нет. Кэш метаданных у файловой базы, как и у клиент-серверной, хранится на стороне каждого клиента в ~/.1cv8/. Поэтому «тормозит файловая база» проверяют так:

1. Откройте базу с другой станции или под другим пользователем. Если там быстро — виноват кэш конкретной учётки.
2. Проверьте, что база лежит на локальном диске или на быстрой сетевой шаре (NFS/SMB), а не на перегруженном томе.
3. Убедитесь, что файл 1Cv8.cdn не остался от упавшего сеанса: его присутствие при нулевом числе пользователей — признак зависшей блокировки.

Команды для анализа: что занимает место и кто это держит

Перед любой очисткой посмотрите факты. Вот набор, который хватает в 90% случаев.

# Сколько занимает каждый подкаталог кластера
du -h --max-depth=1 /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 | sort -h

# Самые большие файлы во временном каталоге
find /tmp -type f -size +100M -printf '%s %p\n' | sort -n | tail

# Файлы 1С старше 7 дней
find /tmp -type f -mtime +7 -user usr1cv8 | head

# Кто держит файл открытым
lsof +D /home/usr1cv8/.1cv8 | head

Что смотреть в результатах:

• 🔍 резкий перекос в одну папку — искать причину именно там, а не чистить всё подряд;
• 🔍 очень много мелких файлов в /tmp с владельцем usr1cv8 — рабочие процессы не завершаются корректно, чистка лишь маскирует проблему;
• 🔍 lsof показывает процесс — значит, файл используется, и удалять его нельзя.

Для списка сеансов и нагрузки пригодится утилита администрирования кластера rac, она входит в состав серверной поставки:

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

Идентификатор кластера выводит rac cluster list. Если сеансов много, а пользователи давно ушли домой, очистка кэша не поможет: сначала нужно разобраться с зависшими сеансами.

Безопасная очистка кэша: порядок действий

Очистка клиента и очистка сервера — разные процедуры. Начинайте с клиентской, она ничем не рискует.

Очистка кэша клиента

Есть два пути.

Способ 1. Ключ командной строки. Запустите клиент с ключом /ClearCache: он сбросит кэш клиент-серверных вызовов. Пример для тонкого клиента :

/opt/1cv8/x86_64/8.3.xx.xxxx/1cv8 ENTERPRISE /S "server/base" /ClearCache

Версию в пути подставьте свою: каталоги в /opt/1cv8/ именуются по номеру платформы.

Способ 2. Ручное удаление. Закройте все окна 1С, затем:

1. Проверьте, что процессов нет: pgrep -a 1cv8.
2. Сделайте копию на случай отката: cp -a ~/.1cv8 ~/.1cv8.bak.
3. Удалите каталоги баз с GUID внутри ~/.1cv8/1C/1cv8/. Файлы со списком баз и каталог conf оставьте.
4. Запустите 1С и дождитесь первой загрузки. Она займёт на минуту-две больше обычной.
5. Если всё в порядке, удалите резервную копию.

Если вы снесли и список баз — ничего страшного, базы просто придётся добавить заново. Но пользователи это не оценят, поэтому лучше оставлять.

Очистка кэша на сервере

Здесь порядок строгий.

1. Предупредите пользователей и дождитесь, когда они выйдут. Принудительно завершать сеансы можно, но потеря несохранённых данных на вашей совести.
2. Остановите службу сервера. Название юнита зависит от версии платформы: найдите его командой systemctl list-units | grep srv1cv8.
3. Убедитесь, что процессы остановлены: pgrep -a 'ragent|rphost|rmngr'. Пусто — можно идти дальше.
4. Скопируйте каталог reg_1541 целиком, если место позволяет. Реестр кластера — самая ценная вещь в нём.
5. Удалите содержимое папок snccntx* и временные файлы из TMPDIR.
6. Запустите службу и проверьте, что кластер видит базы, а пользователи заходят.

Перед чисткой серверного каталога сделайте копию реестра кластера. Восстановить список баз и администраторов из памяти сложнее, чем потратить минуту на cp.

Автоматизация обслуживания через cron

Ручная очистка каждый квартал — плохая привычка. Лучше один раз настроить регулярное удаление только временных файлов, которые точно никому не нужны, и мониторинг размера всего остального.

Пример скрипта /usr/local/bin/1c-tmp-clean.sh:

#!/bin/bash
# Удаляет временные файлы пользователя usr1cv8 старше 3 суток
TMP_DIR="${TMPDIR:-/tmp}"
find "$TMP_DIR" -xdev -type f -user usr1cv8 -mtime +3 -delete
find "$TMP_DIR" -xdev -type d -empty -user usr1cv8 -mtime +3 -delete

Пояснения:

• -xdev не даёт find выйти за пределы раздела;
• -user usr1cv8 защищает чужие файлы;
• -mtime +3 оставляет свежие файлы, которые могут использоваться прямо сейчас.

Правило для cron (crontab -e от root), запуск каждую ночь в 3:30:

30 3 * * * /usr/local/bin/1c-tmp-clean.sh

И добавьте проверку заполнения диска, чтобы узнать о проблеме до того, как всё остановится:

#!/bin/bash
USED=$(df --output=pcent /home | tail -1 | tr -dc '0-9')
[ "$USED" -gt 85 ] && echo "Диск /home заполнен на ${USED}%" | logger -t 1c-disk

Результат уйдёт в системный журнал, откуда его подхватит ваш мониторинг. Если мониторинга нет, замените logger отправкой письма или сообщения в мессенджер.

Автоматически не чистят:

• ❌ каталоги snccntx* при работающей службе;
• ❌ реестр кластера и его резервные копии;
• ❌ журнал регистрации: его хранение настраивается в самой 1С, а не find‘ом;
• ❌ клиентский кэш на рабочих станциях по расписанию: проще чистить по запросу.

Типичные ошибки при очистке

Здесь только то, чего нет в шагах выше.

• Чистят кэш под root, а платформа запущена под другим пользователем. Файлы удаляются не из тех каталогов, симптом остаётся.
• После удаления кэша ждут мгновенного ускорения. Реальный эффект — обратный на первом запуске, потом нормализация.
• Правят права на /home/usr1cv8 через chmod -R 777, «чтобы точно работало». Так служба получает проблемы безопасности и не решает исходной.
• Удаляют каталог с GUID базы на сервере, думая, что это клиентский кэш. На сервере это уже служебные данные кластера.

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