При проектировании инфраструктуры для решений на платформе 1С:Предприятие системные администраторы часто сталкиваются с дилеммой: разносить ли сервер приложений 1С и СУБД MS SQL Server по разным физическим (или виртуальным) машинам, либо разворачивать их совместно на одном сервере. В этой статье мы подробно проанализируем реальный кейс с форума, разберем технические нюансы совмещенной схемы работы, произведем расчеты оперативной памяти и рассмотрим лучшие практики оптимизации производительности.
Рассмотрим конфигурацию оборудования и требования, заявленные в исходном обращении:
Выясним, жизнеспособна ли такая схема, и как добиться от нее максимальной производительности.
---
Разнесение сервера 1С и СУБД на разные физические серверы часто преподносится как стандарт «правильного» проектирования. Однако для небольших и средних внедрений (до 50–70 пользователей) совместное размещение СУБД и 1С на одном сервере не просто допустимо, но и **технически более выгодно**. Главный козырь такой архитектуры — использование протокола Shared Memory (Общая память) вместо сетевого протокола TCP/IP.
Выясним, как это работает на практике. Когда сервер приложений 1С и MS SQL Server находятся на разных машинах, обмен данными между процессами rphost и sqlservr.exe происходит по сети через протокол TCP/IP. Даже при использовании быстрой гигабитной или 10-гигабитной сети на передачу пакетов тратится время (сетевые задержки — network latency), а центральный процессор вынужден тратить такты на упаковку и распаковку сетевых пакетов.
Если же обе службы работают в рамках одной операционной системы, они могут общаться напрямую через выделенный сегмент в оперативной памяти сервера. Это полностью исключает сетевой стек из цепочки обмена данными. Прирост производительности на операциях обмена данными составляет от 10% до 15%. Особенно сильно это заметно на «тяжелых» транзакциях, таких как закрытие месяца или проведение крупных документов, выполняющих тысячи мелких последовательных запросов к СУБД.
Чтобы задействовать этот механизм, выполним следующие шаги по настройке:
Server1C-SQL) или локальный адрес localhost, но **ни в коем случае не IP-адрес**. При указании IP-адреса операционная система Windows принудительно перенаправит трафик через сетевой стек TCP/IP, и преимущества Shared Memory будут утеряны.---
При совместном размещении двух требовательных к ресурсам систем возникает серьезная опасность конкуренции за оперативную память. По умолчанию MS SQL Server спроектирован так, что стремится забрать под свой буферный кэш (Buffer Pool) всю доступную физическую память сервера. Если не ограничить аппетиты СУБД, она вытеснит процессы 1С (rphost) в файл подкачки (pagefile.sys) на жестком диске, что приведет к катастрофическому падению производительности всей системы.
Произведем математический расчет распределения имеющихся 44 ГБ оперативной памяти:
rphost обслуживают 25–30 активных сеансов. В базах БП и ЗУП на каждого пользователя в среднем требуется от 300 до 400 МБ оперативной памяти под серверные вызовы, кэш метаданных и временные таблицы платформы. Таким образом, серверу 1С необходимо выделить минимум 10–12 ГБ.44 - 4 - 12 = 28 ГБ. Следовательно, верхний лимит для СУБД необходимо жестко ограничить значением в 28 ГБ.Рассмотрим подробнее последствия такого лимита. Суммарный объем пяти баз данных составляет от 50 до 75 ГБ. Поскольку лимит памяти для SQL Server установлен на уровне 28 ГБ, СУБД сможет удерживать в кэше буферного пула только около половины или трети всех данных. Это значит, что при обращении пользователей к архивным периодам или редким отчетам SQL Server будет вынужден постоянно обращаться к дисковой подсистеме для считывания страниц данных.
В связи с этим рекомендация по увеличению оперативной памяти сервера до 64 ГБ является крайне актуальной и экономически оправданной. При наличии 64 ГБ оперативной памяти мы сможем выделить под MS SQL Server около 44–46 ГБ, что позволит удерживать практически всю «горячую» (активно используемую) часть баз данных непосредственно в ОЗУ, сводя к минимуму медленное дисковое чтение.
Для установки лимита памяти в MS SQL Server выполним следующие действия:
28672 для 28 ГБ).---
Рабочие процессы сервера 1С (rphost) в процессе длительной работы подвержены фрагментации памяти и утечкам ресурсов, связанных со спецификой исполнения кода прикладных решений. Чтобы предотвратить неконтролируемый рост потребления памяти сервером приложений, настроим параметры перезапуска рабочих процессов в консоли администрирования кластера 1С:
---
При совмещении сервера 1С и СУБД на одном аппаратном сервере диски становятся основным узким местом (bottleneck). Настоятельно рекомендуем отказаться от использования традиционных магнитных HDD-дисков в пользу высокоскоростных твердотельных накопителей класса Enterprise (желательно с интерфейсом NVMe).
Проанализируем схему оптимального распределения дисковой активности. В идеале дисковые операции записи и чтения должны быть разнесены по разным физическим массивам:
%USERPROFILE%\Local Settings\Temp пользователя, под которым запущена служба 1C:Enterprise 8.3 Server Agent)..mdf). На этот диск будет приходиться основной поток операций случайного чтения..ldf). SQL Server записывает данные в журнал транзакций строго последовательно и синхронно при фиксации каждой транзакции, поэтому скорость записи на этот накопитель напрямую влияет на скорость проведения документов в 1С.Рассмотрим подробнее настройку базы tempdb. Платформа 1С:Предприятие при выполнении сложных запросов активно задействует временные таблицы СУБД, которые создаются и обрабатываются именно в базе tempdb. Чтобы избежать взаимных блокировок потоков при выделении страниц памяти (проблема защелок PAGELATCH), настроим tempdb по следующим правилам:
tempdb должно быть равно числу логических ядер процессора (если ядер до 8). В нашем случае (Xeon с 4 ядрами) необходимо создать ровно 4 файла данных tempdb одинакового начального размера.---
По умолчанию после установки операционной системы Windows Server активируется схема электропитания «Сбалансированная» (Balanced). В этом режиме операционная система динамически снижает тактовую частоту процессора при отсутствии непрерывной высокой нагрузки.
Поскольку архитектура 1С генерирует преимущественно короткие, импульсные однопоточные запросы, процессор физически не успевает выйти на свою максимальную тактовую частоту в момент выполнения запроса. Это приводит к ощутимому замедлению работы интерфейса и проведения документов.
Выясним, как это исправить. В обязательном порядке сменим режим электропитания:
C-States, Intel SpeedStep/AMD Cool'n'Quiet), переведя режим управления питанием процессора под контроль операционной системы (режим OS Control).---
В ходе обсуждения на форуме прозвучало предложение (Сообщение 8) установить сервер приложений 1С на терминальный сервер, а MS SQL Server оставить на более мощном сервере. Проанализируем, почему такая архитектурная схема считается неэффективной и даже вредной в реальной практике эксплуатации систем средней нагруженности:
rphost), они будут делить процессорное время с пользовательскими приложениями. Это приведет к микрофризам, зависаниям интерфейса у всех пользователей RDP-сессий при выполнении тяжелых отчетов.Таким образом, предложенное в первом сообщении разделение функций является оптимальным: первый сервер (Xeon 4 ядра, 44-64 ГБ RAM) мы выделяем целиком под связку **1С + SQL Server**, а второй сервер (Xeon 4 ядра, 24 ГБ RAM) используем исключительно как **выделенный терминальный сервер (RDP)**, на котором пользователи будут запускать легкие тонкие клиенты 1С для работы.
---
Для предотвращения сброса страниц памяти буферного пула SQL Server в своп при внезапных пиковых нагрузках со стороны других приложений (например, при запуске тяжелого регламентного задания в 1С), включим для СУБД политику Lock Pages in Memory (Закрепление страниц в памяти):
Win + R, введите gpedit.msc и нажмите Enter для открытия редактора локальной групповой политики.---
Подводя итог нашему анализу, сформируем пошаговый план действий для запуска системы в эксплуатацию:
localhost.rphost раз в сутки.Такой подход обеспечит максимальную производительность дисковой подсистемы и процессора, исключит сетевые издержки и гарантирует стабильную и быструю работу всех пяти информационных баз для 25-30 пользователей.