Рассмотрим распространенную и крайне неприятную проблему, с которой сталкиваются системные администраторы при развертывании серверов 1С:Предприятие на операционных системах семейства Linux в связке с СУБД PostgreSQL. Ситуация выглядит следующим образом: сервер стабильно работал с определенным пулом баз данных, однако после добавления новых баз (например, перенесенных из резервных копий) рабочий процесс rphost начинает лавинообразно потреблять оперативную память. При достижении порога около 2 ГБ процесс аварийно завершается, память «сбрасывается в ноль», после чего менеджер кластера запускает новый процесс, и цикл повторяется снова и снова.
В этой статье мы подробно разберем, почему так происходит, проанализируем неочевидные взаимосвязи между СУБД PostgreSQL и платформой 1С, а также по шагам настроим систему так, чтобы локализовать и устранить эти падения.
---
Когда мы переносим базу данных из резервной копии рабочей системы на новый или тестовый сервер, вместе с конфигурацией и данными переносится и всё расписание регламентных заданий. Как только база регистрируется в кластере 1С, сервер автоматически инициализирует выполнение этих задач.
Выясним причину, почему это приводит к падению rphost:
rphost быстро исчерпывается.Решение проблемы по шагам:
Для предотвращения этой ситуации при добавлении любых новых или восстановленных из бэкапа баз данных необходимо временно блокировать выполнение регламентных заданий на уровне кластера 1С:
---
Еще один частый виновник утечки памяти в rphost сразу после подключения базы — это механизм полнотекстового поиска. Платформа 1С пытается автоматически актуализировать индекс ППД для вновь добавленной базы данных.
Если в процессе переноса или из-за сбоя структуры файлы индекса оказались повреждены, фоновое задание индексирования зацикливается, вызывая критическую ошибку обращения к памяти (Segmentation Fault). При этом в системных каталогах Linux (например, в директории /tmp) начинает плодиться огромное количество временных файлов .tmp.
Как решить проблему с полнотекстовым поиском:
Рассмотрим алгоритм очистки и пересоздания индекса ППД:
---
При использовании СУБД PostgreSQL крайне важно соблюдать методологию восстановления баз данных. Распространенной ошибкой администраторов является восстановление резервной копии поверх уже существующей структуры базы данных без ее предварительной очистки.
В PostgreSQL, в отличие от MS SQL Server, простое наложение бэкапа поверх «живой» базы не перезаписывает таблицы полностью, а пытается объединить данные. Это приводит к рассинхронизации системных каталогов СУБД, дублированию внутренних идентификаторов (OID) и разрушению индексов. При попытке 1С прочитать поврежденные метаданные рабочий процесс rphost моментально падает по ошибке нарушения прав доступа к памяти.
Правильная методика восстановления баз в PostgreSQL:
Разберем, как правильно выполнять развертывание бэкапа:
DROP DATABASE) старую базу данных.ru_RU.utf8).pg_restore, обязательно используем ключи очистки и безопасного удаления объектов. Посмотрим на пример команды:
pg_restore --host="localhost" --port="5432" --username="postgres" --dbname="target_db" --clean --if-exists --verbose "/path/to/backup.backup"
Использование флагов --clean и --if-exists гарантирует, что перед созданием каждого объекта СУБД попытается удалить его старую копию, что исключает наложение структуры данных.
---
Падение процесса ровно на отметке около 2 ГБ часто указывает не на физическую нехватку оперативной памяти на сервере, а на срабатывание встроенных предохранительных механизмов самого кластера 1С.
В свойствах рабочего сервера 1С есть параметры, ограничивающие аппетиты процессов:
rphost.rmngr.Если для этих параметров заданы некорректные или слишком жесткие ограничения, то при интенсивной нагрузке (которая всегда возникает при первом запуске восстановленных баз) процесс принудительно убивается системой контроля кластера.
Как исправить настройки лимитов:
rphost) и настраивать перезапуск процессов по расписанию в нерабочее время.---
Сервер 1С на Linux работает от имени системного пользователя (обычно это usr1cv8). При операциях добавления, удаления и пересоздания баз данных через консольные команды в локальном кэше сервера могут оставаться битые ссылки и файлы блокировок.
Если у пользователя usr1cv8 нет прав на запись в системные каталоги временных файлов или если кэш сеансов поврежден, рабочий процесс будет аварийно завершаться при обращении к диску.
Пошаговая очистка кэша и проверка прав:
systemctl stop srv1cv83
/home/usr1cv8/.1cv8 или /var/1C/v8.3) и временные папки. Убедимся, что владельцем является пользователь usr1cv8:
chown -R usr1cv8:grp1cv8 /var/1C/v8.3
reg_1541), исключая конфигурационные файлы.
systemctl start srv1cv83
---
Если после выполнения всех рекомендаций процесс rphost продолжает падать, проанализируем системные логи операционной системы Linux. Для этого откроем терминал и проверим лог системных сообщений на наличие критических ошибок:
grep -i -E 'oom|segfault|sigsegv' /var/log/messages
Или на дистрибутивах Ubuntu/Debian:
grep -i -E 'oom|segfault|sigsegv' /var/log/syslog
Если в логах обнаруживается запись вида kernel: [XXXXXX] rphost[XXXX]: segfault at ... ip ... sp ... error 4 in ..., это подтверждает ошибку Segmentation Fault (нарушение сегментации памяти). В этом случае наиболее вероятной причиной является использование несовместимых версий платформы 1С и PostgreSQL, либо повреждение конфигурации базы данных, требующее тестирования и исправления (ТИИ) метаданных.