← На главную

Многие администраторы высоконагруженных систем 1С сталкиваются с классической проблемой: один пользователь запускает формирование объемного и сложного отчета, после чего сервер СУБД блокируется, транзакции зависают, а сеансы остальных пользователей начинают отваливаться. Возникает логичный вопрос — можно ли жестко разделить ресурсы сервера (процессор, оперативную память) между пользователями в равных долях или установить лимит, например, не более 50% мощности на одного юзера?

Давайте подробно разберем эту ситуацию, проанализируем ошибки в архитектуре и рассмотрим современные, правильные способы балансировки нагрузки и ограничения аппетитов «тяжелых» сеансов.

Анализ аппаратных мощностей и архитектуры

Проанализируем типичный пример: имеется сервер с процессором Xeon 5218R и 128 ГБ оперативной памяти. На нем развернуты базы 1С, СУБД (SQL Server) и работают около 500 пользователей (большая часть — через RDP на этом же или соседних серверах). В такой конфигурации проблема кроется в критической нехватке аппаратных ресурсов.

Один терминальный сеанс RDP с запущенным клиентом 1С потребляет в среднем 300–500 МБ оперативной памяти. На обслуживание 400–500 пользователей только для RDP-сессий потребуется от 150 до 250 ГБ ОЗУ. При наличии всего 128 ГБ сервер неизбежно уходит в жесткий свопинг (использование файла подкачки на диске), что парализует работу и сервера 1С, и СУБД.

Что необходимо сделать в первую очередь:

1. Вынести пользователей RDP на отдельные терминальные серверы. Сервер СУБД и сервер приложений 1С должны иметь гарантированные ресурсы.
2. Увеличить объем оперативной памяти на сервере баз данных.
3. Разнести физические дисковые массивы (или использовать быстрые NVMe). Категорически не рекомендуется держать сервер приложений 1С в одном дисковом пространстве с SQL. Оба компонента генерируют высокую дисковую нагрузку, и сервер приложений 1С крайне чувствителен к дисковой деградации.

Ограничение ресурсов на уровне SQL Server

Ранее для ограничения потребления ресурсов процессами в Windows использовали утилиту WSRM. Однако эта технология признана устаревшей и удалена из современных версий Windows Server. Правильный подход — ограничивать нагрузку непосредственно на уровне СУБД.

В MS SQL Server есть встроенный мощный инструмент — Resource Governor (Регулятор ресурсов). С его помощью мы распределим входящие сессии по специальным пулам ресурсов. Мы сможем:

1. Классифицировать подключения по имени приложения, пользователю или базе данных.
2. Задать жесткие лимиты на использование CPU (процессорного времени) и RAM (оперативной памяти) для пула, в который попадают тяжелые отчеты.
3. Предотвратить ситуации, когда один некорректный запрос забирает 100% мощности SQL-сервера, оставляя приоритетные транзакции (проведение документов) в очереди.

Механизм копий баз данных для тяжелых отчетов

Если блокировки транзакций у скульника происходят из-за чтения огромных массивов данных, лучшим решением будет использование встроенного в платформу 1С:Предприятие 8.3 (начиная с версии 8.3.14) механизма репликации — Механизм копий баз данных (подобно архитектуре CQRS).

Разберем алгоритм настройки:

1. Поднимаем отдельный сервер (можно менее мощный) и настраиваем на него автоматическую репликацию данных из основной рабочей базы.
2. В настройках платформы и конфигурации указываем, что тяжелые аналитические отчеты должны получать данные исключительно из копии базы.
3. В результате, когда пользователь формирует "ебейший отчет", нагрузка ложится на резервный сервер. В основной базе блокировок не возникает, и остальные пользователи продолжают комфортно проводить документы.

Настройка кластера серверов 1С

Вместо попыток поделить ресурсы между пользователями, мы настроим ограничения в консоли администрирования кластера 1С. Платформа имеет отличные встроенные механизмы балансировки рабочих процессов rphost.

Параметры рабочих процессов:

1. Задаем критический объем памяти для процессов rphost. Если пользователь запустит отчет, который начнет неконтролируемо съедать всю оперативную память, кластер 1С принудительно завершит этот процесс по достижении лимита. Сеанс виновника прервется, но весь сервер не зависнет.
2. Настраиваем изоляцию процессов. Выделяем фоновые задания или конкретные информационные базы на отдельные рабочие процессы, чтобы они не пересекались с активными пользовательскими сеансами.

Поиск виновников: Технологический журнал 1С

Искать, кто именно повесил базу, через обычный Журнал регистрации — задача бессмысленная. Журнал регистрации показывает только бизнес-события. Для глубокого анализа производительности мы применим Технологический журнал (ТЖ).

Настроим сбор логов ТЖ на следующие события:

1. TTIMEOUT и TLOCK — для отслеживания таймаутов и ожиданий на управляемых блокировках.
2. DBMSSQL — для фиксации долгих запросов к СУБД.

Проанализировав логи ТЖ, мы точно установим имя пользователя, название отчета, текст SQL-запроса и время его выполнения. Это даст нам четкое понимание, какую часть кода необходимо передать программистам на оптимизацию.

Оптимизация на уровне RDP (Групповые политики)

Поскольку подавляющее большинство пользователей (около 475 человек) работает через удаленный рабочий стол, мы должны жестко регламентировать их сеансы через групповые политики (GPO) Windows Server:

1. Тайм-ауты бездействия: Устанавливаем принудительное отключение или завершение сеанса через 30-60 минут простоя. "Висящие" сессии потребляют огромный объем памяти.
2. Квотирование дисков (FSRM): Ограничиваем размер пользовательских профилей (папки Temp и AppData), чтобы временные файлы 1С не переполнили системный диск, что моментально приведет к падению сервера.
3. Ограничение функционала: Отключаем перенаправление локальных принтеров, дисков и буфера обмена, если это не требуется для работы, тем самым снижая фоновую нагрузку на сервер.

Подводя итог: делить ресурсы "поровну" на сервере 1С невозможно и нецелесообразно. Проблема решается комплексным подходом — наращиванием памяти, правильной балансировкой в кластере 1С, использованием MS SQL Resource Governor, настройкой механизма копий баз данных для аналитики и грамотной настройкой терминальных серверов.