Оптимизация сервера 1С:Предприятие при ограниченных ресурсах

Оптимизация рабочих процессов и потребления памяти

Почему сервер 1С, который в понедельник работал шустро, к пятнице превращается в вялую машину, на которой каждое действие пользователя занимает десятки секунд? Ответ почти всегда один и тот же: рабочие процессы (rphost.exe) накопили критический объём памяти и деградировали. На одиночном сервере с десятками баз эта проблема проявляется острее всего — вам некуда девать нагрузку, и каждый «прожорливый» процесс отбирает ресурсы у остальных.

Как устроены рабочие процессы

Каждый рабочий процесс (rphost.exe) — это отдельный экземпляр сервера приложений 1С, который принимает соединения от клиентов, исполняет серверный код и обменивается данными с SQL Server. Платформа автоматически создаёт несколько таких процессов и распределяет между ними входящие соединения. Ключевой параметр, который определяет это распределение — количество соединений на процесс. По умолчанию оно равно 256.

Представьте себе ресторан с одним официантом на 256 столов. Пока столиков занято мало — всё отлично. Но когда зал заполняется, официант начинает метаться, забывает заказы, тормозит. Если разделить зал на секции с отдельными официантами — каждый обслуживает меньше столов и работает быстрее. Именно так работает уменьшение количества соединений на процесс: вы получаете больше рабочих процессов, каждый из которых обслуживает меньше сеансов.

Настройка количества соединений на процесс

Откройте консоль кластера серверов (Администрирование сервера 1С:Предприятия) и перейдите к свойствам рабочего сервера. На вкладке «Рабочие процессы» найдите параметр «Максимальное количество соединений».

| Параметр | Значение по умолчанию | Рекомендация при ограниченных ресурсах | |---|---|---| | Соединений на процесс | 256 | 64–128 | | Интервал перезапуска РП | Не задан | 3–6 часов | | Допустимый объём памяти | 0 (автоматически) | 70–80% от доступной RAM |

При уменьшении соединений с 256 до 64 на сервере с 400 активными сеансами вы получите не 2, а 7 рабочих процессов. Каждый из них будет потреблять меньше памяти и быстрее отвечать на запросы.

> Но есть обратная сторона: каждый дополнительный rphost.exe — это собственный кэш объектных данных. Суммарное потребление памяти кластером вырастет. На сервере с 32 ГБ RAM и 30 базами это критично — нужно искать баланс.

Перезапуск рабочих процессов

Рабочий процесс со временем деградирует — потребляет всё больше памяти, кэширует устаревшие объекты, фрагментирует управляемую кучу .NET. Платформа предлагает два сценария перезапуска:

Перезапуск по объёму памяти. Параметр «Временно допустимый объём памяти рабочих процессов» задаёт порог в мегабайтах. Когда процесс превышает этот порог, платформа завершает его и запускает новый. Проблема: потребление памяти неравномерно в течение дня. Утром, когда пользователи только зашли, процессы «худые». К обеду — «толстые». Фиксированный порог, который корректен утром, будет слишком низким к вечеру и вызовет лавину перезапусков.

Перезапуск по интервалу. Вы задаёте интервал в часах, и платформа перезапускает процессы регулярно. Проблема: если все процессы стартовали одновременно (а это типичная ситуация утром), они и перезапустятся одновременно. В момент массового перезапуска пользователи испытают «подвисание» на 15–30 секунд.

Практическое решение — разнести старт процессов по времени. Этого можно добиться, задав разное количество соединений на процесс для разных баз или запуская часть баз позже (например, фоновые базы бухгалтерии стартуют после загрузки основной базы учёта).

Скрипт мониторинга потребления памяти

Чтобы понять реальную картину, нужен автоматический сбор данных. Вот PowerShell-скрипт, который каждые 5 минут записывает потребление памяти всеми rphost.exe в CSV-файл:

Через пару дней анализа вы увидите, какие базы порождают самые «тяжёлые» процессы и в какое время суток происходит пик потребления. Эти данные — основа для дальнейшей настройки.

Лимитирование памяти на уровне ОС

Если платформенная настройка не справляется, можно ограничить потребление памяти процессами rphost.exe средствами Windows. Используйте групповые политики или утилиту SetProcessWorkingSetSize, но проще всего — создать задание планировщика, которое отслеживает процессы, превысившие порог:

Запускайте этот скрипт по расписанию каждые 10 минут. Это «последний рубеж» защиты — если платформа не перезапустила процесс сама, скрипт сделает это принудительно.

Практический сценарий

Сервер: 1 ядро Xeon, 32 ГБ RAM, 25 баз, 180 одновременных пользователей. Симптомы: к середине дня 3–4 процесса rphost потребляют по 4–5 ГБ каждый, пользователи жалуются на тормоза.

Шаг 1. Уменьшить соединения на процесс с 256 до 80. Результат: вместо 2–3 процессов стало 5–6, каждый потребляет не более 2 ГБ.

Шаг 2. Установить интервал перезапуска — 4 часа. Задать параметр «Временно допустимый объём памяти» — 3 ГБ.

Шаг 3. Запустить скрипт мониторинга. Через неделю анализа выяснилось, что две базы (УТ 11 и БП 3.0) дают 60% нагрузки на память.

Шаг 4. Для этих двух баз выделить отдельный рабочий процесс с лимитом 80 соединений, для остальных 23 баз — общий процесс с лимитом 128.

После настройки пик потребления памяти кластером снизился с 28 ГБ до 19 ГБ, а время отклика сервера — с 2.8 секунды до 0.9 секунды.

Стратегии распределения ресурсов между базами

Когда на одном сервере крутятся 20–30 баз, а памяти всего 32 ГБ, каждая база тянет одеяло на себя. Бухгалтерия запускает тяжёлый отчёт — и все остальные пользователи начинают «зависать». Регламентное задание в УТ формирует проводки — и CRM-менеджеры не могут открыть карточку клиента. Проблема не в том, что ресурсов мало, а в том, что они распределены хаотично: тяжёлые и лёгкие базы получают одинаковый доступ к памяти, процессору и диску.

Принцип приоритизации: не все базы равны

Первый шаг — инвентаризация. Нужно понять, какие базы критичны для бизнеса, а какие можно «задвинуть» на второй план. Разделите все базы на три категории:

Критичные. Базы, простой которых означает остановку бизнеса. Обычно это основная учётная система (ERP, УТ), кассовые базы, CRM. Для них — максимальный приоритет и гарантированные ресурсы.

Важные. Базы, которые нужны регулярно, но простой в 5–10 минут не критичен. Бухгалтерия, складской учёт, кадры. Средний приоритет.

Фоновые. Архивные базы, тестовые конфигурации, базы для разработки. Они не должны мешать остальным. Минимальный приоритет или ограничение по времени работы.

> Категоризация — это не формальность. Именно она определяет, как вы будете настраивать кластер, SQL Server и планировщик заданий. Без неё любая оптимизация будет «стрельбой по площадям».

Механизм назначения функциональности в кластере 1С

Платформа 1С позволяет привязывать базы к конкретным рабочим процессам через механизм назначения функциональности. Это ключевой инструмент изоляции нагрузки.

Откройте консоль кластера и перейдите к свойствам рабочего сервера. На вкладке «Назначения функциональности» создайте правила:

После этого тяжёлая УТ будет работать в своём процессе, а 15 лёгких баз — в другом. Когда УТ начнёт «жрать» память, она не заденет остальные.

На практике это выглядит так:

| Категория | Базы | Соединений на процесс | Количество РП | Лимит памяти | |---|---|---|---|---| | Критичные | УТ 11, ERP | 64 | 2 | 4 ГБ | | Важные | БП 3.0, ЗУП | 96 | 2 | 3 ГБ | | Фоновые | Архив, тесты | 128 | 1 | 2 ГБ |

> Важный нюанс: назначение функциональности работает только в редакции КОРП. В ПРОФ-версии этот механизм недоступен, и придётся использовать обходные пути — о них ниже.

Обходные пути для ПРОФ-редакции

Если у вас ПРОФ, можно добиться изоляции косвенно. Первый способ — разные пулы менеджеров кластера. Создайте два отдельных кластера на одном сервере (или два менеджера в одном кластере) и распределите базы между ними. Каждый менеджер будет управлять своими рабочими процессами независимо.

Второй способ — тонкая настройка количества соединений. Если вы знаете, что в тяжёлой базе сидят 40 пользователей, а в лёгких — 120, настройте для тяжёлой базы лимит 40 соединений на процесс, а для лёгких — 120. Тяжёлая база получит больше процессов, каждый из которых будет меньше по объёму памяти.

Третий способ — разнесение по времени. Запускайте регламентные задания тяжёлых баз в нерабочее время (ночь, раннее утро), а лёгкие базы — в штатном режиме. Это не изоляция в чистом виде, но существенно снижает пиковые нагрузки.

Распределение дисковых ресурсов

Память и процессор — не единственные ресурсы, которые нужно делить. Диск — часто узкое место, особенно на сервере с HDD или ограниченным набором SSD.

Правило первое: каждая база должна лежать на своём диске (или на своём LUN). Если все 25 баз на одном диске, один тяжёлый запрос к одной базе блокирует ввод-вывод для всех остальных.

Правило второе: файлы данных и журналов транзакций — на разных физических дисках. Это классическая рекомендация SQL Server, но для 1С она критична: журнал пишется последовательно, а данные читаются случайно. Совместное использование диска приводит к конфликтам ввода-вывода.

Правило третье: tempdb — на самом быстром диске. Если есть NVMe — отдайте его под tempdb. Именно tempdb используется для промежуточных результатов сортировок, хеш-соединений и группировок, которые 1С генерирует в огромных количествах.

Вот PowerShell-скрипт, который проверяет распределение баз по дискам:

Распределение CPU через планировщик заданий SQL Server

Если на сервере несколько баз и все они активно используют SQL Server, можно привязать каждую базу к определённым ядрам процессора через Affinity Mask. Это не даёт одной базе захватить все ядра.

Resource Governor позволяет задать не только привязку к ядрам, но и ограничение на потребление памяти и параллелизм для каждой группы. Это мощный инструмент, но он доступен только в Enterprise и Developer редакциях SQL Server.

Практический сценарий

Сервер: 8 ядер, 64 ГБ RAM, 28 баз, 220 пользователей. Симптомы: бухгалтерия жалуется на тормоза при закрытии месяца, остальные пользователи — на общую вялость.

Шаг 1. Инвентаризация: 3 критичные базы (УТ, ERP, CRM), 8 важных (бухгалтерия, кадры, склад), 17 фоновых (архивы, тесты).

Шаг 2. Создание двух пулов рабочих процессов: критичные — 64 соединения, остальные — 128.

Шаг 3. Перенос файлов данных критичных баз на SSD, фоновых — на HDD.

Шаг 4. Регламентные задания фоновых баз перенесены на 02:00–05:00.

Шаг 5. Настроен Resource Governor: критичные базы получают 4 ядра и 40% памяти, остальные — 4 ядра и 30%, tempdb — 30%.

Результат: время отклика критичных баз снизилось с 3.2 до 0.8 секунды, жалобы от бухгалтерии прекратились. Фоновые базы стали работать медленнее, но это некритично — они обслуживаются ночью.

---

Настройка SQL Server для работы с множеством баз

SQL Server — это мотор, на котором едет ваша 1С. И если мотор не настроен, он будет греться, гудеть и потреблять топливо впустую, даже если у вас мощный сервер. На одиночном сервере с десятками баз неправильная настройка SQL Server проявляется острее всего: каждая база конкурирует за одни и те же ресурсы — буферный пул, потоки ввода-вывода, блокировки.

Файловая структура: фундамент производительности

Первое, что нужно сделать — убедиться, что файлы данных, журналов и tempdb разнесены по разным дискам. Это не рекомендация, а обязательное условие для сервера с множеством баз.

Стандартная схема:

Если SSD всего один — разместите на нём данные и tempdb, а журналы оставьте на HDD. Журнал пишется последовательно, и HDD с этим справляется лучше, чем со случайным чтением данных.

Для tempdb рекомендуется создать несколько файлов — по одному на каждое физическое ядро процессора, но не более 8. Это снижает contention на страницах выделения (PFS, GAM, SGAM).

Все файлы tempdb должны быть одинакового размера — иначе SQL Server будет загружать их неравномерно.

Настройка памяти SQL Server

По умолчанию SQL Server забирает всю доступную оперативную память. На сервере, где крутится и 1С, и SQL Server, это недопустимо — рабочие процессы 1С начнут вытесняться на диск, и система «ляжет».

Правило: оставьте 1С минимум 4 ГБ + 10% от общего объёма RAM, а остальное отдайте SQL Server. Например, при 32 ГБ RAM: 1С — 8 ГБ, SQL Server — 24 ГБ.

> Не забудьте также установить минимальный объём памяти (min server memory), чтобы SQL Server не отдавал память ОС при снижении нагрузки. Значение — примерно 80% от максимального.

Настройка параллелизма

1С не любит параллельные запросы. Один тяжёлый запрос, разбитый на 8 потоков, может заблокировать все ядра и замедлить обработку остальных запросов. Поэтому для серверов 1С рекомендуется ограничивать параллелизм.

Значение max degree of parallelism = 2 означает, что один запрос займёт максимум 2 ядра. Значение cost threshold for parallelism = 50 (по умолчанию 5) — что параллелизм включается только для запросов стоимостью выше 50. Для 1С это оптимально: большинство запросов простые и не нуждаются в параллелизме, а сложные отчёты получат 2 потока вместо захвата всех ядер.

Регламентное обслуживание: статистика и индексы

Устаревшая статистика — одна из главных причин «тормозов» SQL Server. Оптимизатор выбирает неверный план выполнения, потому что не знает реального распределения данных в таблицах. Для 1С это особенно критично: таблицы документов и регистров постоянно растут, и статистика устаревает за часы.

Автоматическое обновление статистики включено по умолчанию, но оно срабатывает только при значительном изменении данных (порог 20% + 500 строк). Для больших таблиц это слишком редко.

Вот скрипт, который обновляет статистику по всем базам каждую ночь:

Для перестроения индексов используйте более избирательный подход — перестраивайте только индексы с фрагментацией выше 30%:

Настройка модели восстановления

По умолчанию базы данных создаются с моделью восстановления FULL. Это значит, что журнал транзакций растёт бесконечно, пока вы не сделаете бэкап лога. На сервере с 25 базами это может привести к тому, что диск с журналами заполнится за пару дней.

Если вам не нужна восстановление до произвольного момента времени (а для большинства баз 1С это так), переключите модель на SIMPLE:

Для критичных баз оставьте FULL, но настройте регулярные бэкапы лога:

Мониторинг ожиданий SQL Server

Когда SQL Server «тормозит», он не просто ждёт — он ждёт конкретного ресурса. Ожидания (wait stats) показывают, чего именно не хватает. Вот запрос, который покажет топ-10 ожиданий за последние сутки:

Ключевые типы ожиданий и их значение:

| Wait type | Что означает | Что делать | |---|---|---| | PAGEIOLATCH_* | Ожидание чтения страницы с диска | Ускорить диски, увеличить память | | CXPACKET | Ожидание параллельных потоков | Уменьшить MAXDOP | | LCK_* | Блокировки | Оптимизировать транзакции, индексы | | WRITELOG | Ожидание записи в журнал | Вынести журнал на быстрый диск | | SOS_SCHEDULER_YIELD | Ожидание свободного планировщика | Не хватает ядер CPU |

Если вы видите, что PAGEIOLATCH занимает первое место — значит, SQL Server больше времени тратит на ожидание данных с диска, чем на их обработку. Это прямой сигнал к ускорению дисков или увеличению памяти (чтобы больше данных помещалось в кэш).

Практический сценарий

Сервер: 4 ядра, 32 ГБ RAM, 25 баз, SQL Server Standard. Симптомы: пользователи жалуются на задержки 5–10 секунд при открытии форм, SQL Server потребляет 100% диска.

Шаг 1. Ограничена память SQL Server до 24 ГБ (8 ГБ оставлены для 1С).

Шаг 2. MAXDOP установлен в 2, cost threshold — 50.

Шаг 3. tempdb разбит на 4 файла по 2 ГБ на отдельном SSD.

Шаг 4. Запущено обновление статистики по всем базам — выявлено 3 базы с устаревшей статистикой на таблицах с миллионами записей.

Шаг 5. Модель восстановления переключена на SIMPLE для 20 некритичных баз.

Шаг 6. Настроен nightly-скрипт обновления статистики и перестроения индексов.

Результат: PAGEIOLATCH снизился с 45% до 12% общего времени ожиданий, время отклика сервера — с 4.1 до 1.3 секунды.

---

Диагностика производительности через технологический журнал

Когда пользователь говорит «1С тормозит», это как жалоба врачу «болит». Без диагностики вы не знаете, что именно болит и почему. Технологический журнал — это рентген вашего сервера: он показывает, что происходит внутри платформы, какие вызовы выполняются, сколько времени они занимают и где возникают ошибки. Но, как и рентген, его нужно уметь читать.

Включение технологического журнала

Технологический журнал включается через файл logcfg.xml, который лежит в каталоге конфигурации кластера. По умолчанию он отключён — и правильно, потому что запись журнала сама по себе消耗ирует ресурсы.

Создайте файл logcfg.xml в каталоге C:\Program Files\1cv8\conf\ (или в %APPDATA%\1C\1cv8\conf\ для пользовательских настроек):

Разберём, что здесь происходит:

> Не включайте технологический журнал на постоянной основе. Включайте на время диагностики (1–4 часа), анализируйте, выключайте. Постоянная запись снижает производительность на 5–15%.

Формат записей журнала

Каждая запись журнала — это строка в формате имя_свойства=значение, разделённая запятыми. Вот типичная запись события DBMSSQL:

Ключевые поля:

Если ExecuteSQLTime превышает 3000 мс — это «тяжёлый» запрос, на который стоит обратить внимание. Если Rows равен миллиону, а пользователь открывал список номенклатуры — значит, платформа вычитала всю таблицу, хотя нужно было 50 строк.

Анализ тяжёлых запросов

Самый быстрый способ найти проблемные места — отсортировать записи по ExecuteSQLTime и найти топ-20 самых долгих запросов. Вот PowerShell-скрипт, который парсит технологический журнал и выводит тяжёлые запросы:

Диагностика исключений

События EXCP — это ошибки и исключения. Они показывают не только проблемы с кодом, но и ситуации, когда платформа неожиданно завершает операцию. Частые исключения — признак нестабильности, которая может приводить к деградации рабочих процессов.

sql CREATE NONCLUSTERED INDEX IX_AccumRg12345_Period_Account ON dbo._AccumRg12345 (_Period, _AccountRRef) INCLUDE (_Dim1RRef, _Dim2RRef, _TurnoverDt, _TurnoverCt); ```

Шаг 5. Время формирования ОСВ снизилось с 40 до 3 секунд. Технологический журнал выключен.

---

Методы повышения отзывчивости интерфейса

Пользователь нажимает кнопку «Провести» — и ждёт. Секунду, две, пять. Он не знает, что происходит: зависла 1С, завис сервер, или просто идёт обработка. Через 10 секунд он нажимает кнопку ещё раз. И ещё. В итоге — дублирование документов, блокировки, и общее ощущение, что «1С — это медленно». Отзывчивость интерфейса — это не абстрактная метрика, а субъективное ощущение пользователя. И на него влияют не только серверные ресурсы, но и десяток мелочей, о которых администраторы часто забывают.

Где живёт проблема: клиент, сервер или сеть

Прежде чем оптимизировать, нужно понять, на каком этапе возникает задержка. Задержка интерфейса 1С складывается из трёх компонентов:

Если пользователь сидит через RDP на терминальном сервере — сетевая задержка минимальна, и проблема почти всегда на стороне сервера. Если пользователь работает с тонким клиентом через VPN — сеть может быть главным узким местом.

> Быстрый тест: откройте пустую базу (демонстрационную) на том же сервере. Если она работает шустро — проблема не в сервере и не в сети, а в конкретной базе или конфигурации.

Оптимизация серверной части: что уже сделано

В предыдущих статьях мы настраивали рабочие процессы, SQL Server и распределение ресурсов. Все эти меры напрямую влияют на отзывчивость: чем быстрее сервер отвечает, тем меньше пользователь ждёт. Но есть ещё несколько серверных настроек, которые специфически влияют на интерфейс.

Разделение сеансов пользователей и фоновых заданий. Если регламентное задание запускается в том же рабочем процессе, что и пользователи, оно может «заморозить» их сеансы на десятки секунд. В редакции КОРП это решается через назначение функциональности (как описано в статье о распределении ресурсов). В ПРОФ — через настройку расписания регламентных заданий на нерабочее время и ручной контроль.

Ограничение количества сеансов на процесс. Как мы выяснили, уменьшение соединений на процесс с 256 до 64–80 даёт больше рабочих процессов, каждый из которых быстрее реагирует на запросы. Это напрямую повышает отзывчивость: пользователь не ждёт, пока процесс обслужит 255 других сеансов.

Клиентская сторона: тонкий vs толстый клиент

Выбор режима клиента — один из самых недооценённых факторов отзывчивости.

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

Тонкий клиент выполняет почти весь код на сервере. Это снижает требования к рабочей станции, но увеличивает нагрузку на сервер и сеть.

Для сервера с ограниченными ресурсами тонкий клиент предпочтительнее: он генерирует меньше сеансовых данных, потребляет меньше памяти на сервере и позволяет централизованно контролировать нагрузку. Но если пользователи работают через медленный канал — тонкий клиент может быть медленнее толстого из-за постоянных обращений к серверу.

Практическое правило: если пользователи на локальной сети (1 Гбит) — используйте тонкий клиент. Если через VPN с каналом менее 50 Мбит — рассмотрите RDP с тонким клиентом на терминальном сервере.

Настройка кэширования на стороне клиента

Платформа 1С кэширует данные на стороне клиента в каталоге %APPDATA%\1C\1cv8\. Со временем этот кэш разрастается и может замедлять работу: платформа тратит время на чтение устаревших данных из кэша вместо получения актуальных с сервера.

Автоматическая очистка кэша не предусмотрена. Решение — скрипт, который очищает кэш при входе пользователя:

Мониторинг отзывчивости в реальном времени

Чтобы понять, насколько отзывчив ваш сервер прямо сейчас, нужно метрику, которую можно измерить. Платформа 1С не даёт встроенных инструментов для этого, но можно использовать косвенные признаки.

Время отклика сервера — метрика, которую можно получить из технологического журнала (события SCALL). Среднее время серверного вызова менее 500 мс — нормально, 500–2000 мс — стоит обратить внимание, более 2000 мс — проблема.

Количество активных сеансов vs количество рабочих процессов. Если на 3 рабочих процесса приходится 200 активных сеансов — каждый процесс обслуживает 67 сеансов одновременно. Это слишком много. Целевое значение — 20–40 сеансов на процесс.

Вот скрипт, который проверяет текущее соотношение:

Практический сценарий

Сервер: 4 ядра, 32 ГБ RAM, 15 баз, 120 пользователей. Симптомы: пользователи жалуются, что при проведении документов интерфейс «зависает» на 8–15 секунд. При этом сервер загружен на 40% CPU и 60% RAM.

Шаг 1. Проверка: 2 рабочих процесса, 120 сеансов — по 60 на процесс. Слишком много.

Шаг 2. Уменьшены соединения на процесс с 256 до 80. Рабочих процессов стало 4, по 30 сеансов на процесс.

Шаг 3. Включён технологический журнал на 2 часа. Обнаружено: 3 тяжёлых запроса к регистру накопления при проведении документов (ExecuteSQLTime 4000–7000 мс).

Шаг 4. На терминальном сервере очищен кэш 1С, отключены визуальные эффекты.

Шаг 5. Настроены таймауты неактивных сеансов RDS — 15 минут.

Результат: время проведения документов снизилось с 12 до 2 секунд, жалобы на «зависания» прекратились. Среднее время серверного вызова — 350 мс.

---