Вопрос разделения сервера приложений 1С:Предприятие и системы управления базами данных (СУБД) на разные физические или виртуальные машины является одним из самых обсуждаемых в среде системных администраторов 1С. С одной стороны, существует старая школа, рекомендующая жесткое разделение ролей, с другой — современные технологии обмена данными внутри одной ОС, которые обещают прирост производительности при совместном размещении. В этой статье мы подробно разберем, как именно работают эти механизмы, и в каких случаях разделение ресурсов оправдано, а в каких — вредно.
Ранее, во времена активного использования старых версий платформ и СУБД, разделение на разные физические серверы было обусловлено банальной нехваткой мощностей одного «железа». Сегодня же, когда ресурсы позволяют запускать всё на одном хосте, на первый план выходит вопрос эффективности взаимодействия. Рассмотрим ключевую технологию, которая часто становится аргументом в пользу совместной установки — Shared Memory.
Разберем, как это работает: при нахождении rphost (рабочего процесса 1С) и процесса СУБД (например, sqlservr.exe) в рамках одной операционной системы, они могут обмениваться данными напрямую через оперативную память, минуя сетевой стек TCP/IP. Это исключает накладные расходы на упаковку данных в пакеты и их дефрагментацию. Однако, как отмечают участники обсуждения, прирост производительности от этой технологии составляет в среднем 5-15% и наиболее заметен на операциях с огромным количеством мелких запросов.
Проанализируем ситуацию, когда 1С и СУБД живут на одной ОС. Здесь возникает скрытая проблема — борьба за процессорное время. СУБД (особенно MS SQL Server) обладает собственным высокоэффективным планировщиком потоков — SQLOS. Он спроектирован так, чтобы максимально утилизировать ресурсы процессора под задачи базы данных. Когда на этой же машине начинают активно работать процессы rphost, планировщик самой Windows вынужден постоянно переключать контекст (context switching) между задачами СУБД и задачами сервера приложений.
Выясним, к чему это приводит на практике:
Buffer Pool (кэш страниц данных). 1С также крайне требовательна к памяти. На одной машине они начинают «вытеснять» друг друга, что может привести к сбросу данных в файл подкачки (swap), а это фатально для производительности.Разделение на две виртуальные машины позволяет нам жестко лимитировать ресурсы для каждой системы на уровне гипервизора, предотвращая ситуацию, когда один сервис «душит» другой.
Современные серверы с двумя и более процессорами используют архитектуру NUMA (Non-Uniform Memory Access). В этой схеме каждому процессору принадлежит свой локальный банк памяти. Доступ к «своей» памяти осуществляется мгновенно, а к памяти соседа — со значительной задержкой.
Посмотрим на пример: если мы создаем одну гигантскую виртуальную машину, которой выделяем все доступные ядра и всю память хоста, операционная система внутри ВМ неизбежно начнет распределять потоки 1С и СУБД по разным NUMA-узлам. В итоге процесс СУБД может пытаться прочитать данные из памяти, которая физически относится к другому процессору. Если же мы разделим систему на две ВМ меньшего размера, каждая из которых «впишется» в границы одного NUMA-узла, мы получим гораздо более стабильный и быстрый отклик системы, который с лихвой перекроет отсутствие Shared Memory.
Проанализируем работу дисков. Профили нагрузки 1С и СУБД принципиально различаются:
tempdb и логах транзакций.Когда эти нагрузки смешиваются в одной очереди дисковой подсистемы внутри одной ОС, производительность падает из-за конфликтов доступа. Разделение по разным ВМ позволяет нам разнести дисковые хранилища по разным LUN или физическим массивам, оптимизируя каждый из них под конкретный тип задач.
Если в вашем стеке используется PostgreSQL на операционных системах семейства Linux, ситуация с сетевым обменом выглядит иначе. Рассмотрим альтернативу технологии Shared Memory — UNIX domain sockets. При нахождении сервера 1С и PostgreSQL на одной Linux-машине, взаимодействие через сокеты происходит крайне быстро, практически не уступая прямой работе с памятью. Однако рекомендация устанавливать PostgreSQL именно на Linux (например, CentOS или Debian) остается в силе, так как версия этой СУБД под Windows традиционно показывает меньшую производительность и стабильность в связке с 1С.
Помимо чистой производительности, разберем эксплуатационные преимущества разделения:
Рассмотрим, какую стратегию выбрать в зависимости от условий:
Оправдано только в следующих случаях:
Shared Memory может дать критически важный бонус на слабых процессорах.Рекомендуется как стандарт для средних и крупных внедрений:
Таким образом, хотя технология Shared Memory и кажется привлекательной, на современных многоядерных системах архитектурные преимущества разделения ролей (изоляция ресурсов, учет NUMA, удобство бэкапов) чаще всего оказываются более весомыми для стабильной работы бизнес-приложения.