Ситуация, когда сервер 1С в связке с SQL Server начинает «подтормаживать», а пользователи жалуются на зависание сессий, является классической проблемой при нехватке ресурсов или некорректной архитектуре системы. Рассмотрим типичный кейс: виртуальная машина на Hyper-V, 8 ядер процессора, 52 ГБ оперативной памяти и три базы общим объемом около 100 ГБ (Бит.Строительство, ЗУП, Документооборот), на которых работают 40 терминальных пользователей через RemoteApp. Проанализируем, почему такая конфигурация «захлебывается», и разберем по шагам, как оптимизировать работу системы.
Первая и самая критичная проблема в описанной ситуации — совмещение ролей сервера баз данных (SQL), сервера приложений 1С и терминального сервера (RemoteApp) на одной операционной системе. Проанализируем ситуацию: SQL Server по своей природе стремится занять всю доступную оперативную память для кэширования данных. В то же время 40 терминальных пользователей активно потребляют ресурсы на отрисовку интерфейса и работу клиентских приложений. Выясним причину деградации: при нехватке памяти система начинает использовать файл подкачки (свопинг), что катастрофически снижает скорость работы из-за разницы в скорости между ОЗУ и диском.
Рекомендация: Для стабильной работы крайне желательно вынести терминальный сервер на отдельную виртуальную машину или физический сервер. Если это невозможно, необходимо перейти на использование тонкого клиента. Тонкий клиент потребляет значительно меньше ресурсов на стороне сервера по сравнению с RemoteApp/RDP, так как основная нагрузка по отрисовке интерфейса ложится на локальные компьютеры пользователей.
Разберем подробнее вопрос выделения ядер процессора. В настройках Hyper-V параметр число виртуальных процессоров часто путают с физическими ядрами. На самом деле, это количество потоков. Если процессору Xeon Gold 6146 (у которого 12 ядер и 24 потока) выделено 8 виртуальных процессоров, то фактически машина получает ресурсы, эквивалентные 4 физическим ядрам. Для 40 активных пользователей и тяжелых баз этого недостаточно.
Также важно проверить схему электропитания на физическом хосте Hyper-V и внутри гостевой ОС. Рассмотрим настройку:
В сбалансированном режиме ядра процессора могут «засыпать» или снижать частоту, что критично для 1С, так как время отклика (latency) в этой системе важнее общей многопоточной производительности.
Проанализируем объем памяти. На 100 ГБ баз данных и 40 пользователей выделено 52 ГБ. Этого едва хватает только для нормальной работы SQL Server. Если учесть, что каждая терминальная сессия RemoteApp может потреблять от 500 МБ до 1 ГБ, то 40 пользователей могут «съесть» до 40 ГБ только на свои процессы. На SQL и систему остается всего 12 ГБ, что и приводит к состоянию, когда сервер «захлебывается».
Посмотрим, как правильно настроить лимиты для SQL Server, чтобы он не конфликтовал с процессами 1С:
Maximum server memory (in MB). Оставьте операционной системе и процессам 1С (rphost) хотя бы 10-15 ГБ от общего объема, остальное отдайте SQL.Важно: В настройках Hyper-V для этой виртуальной машины должна быть установлена Статическая память. Динамическая память для SQL Server противопоказана, так как механизмы ее перераспределения вызывают резкие скачки задержек.
Разберем по шагам ключевые параметры СУБД, которые напрямую влияют на «тормоза» в 1С:
Параметр MAXDOP (Max Degree of Parallelism): По умолчанию SQL пытается распараллеливать запросы на все доступные ядра. Для 1С это часто вредно. Рекомендуется установить значение 1 (или 2-4, если ядер много, но начать лучше с 1). Это предотвратит ситуацию, когда один тяжелый запрос от пользователя блокирует все ядра процессора.
Параметр Cost Threshold for Parallelism: Увеличьте это значение с 5 (по умолчанию) до 50. Это укажет SQL серверу не распараллеливать мелкие запросы, на подготовку которых тратится больше времени, чем на выполнение.
Протокол Shared Memory: Поскольку SQL и сервер 1С находятся на одном хосте, убедитесь, что они общаются через общую память. Это быстрее, чем TCP/IP. Проверить это можно в SQL Server Configuration Manager в разделе SQL Server Network Configuration — Protocols for MSSQLSERVER.
Проанализируем ситуацию с базами. 1С:Документооборот и Бит.Финанс содержат огромное количество регламентных заданий. Например, «Документооборот» постоянно запускает процессы обработки почты, полнотекстового поиска и уведомлений. Если эти задания выполняются каждые 10 секунд, они создают постоянную паразитную нагрузку на процессор.
Для диагностики наиболее «тяжелых» процессов выполните следующие шаги:
Сеансы.Время вызова (текущее) или Время вызова (всего).Если база ЗУП весит 40 ГБ при 40 пользователях — это аномалия. Скорее всего, в базе хранятся сканы документов в высоком разрешении. Выясним причину: такие объемы данных в оперативной памяти SQL Server вытесняют полезный кэш индексов. Рассмотрите возможность выноса хранения файлов из базы данных во внешние тома (настройка в 1С:Документооборот и ЗУП).
Посмотрим на дисковую активность. В Диспетчере задач или Мониторе ресурсов проверьте параметр Длина очереди диска. Если это значение стабильно выше 2, ваши диски не справляются. При совмещении SQL и Терминала возникает конфликт: SQL требует быстрых операций чтения, а профили пользователей в RemoteApp генерируют множество мелких записей. Рекомендуется использовать SSD корпоративного класса и разделять файлы БД (mdf), логи (ldf) и временную базу (tempdb) по разным виртуальным дискам.
Для решения проблемы подтормаживания системы мы рекомендуем придерживаться следующего плана:
Max Server Memory, установить MAXDOP = 1 и включить Lock Pages in Memory.Соблюдение этих шагов позволит стабилизировать систему и избавиться от «зависаний» при работе в 1С.