При эксплуатации систем на базе 1С:Предприятие 8.3 в клиент-серверном варианте часто возникает ситуация, когда текущий сервер перестает справляться с нагрузкой. Перед системным администратором встает классическая дилемма: продолжать наращивать ресурсы одного мощного сервера (вертикальное масштабирование) или перейти к «честной» трехзвенной архитектуре, разнеся сервер приложений 1С и сервер СУБД (SQL) на разные физические или виртуальные машины. Рассмотрим подробнее все за и против такого решения, проанализируем технические нюансы и выясним, как не допустить деградации производительности при переезде.
Прежде чем принимать решение о покупке нового оборудования или миграции баз, разберем по шагам алгоритм диагностики. Нельзя просто так переносить SQL на другой хост, надеясь, что станет быстрее. Часто результат бывает обратным. Проанализируем нагрузку на текущем сервере:
rphost) и SQL-сервер (процесс sqlservr.exe) имеют разные профили нагрузки. Сервер 1С требует высокой тактовой частоты (от 3.5 ГГц), так как бизнес-логика часто выполняется в один поток. SQL-сервер лучше масштабируется по количеству ядер и объему кэша L3.tempdb.Если мы видим, что ресурсов не хватает обоим процессам одновременно, и физическая возможность апгрейда текущего сервера исчерпана, только тогда рассматриваем вариант разделения.
Разберем важнейший технический аспект, который часто упускают из виду. При размещении сервера 1С и SQL на одном хосте (двухзвенка), система по умолчанию использует протокол Shared Memory (общая память). Это позволяет передавать данные между процессами практически мгновенно, минуя сетевой стек.
Как только мы разносим серверы по разным хостам, взаимодействие переходит на протокол TCP/IP. Посмотрим на последствия:
Для оценки разницы рекомендуется запустить специализированные тесты (например, тест Гилева). На двухзвенке с использованием Shared Memory показатели всегда будут выше, чем на трехзвенке через 1 Гбит сеть, при прочих равных характеристиках процессора.
Если решение о разделении принято, выясним причину и выберем правильный сценарий:
Рассмотрим ситуацию, когда SQL-серверу хватает памяти для кэширования таблиц, но процессор перегружен расчетами 1С. В этом случае логично оставить SQL на старом месте (где уже настроены быстрые диски), а сервер приложений 1С перенести на новый хост с максимально доступной частотой ядра процессора. Это даст прирост в скорости проведения документов.
Если база данных выросла настолько, что ей требуется огромный объем RAM (сотни гигабайт) и мощная дисковая полка, выносим SQL. При этом крайне важно обеспечить максимально «короткий» сетевой путь до сервера 1С. Идеально — прямое соединение двух серверов отдельным патч-кордом 10 Гбит/с без лишних коммутаторов.
Чтобы минимизировать негативный эффект от сетевого взаимодействия, проанализируем следующие настройки:
hosts на сервере 1С, указав IP-адрес сервера SQL, или использовать IP-адрес напрямую в строке подключения в консоли администрирования.Network Packet Size) по умолчанию установлено значение 4096 байт. Для 1С, которая часто оперирует большими объемами данных при формировании отчетов, имеет смысл протестировать увеличение этого значения до 8192 байт.tempdb расположена на самом быстром накопителе (NVMe). В трехзвенной архитектуре нагрузка на временные таблицы возрастает из-за особенностей передачи данных между звеньями.Выясним критерии, при которых переход к трехзвенке неизбежен:
Подведем итог: для небольших систем с ограниченным бюджетом и малым количеством пользователей (до 30-50) лучше вложить средства в один мощный сервер («все в одном»). Это позволит использовать преимущество Shared Memory и избежать сложностей с настройкой сети. Если же вы уперлись в потолок производительности железа, переход к трехзвенке должен сопровождаться обязательным внедрением 10-гигабитной сети, иначе сетевые задержки нивелируют весь выигрыш от нового оборудования.