← На главную

Переход с 32-разрядного сервера «1С:Предприятие» на 64-разрядную версию — частый и логичный шаг при росте информационной базы и количества одновременно работающих пользователей. Главная цель такой миграции — устранить жесткое архитектурное ограничение в 2–4 ГБ оперативной памяти на рабочий процесс rphost, приводящее к аварийным завершениям при выполнении тяжелых отчетов или выгрузок. Рассмотрим подробно, действительно ли 64-битный сервер работает стабильно «из коробки», с какими скрытыми нюансами интеграции можно столкнуться и какие параметры кластера необходимо скорректировать для надежной эксплуатации.

Особенности работы сервера 1С x64 «из коробки» и управление процессами

В базовом сценарии 64-разрядный сервер платформы действительно готов к работе сразу после установки без обязательного ручного тюнинга. Однако администраторам, привыкшим к особенностям платформы x86, необходимо пересмотреть подход к организации рабочих процессов.

Разберем ключевые архитектурные изменения:

1. Отказ от ручного дробления рабочих процессов: В 32-битной архитектуре администраторам приходилось вручную добавлять несколько процессов rphost, чтобы распределить пользователей и избежать исчерпания адресного пространства процесса. В 64-битной версии один процесс может адресовать терабайты оперативной памяти. Создавать лишние процессы вручную больше не требуется — рекомендуется доверить балансировку автоматическим механизмам кластера либо ограничиться одним-двумя процессами.
2. Повышенное потребление оперативной памяти: Сервер x64 для размещения тех же структур данных потребляет на 20–30% больше RAM по сравнению с x86 из-за увеличенного размера указателей адресов памяти. Этот фактор обязательно учитываем при планировании аппаратных мощностей хоста.

Совместимость с внешними компонентами и COM-соединениями

Основная сложность, с которой сталкиваются при миграции — невозможность загрузки 32-битных библиотек (DLL) непосредственно в адресное пространство 64-разрядного процесса rphost. Выясним причину: 64-разрядный исполняемый файл физически не может загрузить 32-битную DLL напрямую.

Проанализируем возможные варианты решения этой проблемы:

1. Обновление библиотек до 64 бит: Если в конфигурации на сервере используются внешние компоненты систем защиты, интеграции с торговым оборудованием или драйверы для разбора файлов (например, Microsoft Access Database Engine для Excel), их необходимо обновить до x64 версий.
2. Изоляция 32-битных COM через COM+ (dllhost.exe): Если разработчики внешней компоненты не предоставили 64-битную сборку, библиотеку можно вынести в отдельное приложение Служб компонентов Windows (dcomcnfg). В этом случае библиотека будет запущена в системном 32-разрядном суррогатном процессе dllhost.exe, а 64-битный процесс rphost свяжется с ней посредством межпроцессного взаимодействия (DCOM/маршалинг).

Параметры кластера для контроля утечек памяти

Поскольку 64-битный рабочий процесс не ограничен лимитом в 4 ГБ, некорректно написанный код конфигурации или ресурсоемкие запросы могут привести к неконтролируемому разрастанию процесса вплоть до полного исчерпания всей физической памяти сервера. Это может парализовать операционную систему. Чтобы этого избежать, настроим встроенные параметры защиты кластера в консоли администрирования 1С.

Посмотрим на параметры, которые необходимо задать для свойств кластера:

1. «Допустимый объем памяти»: Задает порог виртуальной памяти в байтах. Если рабочий процесс превышает это значение, кластер помечает его как неактивный, создает новый процесс для входящих подключений, а старый завершает штатно после завершения текущих клиентских вызовов.
2. «Интервал превышения допустимого объема памяти»: Время в секундах, в течение которого процессу разрешено находиться за пределами лимита памяти до принудительного перезапуска.
3. «Период перезапуска»: Рекомендуется установить регулярный перезапуск рабочих процессов (например, 86400 секунд, то есть раз в сутки). Это помогает бороться с фрагментацией памяти и очищать неосвобожденные ресурсы.

Взаимодействие с СУБД на одном физическом сервере

Если сервер «1С:Предприятия» и сервер баз данных (MS SQL Server или PostgreSQL) установлены на одном экземпляре операционной системы, возникает риск взаимного вытеснения. По умолчанию СУБД стремится занять под свой кэш всю доступную оперативную память, а 64-разрядный rphost делает то же самое при пиковых нагрузках. Это неминуемо приведет к уходу процессов в файл подкачки (swapping) и катастрофическому падению производительности.

Разберем обязательные действия по настройке совместного хостинга:

1. Ограничение памяти СУБД: В свойствах экземпляра MS SQL Server жестко зафиксируем параметр max server memory, оставив достаточный запас оперативной памяти под работу процессов 1С и нужды операционной системы.
2. Контроль запущенных служб: При установке новой платформы служба 1С регистрируется по пути C:\Program Files\1cv8\... (в отличие от старой службы x86 в C:\Program Files (x86)\...). Старую службу 32-разрядного сервера необходимо отключить, чтобы избежать конфликта сетевых портов кластера.
3. Права сервисной учетной записи: Учетная запись операционной системы (по умолчанию usr1cv8) должна иметь полные права на каталог данных кластера srvinfo, право на вход в качестве службы (Log on as a service) и доступ к системным временным каталогам.