Стоит ли размещать сервер 1С и СУБД MS SQL на одной машине и как решить проблему нехватки памяти?

Вопрос оптимального размещения кластера серверов 1С:Предприятия и СУБД (в частности, Microsoft SQL Server) является классической дилеммой системного администрирования. Нередко возникающие ошибки производительности и нехватки ресурсов ошибочно связывают исключительно с топологией серверов. Разберем подробно плюсы и минусы совместного и раздельного размещения служб, влияние виртуализации, а также выясним реальную причину ошибки «Недостаточно памяти для записи файла формата Base64».

Совместное размещение 1С и MS SQL на одном сервере

Рассмотрим вариант, когда служба ragent (кластер 1С) и экземпляр СУБД функционируют в рамках одной операционной системы. Это решение имеет ключевое преимущество для платформы 1С — максимальную скорость межузлового взаимодействия.

Платформа 1С генерирует огромное количество мелких последовательных SQL-запросов. При размещении служб на одном хосте обмен данными происходит через локальный протокол оперативной памяти Shared Memory. Это полностью исключает накладные расходы сетевого стека: трафик не проходит через сетевые адаптеры, виртуальные коммутаторы и сетевые драйверы.

Однако совместное размещение требует строгого контроля системных ресурсов. Для стабильной работы настроим следующие параметры:

1. Ограничение максимальной памяти СУБД: в свойствах экземпляра MS SQL Server обязательно зададим параметр max server memory. Если этого не сделать, SQL Server займет всю доступную оперативную память хоста, вызвав нехватку памяти для рабочих процессов 1С (rphost) и сброс их страниц в файл подкачки.
2. Резервирование памяти для 1С и ОС: оставим под нужды операционной системы и кластера серверов 1С не менее 20–30% физической памяти сервера.
3. Разделение дисковой подсистемы: распределим дисковые операции по разным физическим накопителям или RAID-массивам. Файлы баз данных (.mdf), журналы транзакций (.ldf), системные базы tempdb и рабочие каталоги 1С (журналы регистрации и временные файлы) не должны конкурировать за одну дисковую очередь.

Разнесение служб по разным серверам и виртуализация

Проанализируем сценарий с разделением служб на разные физические серверы или виртуальные машины. Данный подход традиционно применяется в крупных инфраструктурах для горизонтального масштабирования и построения отказоустойчивых кластеров (например, с технологиями Always On).

Однако разделение на две виртуальные машины в пределах одного физического сервера часто приводит к серьезной деградации производительности:

1. Сетевые задержки (Latency): даже внутри одного гипервизора пакеты TCP/IP проходят стек виртуализации. Дополнительная задержка в 0.5–1 мс способна замедлить выполнение тяжелых транзакций и групповых проводок в несколько раз по сравнению с обменом через Shared Memory.
2. Конкуренция за процессорное время (CPU Co-scheduling): когда две нагруженные виртуальные машины делят одни и те же физические ядра, гипервизор тратит ресурсы на переключение контекстов, увеличивая показатель CPU Ready Time.
3. Проблемы NUMA-архитектуры: неверная топология виртуальных процессоров может приводить к обращению к удаленным узлам памяти через межпроцессорную шину, что существенно снижает скорость работы с ОЗУ.

Если разделение на виртуальные машины необходимо по регламентам инфраструктуры, обеспечим статическое выделение памяти со 100% резервированием (исключая механизм Ballooning) и жестко зафиксируем топологию vNUMA в соответствии с физическими сокетами хоста.

Причины и устранение ошибки «Недостаточно памяти для записи файла формата Base64»

Выясним причину ошибки нехватки памяти при записи Base64. Данная ошибка не связана напрямую со схемой расположения серверов 1С и MS SQL. Она возникает на уровне сервера 1С или клиентского приложения при сериализации тяжелых двоичных данных в XML-поток (например, при вызове ЗаписатьXML с использованием ЗаписьFastInfoset).

Чаще всего сбой происходит в механизмах версионирования объектов, обмена данными (РИБ, EnterpriseData) или при работе с присоединенными файлами и реквизитами типа ХранилищеЗначений.

Разберем по шагам, как локализовать и устранить данную проблему:

1. Проверка разрядности сервера 1С: если служба сервера 1С работает в 32-разрядном режиме, рабочий процесс rphost ограничен адресным пространством в 2–3 ГБ. При попытке выделить непрерывный блок памяти под крупную строку Base64 процесс аварийно завершает операцию. Решением является перевод кластера на 64-разрядную версию платформы 1С.
2. Настройка версионирования объектов: проверим настройки подсистемы версионирования. Если для справочников или документов с большими файлами и изображениями включено хранение всех версий, платформа пытается целиком упаковать историю объекта в память. Отключим версионирование для тяжелых реквизитов или очистим устаревшие версии.
3. Управление рабочими процессами: в консоли администрирования кластера 1С настроим параметры перезапуска рабочих процессов. Зададим Допустимый объем памяти и Интервал превышения допустимого объема памяти, чтобы предотвратить фрагментацию адресного пространства при длительной работе процессов без перезапуска.
4. Очистка временных файлов: проверим свободное место на системном диске и очистим временный каталог Temp учетной записи, от имени которой запущена служба сервера 1С.