Рассмотрим распространенную ситуацию: сервер 1С, на котором одновременно работают сервер приложений, СУБД (MSSQL), терминальный сервер и веб-сервер (IIS), начинает испытывать критическую нагрузку. В частности, во время выполнения регламентных обменов данными с внешними системами (например, сайтом или CRM) загрузка процессора достигает 100%, что приводит к замедлению работы всех пользователей. Проанализируем, почему это происходит и какие шаги можно предпринять для решения проблемы.
Исходные данные проблемы: один сервер с процессором Intel Core i5, 32 ГБ ОЗУ и SSD-дисками. На нем развернуты сервер 1С, MSSQL, терминальный и веб-серверы для 35 пользователей. Проблема возникает при обмене данными в «1С:Управление торговлей» (база 40 ГБ), когда система обрабатывает большой объем номенклатуры.
Прежде чем вкладывать деньги в новое оборудование, важно понять, какой именно процесс создает пиковую нагрузку. В системе 1С за производительность отвечают два ключевых компонента:
В обсуждаемой ситуации пользователь уточнил, что в начале обмена пиковую нагрузку в 100% создает именно процесс sqlservr.exe, а rphost.exe борется за оставшиеся ресурсы. Это говорит о том, что первоначальное узкое место — это выполнение запроса к базе данных, который выбирает данные для обмена. После того как запрос отработан, нагрузка на СУБД падает, но обмен продолжается, и нагрузку уже создает сервер 1С, обрабатывающий полученные данные.
Такая ситуация типична, когда на одной машине конкурируют за ресурсы два "тяжелых" сервиса. Решение проблемы лежит в комплексном подходе: оптимизации запросов, изменении архитектуры и обновлении оборудования.
Самая правильная и стандартная практика при росте нагрузки — это разделение сервера приложений 1С и сервера СУБД на разные физические или виртуальные машины. Это фундаментальный шаг для повышения производительности и стабильности.
Почему это помогает?
rphost. Аналогично, сервер 1С получит выделенные ресурсы для выполнения кода.Что нужно учесть:
При разделении серверов между ними возникает сетевое взаимодействие по протоколу TCP/IP. Чтобы это не стало новым узким местом, обеспечьте между серверами быстрое сетевое соединение (минимум 1 Гбит/с, в идеале — 10 Гбит/с).
Часто высокая нагрузка на СУБД вызвана не столько слабым "железом", сколько неоптимальными настройками или кодом. Перед покупкой нового сервера обязательно проверьте следующие моменты.
Нерассчитанные итоги регистров
Это одна из самых частых причин медленной работы запросов на получение остатков (СрезПоследних). Если итоги по регистрам накопления не рассчитаны или устарели, СУБД для получения актуальных данных приходится "перелопачивать" всю таблицу движений, что создает колоссальную нагрузку.
Решение: Убедитесь, что в вашей базе настроено и регулярно выполняется регламентное задание по расчету итогов. Запускать его следует в период минимальной активности пользователей, например, ночью.
Анализ запросов
Возможно, сам запрос, который выполняется при обмене, написан неоптимально. Для выявления таких запросов можно использовать:
Проанализировав проблемный запрос, можно передать его программисту 1С для оптимизации.
Индексация таблиц
Проверьте, что для таблиц, к которым идут обращения во время обмена, существуют необходимые индексы. Отсутствие индексов приводит к полному сканированию таблиц (Full Table Scan), что крайне медленно и ресурсоемко.
Если вы решили разделить серверы и приобрести новую машину для СУБД, при выборе конфигурации уделите внимание следующим компонентам.
Процессор (CPU)
Для сервера баз данных важна как высокая тактовая частота на ядро, так и достаточное количество ядер. Для нагрузки до 50 пользователей хорошим выбором будет современный процессор с 6-8 быстрыми ядрами. Например, AMD Ryzen 5 5600X или аналогичный процессор от Intel.
Оперативная память (RAM)
Чем больше данных СУБД может закэшировать в ОЗУ, тем быстрее работает система. Для базы размером 40 ГБ и планируемого роста пользователей до 50, рекомендуется не менее 32-64 ГБ оперативной памяти. Для серверной системы крайне желательно использовать память с коррекцией ошибок (ECC), это повысит стабильность.
Дисковая подсистема (SSD)
Это критически важный компонент для производительности СУБД. Рекомендуется использовать несколько быстрых дисков:
Примерная сборка в рамках бюджета:
Рассматриваемый переход с платных Microsoft Windows Server и MSSQL на бесплатные Ubuntu Server и PostgreSQL — это экономически выгодное решение. С точки зрения производительности, правильно настроенный PostgreSQL на Linux часто не уступает, а в некоторых сценариях и превосходит MSSQL. Однако для его администрирования потребуются соответствующие компетенции. Этот шаг также подразумевает переход с веб-сервера IIS на Apache или Nginx, если веб-сервисы 1С используются для обмена.
Итог:
Оптимальная стратегия для решения проблемы — это комплексный подход. Начните с программной оптимизации, так как это может дать результат с минимальными затратами. Если проблема сохраняется, реализуйте архитектурное решение: разделите серверы 1С и СУБД, собрав для базы данных новую, сбалансированную машину. Это не только решит текущую проблему с производительностью, но и создаст запас прочности для дальнейшего роста вашей компании.