При переходе на масштабные внедрения «1С:Управление торговлей 11.4» многие ИТ-отделы сталкиваются с парадоксальной ситуацией: мощный сервер с сотнями гигабайт оперативной памяти и быстрыми дисками внезапно «встает колом» при попытке пользователей запустить тяжелые аналитические отчеты. При этом мониторинг показывает низкую общую загрузку процессора и свободную память. Разберем детально, почему так происходит и как сконфигурировать серверную среду, чтобы 1С действительно «летала».
Одной из главных ошибок при выборе сервера для 1С является погоня за количеством ядер в ущерб их частоте. Рассмотрим ситуацию автора: использование процессора серии Xeon Silver. Данная линейка обладает невысокой тактовой частотой на одно ядро. Для платформы 1С, где многие операции выполняются в один поток, критически важна производительность на одно ядро (Single-core performance).
Проанализируем работу сервера приложений. Когда пользователь запускает тяжелый запрос или отчет, платформа 1С нагружает одно конкретное ядро процессора на 100%. Если ядер 16, а загружено только одно, общий диспетчер задач покажет скромные 6.25% загрузки CPU, но пользователь будет ощущать «тормоза», так как его процесс уперся в потолок частоты одного ядра.
Рекомендация: Для систем с числом пользователей 100+ и тяжелой аналитикой следует выбирать процессоры серии Xeon Gold (например, 6244, 6250) или Intel Core i9 для сервера приложений, если позволяют условия эксплуатации. Главный ориентир — базовая частота от 3.5 ГГц и выше.
Часто возникает путаница в том, как SQL Server потребляет память. Важно понимать разницу между зарезервированной памятью и реально используемой (Working Set). Если SQL показывает потребление 1.5 Гб при выделенных 100 Гб, это может свидетельствовать о недавней очистке кэша или о том, что данные не попадают в буферный пул.
Выясним причину через настройку Lock Pages in Memory. Разберем по шагам:
Max Server Memory. Рекомендуется оставлять операционной системе и процессам 1С (rphost) около 20-30% памяти, остальное отдавать SQL.Посмотрим на настройки параллелизма. Параметр Max Degree of Parallelism (MDOP) часто вызывает споры. Рассмотрим рекомендации:
MDOP = 1, чтобы избежать блокировок при распараллеливании коротких запросов.Cost Threshold for Parallelism стоит поднять со стандартных 5 до 50, чтобы SQL параллелил только действительно тяжелые задачи.Одной из скрытых причин «вставания колом» является новый формат журнала регистрации (lgp.lgp на базе SQLite). При большом количестве активных пользователей и интенсивной записи событий база SQLite блокируется. Рассмотрим решение через смену формата:
Переведем журнал регистрации в старый текстовый формат. Несмотря на отсутствие некоторых удобств поиска, текстовый формат намного стабильнее ведет себя при параллельной записи от 100+ сеансов. Для этого в файле conf.cfg или через настройки кластера нужно изменить тип журнала и перезапустить службу.
Если оптимизация кода покупных решений невозможна, проанализируем варианты архитектурного разделения. Необязательно заставлять всех работать в одной базе на одном сервере.
Платформа 1С позволяет настроить автоматическое обновление копии базы данных. Рассмотрим схему:
Это позволит аналитикам нагружать второстепенный сервер, не мешая операторам вводить документы в основной базе. Это гораздо эффективнее и дешевле, чем бесконечный апгрейд железа.
Лицензия КОРП — это не просто формальность, а инструмент управления производительностью. Разберем, какие возможности она дает для решения нашей проблемы:
В КОРП-версии доступна настройка «Безопасный расход памяти за один вызов». Рассмотрим пример использования:
// В консоли администрирования кластера КОРП
// Устанавливаем лимит памяти на один вызов сервера
БезопасныйРасходПамятиЗаОдинВызов = 2147483648; // 2 Гб
Если какой-то «кривой» отчет в стороннем расширении попытается сожрать 100 Гб оперативной памяти, система просто прервет этот конкретный сеанс, не вешая весь сервер и не вытесняя кэш SQL. Это гарантирует выживаемость системы в пиковые нагрузки.
Проанализируем состояние дисков. Использование Intel Optane для TempDB — отличное решение. Однако важно правильно настроить сам SQL для работы с этой базой. Выясним основные правила:
TempDB должно соответствовать количеству физических ядер процессора (но обычно не более 8-12).Подведем итог: если ваша УТ 11 тормозит на мощном железе, начните с аудита частоты процессора на ядро, проверьте настройки MDOP в SQL и обязательно переведите журнал регистрации в текстовый формат. Если нагрузка от аналитики остается критической — используйте механизмы копий баз данных или распределенные информационные базы (РИБ) для выноса отчетов на отдельный вычислительный узел.