← На главную

При эксплуатации крупной информационной системы на платформе 1С:Предприятие 8.3 с одновременной работой около 500 пользователей (например, в связке с конфигурациями УТ 11, БУХ, ЗУП) администраторы часто сталкиваются с падением рабочих процессов rphost, ошибками «Аварийно завершен процесс» или «Не хватает памяти». Чаще всего подобные сбои проявляются во время выполнения ресурсоемких операций: массового перепроведения документов, закрытия месяца или построения тяжелых отчетов. Разберем по шагам, как выявить узкие места инфраструктуры и оптимизировать параметры операционной системы, СУБД и кластера 1С для обеспечения стабильной и быстрой работы.

Архитектурное разделение серверов и сетевое взаимодействие

Разберем фундаментальную причину падений под высокой нагрузкой. Когда сервер 1С:Предприятия и MS SQL Server сосуществуют на одной физической машине, между ними неизбежно возникает ожесточенная конкуренция за оперативную память и процессорное время. СУБД стремится кэшировать в оперативной памяти как можно больше страниц данных, а рабочий процесс rphost при выполнении вычислений запрашивает динамические блоки RAM. В моменты пиковых вычислений операционная система не успевает своевременно выделить страницы памяти или начинает сбрасывать данные в файл подкачки, что приводит к краху служб.

Оптимальным решением является разделение нагрузки на два выделенных физических сервера:

1. Выделенный сервер СУБД: принимает на себя исключительно обслуживание базы данных MS SQL Server.
2. Выделенный сервер приложений 1С: берет на себя исполнение бизнес-логики и фоновых заданий платформы.

Обратим особое внимание на сетевой канал между сервером 1С и сервером СУБД. При 500 активных сессиях и базах объемом свыше 100 ГБ стандартного прямого подключения 1 Гбит/с становится категорически недостаточно. Во время закрытия месяца и массового расчета регистров межсерверный трафик переполняет гигабитный линк. Это приводит к задержкам передачи пакетов, потере сетевых пакетов, таймаутам соединений и аварийному сбросу сессий. Обязательно используем межсерверное соединение со скоростью не менее 10 Гбит/с, а также активируем технологию Jumbo Frames (MTU 9000) на обоих физических адаптерах для снижения накладных расходов процессора на обработку сетевых кадров.

Оптимизация параметров операционной системы и электропитания

Проанализируем базовые параметры операционной системы на обоих серверах, без коррекции которых тонкие настройки 1С и СУБД не дадут должного эффекта:

1. План электропитания: в панели управления Windows Server и на уровне аппаратного BIOS обязательно переключаем режим управления питанием в положение «Высокая производительность» (High Performance). Сброс частот процессорных ядер в целях энергосбережения при динамических скачках нагрузки 1С дает критическую просадку времени отклика.
2. Приоритет распределения процессорного времени: переходим по пути «Система» — «Дополнительные параметры системы» — «Быстродействие» — «Параметры» — вкладка «Дополнительно» и убеждаемся, что оптимизация работы процессора выставлена в положение «Оптимизировать работу служб, работающих в фоновом режиме».
3. Файл подкачки (pagefile): задаем фиксированный размер файла подкачки на быстрых накопителях во избежание фрагментации дискового пространства при спонтанном расширении.
4. Учет архитектуры NUMA: если сервер двухпроцессорный, оперативная память разбивается на узлы NUMA. Выделение памяти под процессы СУБД и 1С должно учитывать локальность памяти каждого сокета. Использование памяти чужого узла через межпроцессорную шину QPI/UPI снижает скорость операций с памятью на 10–15%. Планки оперативной памяти должны распределяться по каналам строго симметрично.

Тонкая настройка MS SQL Server под требования 1С

Рассмотрим конфигурацию параметров экземпляра MS SQL Server, предотвращающую взаимоблокировки и нерациональный расход ресурсов:

1. Ограничение максимального объема памяти (Max Server Memory): никогда не оставляем значение по умолчанию. Серверу СУБД необходимо жестко зафиксировать верхнюю границу, оставив операционной системе и системным службам не менее 16–32 ГБ RAM (в зависимости от общего объема).
2. Управление параллелизмом (Max Degree of Parallelism и Cost Threshold for Parallelism): фирма «1С» рекомендует для параметра MaxDoP значение 1 (отключение параллелизма запросов). Установка MaxDoP = 0 без тонкой калибровки стоимости запросов приводит к тому, что простые запросы динамических списков начинают дробиться на множество потоков, вызывая задержки типа CXPACKET и зависание интерфейсов пользователей. Если параллелизм необходим для ускорения тяжелых аналитических выборок, параллельно повышаем стоимостной порог параллелизма (Cost Threshold for Parallelism) со стандартных 5 до значений 35–50, исключая запуск параллельных планов на мелких операциях.
3. Флаги трассировки (Trace Flags):
   1. TF 2371: обязателен для крупных таблиц баз данных (УТ 11, ERP). Включает динамический пересчет порога автоматического обновления статистики, что защищает от построения неоптимальных планов выполнения запросов при интенсивных вставках документов.
   2. TF 1118 и TF 1117: снижают взаимные блокировки при распределении страниц в системной базе tempdb и обеспечивают пропорциональный рост всех файлов данных.
4. Конфигурация базы данных TempDB: разбиваем tempdb на несколько файлов данных одинакового размера (по числу физических ядер процессора, но не более 8 файлов). Шаг авторасширения файлов настраиваем фиксированным объемом (например, по 256–512 МБ), исключая процентное увеличение.
5. Системные привилегии службы SQL Server:
   1. Instant File Initialization (Мгновенная инициализация файлов): предоставляем сервисной учетной записи SQL право локальной политики безопасности «Выполнение задач по обслуживанию томов» (SE_MANAGE_VOLUME_NAME). Это устраняет замирание работы пользователей при росте файлов данных.
   2. Lock Pages in Memory (Блокировка страниц в памяти): активируем право «Закрепление страниц в памяти», что предотвращает сброс буферного пула СУБД в своп Windows при нехватке памяти.

Настройка кластера серверов 1С:Предприятие 8.3

Перейдем к свойствам кластера 1С, непосредственно влияющим на стабильность рабочих процессов rphost:

1. Количество сеансов на рабочий процесс: не следует перегружать один процесс. При 500 пользователях рекомендуемое значение составляет 20–30 сессий на один rphost. Это защитит процесс от чрезмерного потребления виртуальной памяти и ее фрагментации, а также изолирует группы пользователей друг от друга.
2. Безопасный расход памяти за один вызов: задаем этот параметр в свойствах кластера или базы. Если пользователь сформирует неоптимальный отчет или регламентное задание попытается загрузить гигантский массив в память за один раз, система аварийно прервет исключительно текущий вызов с ошибкой, сохранив процесс rphost и работу остальных сотен сеансов.
3. Мягкий перезапуск процессов: настраиваем параметры «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти». Рабочий процесс, исчерпавший выделенный лимит или отработавший заданный временной интервал, перестает принимать новые соединения и плавно завершается после завершения активных задач, предотвращая утечки памяти.
4. Требования назначения функциональности (ТНФ): для изоляции фоновых регламентных заданий (закрытие месяца, расчет себестоимости) настраиваем правила кластера. Мы можем выделить под сервис фоновых заданий конкретный рабочий сервер кластера или отдельные процессы rphost, полностью оградив интерактивную работу менеджеров от просадок производительности.

Оптимизация прикладных регламентных процедур

Выясним причину ошибок нехватки памяти на стороне конфигураций (УТ 11, ERP). В типовых решениях процедура закрытия месяца по умолчанию пытается распараллеливать операции на максимальное число потоков по количеству потоков процессора. Это приводит к одновременному созданию десятков тяжелых фоновых заданий, порождающих конкуренцию за блокировки регистров и мгновенный расход оперативной памяти.

В настройках закрытия месяца в прикладном решении ограничиваем число параллельных потоков расчетных операций до консервативных величин: от 2 до 4 потоков. Это снимет критическую нагрузку на память, устранит взаимные блокировки и существенно сократит общее время регламентной процедуры.

Также проводим ревизию расписания фоновых задач: отключаем или переносим на глубокую ночь фоновое слияние индексов полнотекстового поиска (СлияниеИндексовППД), пересчет итогов регистров и регулярные синхронизации данных, исключая их наложение на перепроведение документов.