← На главную

При эксплуатации тяжелых конфигураций, таких как 1С:Управление производственным предприятием (УПП) в режиме толстого клиента, системные администраторы часто сталкиваются с деградацией производительности и полным «зависанием» серверов. Рассмотрим ситуацию, когда на терминальном сервере с 64 ГБ оперативной памяти работают около 100 пользователей, и выясним, почему текущих мощностей катастрофически не хватает, а также разберем по шагам методы решения этой проблемы.

Анализируем нормы потребления оперативной памяти

Разберем типичную математику потребления ресурсов. Для режима «толстого клиента» 1С характерно выполнение большей части кода и построение интерфейсных форм непосредственно на стороне клиента (в данном случае — в сессии пользователя на терминальном сервере). В отличие от тонкого клиента, толстый клиент крайне требователен к объему RAM.

Проанализируем реальные цифры:

• Минимальный порог: Даже при выполнении простых операций один сеанс 1С занимает от 800 МБ до 1.2 ГБ.
• Средняя нагрузка: При открытии нескольких журналов документов, формировании типовых отчетов и работе с почтой потребление вырастает до 1.5–2 ГБ на пользователя.
• Тяжелые отчеты: Построение крупных аналитических панелей или сложных ведомостей в УПП может мгновенно «отъесть» до 5 ГБ в рамках одного сеанса.

Таким образом, для 100 пользователей минимально необходимый объем только под процессы 1С составляет: 100 пользователей * 1.5 ГБ = 150 ГБ. С учетом потребностей самой операционной системы Windows Server и служебных процессов, комфортный объем памяти для такой нагрузки начинается от 192 ГБ или даже 256 ГБ. Имеющиеся 64 ГБ позволяют выделить лишь по 600 МБ на человека, что вынуждает систему постоянно использовать файл подкачки.

Выясняем причину зависаний: Трэшинг и очереди к диску

Когда оперативная память занята на 100%, операционная система начинает активно перемещать данные из быстрой оперативной памяти в медленный файл подкачки на диске (процесс swapping). Проанализируем, к чему это приводит:

1. Дисковая очередь: Процессор вынужден ждать, пока данные прочитаются с диска, что порождает высокую очередь (Disk Queue Length). Визуально это выглядит как «замерзание» интерфейса 1С у всех пользователей одновременно.

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

Проверим состояние системы через монитор ресурсов. Если счетчик Memory\Pages/sec стабильно выше 100, а средняя очередь к диску превышает 2, сервер официально находится в состоянии ресурсного голода.

Горизонтальное масштабирование (ферма серверов)

Рассмотрим вариант, предложенный опытными администраторами: вместо одного сверхмощного сервера использовать несколько менее мощных. Это называется созданием терминальной фермы (RDS Farm).

Разберем преимущества такого подхода:

1. Отказоустойчивость: Выход из строя одного сервера затронет только 25% пользователей, а не всех 100.
2. Снижение конкуренции за ресурсы: Операционной системе гораздо проще управлять 25-30 сеансами, чем сотней. Снижается нагрузка на графическую подсистему и процессы dwm.exe (Desktop Window Manager).
3. Лимиты разрядности: Если вы используете 32-битную версию платформы 1С, она не может адресовать более 2-3 ГБ на процесс. Распределение пользователей по разным серверам помогает избежать фрагментации памяти всего сервера.

Рекомендуемая конфигурация в вашем случае — 4 сервера по 25–30 пользователей на каждом, с объемом памяти не менее 64–96 ГБ на единицу.

Оптимизация подсистемы печати и графики

Часто причиной «подвисаний» на терминалах становятся не только расчеты 1С, но и периферийные процессы. Выясним, как это оптимизировать:

Проблема с принтерами: Автоподключение (маппинг) клиентских принтеров через механизм Easy Print создает огромную нагрузку на службу печати и процессор. Проанализируем рекомендации: необходимо отключить автоматический проброс принтеров в настройках RDP и установить драйверы наиболее популярных моделей локально на сервер или использовать специализированные решения (например, универсальные драйверы печати).

Графическое ускорение: В современных версиях Windows Server каждый сеанс требует ресурсов для отрисовки интерфейса. Для оптимизации следует:

• Отключить визуальные эффекты в настройках производительности Windows («Обеспечить наилучшее быстродействие»).
• Через групповые политики (GPO) ограничить глубину цвета до 15 или 16 бит.
• Отключить аппаратное ускорение графики для RDP-сессий.

Борьба с утечками памяти в платформе 1С

Разберем важный технический аспект: платформы 1С (особенно версии 8.3.25 и выше) имеют особенности работы с памятью. Память, захваченная под большой табличный документ или сложный отчет, может не возвращаться операционной системе сразу после закрытия формы. Она остается «зарезервированной» за сеансом пользователя до его полного завершения.

Проанализируем меры противодействия:

1. Ограничение времени сеанса: Настройте автоматическое завершение (log off) отключенных (disconnected) сессий. Часто пользователи просто закрывают «крестиком» окно терминала, оставляя активный процесс 1С, который продолжает потреблять память.
2. Регулярная очистка кэша: Кэш 1С в папке AppData\Local\1C со временем разрастается. Рекомендуется настроить скрипты очистки старого кэша при входе пользователя.
3. Антивирусные исключения: Убедитесь, что антивирус не сканирует временные файлы 1С. Добавьте в исключения процессы 1cv8.exe, 1cv8c.exe и расширения .1cd, .1cl.

Итоги и рекомендации

Для стабильной работы 100 пользователей в УПП на одном сервере текущих 64 ГБ недостаточно. Рассмотрим план действий по исправлению ситуации:

1. Срочное увеличение ОЗУ: Доведите объем памяти до 128 ГБ как временную меру, или до 192+ ГБ для полноценной работы.

2. Разделение нагрузки: Если бюджет позволяет, разверните 3 дополнительные виртуальные машины и настройте RD Connection Broker для распределения нагрузки.

3. Проверка дисков: Убедитесь, что база 1С, файлы подкачки и профили пользователей находятся на быстрых SSD/NVMe накопителях. Обычные HDD не справятся с интенсивным вводом-выводом при такой плотности пользователей.

4. Мониторинг копрокода: Если после добавления памяти она продолжает «улетать» за считанные часы, проанализируйте работу программистов. Возможно, в конфигурации есть неоптимальные запросы или циклы, которые порождают создание огромных временных таблиц в памяти.