Проблема резкого роста нагрузки на центральный процессор (ЦП) при переходе на новые версии платформы 1С:Предприятие 8.3 — это ситуация, с которой часто сталкиваются администраторы систем, где используется файловый вариант информационной базы в терминальной среде (RDP). Особенно остро это проявляется, когда количество одновременно работающих пользователей приближается к 20. В данной статье мы подробно разберем причины возникновения этой проблемы, проанализируем конкретную ошибку платформы и рассмотрим комплекс мер по оптимизации системы.
Рассмотрим ситуацию, описанную в технической документации и подтвержденную практикой. Начиная с версий 8.3.17.1851 и выше, пользователи начали замечать, что даже при простое системы загрузка процессора может достигать 100%. Выясним причину этого явления. Основная проблема кроется в ошибке под номером 10225725 ("Фоновая индексация журнала регистрации").
Суть проблемы заключается в следующем: в файловом варианте базы, когда она размещена на сетевом ресурсе или используется в многопользовательском терминальном режиме, запущенные фоновые процессы индексации постоянно обращаются к одним и тем же файлам индекса журнала регистрации. Синхронизация этих представлений между разными сеансами требует колоссальных затрат процессорного времени из-за постоянных блокировок файловой системы. Проанализируем, в каких версиях эта ошибка была исправлена. Согласно официальным данным, исправления вошли в следующие релизы:
Практика показывает, что стабильным решением для конфигурации «Бухгалтерия предприятия 3.0» является установка платформы версии 8.3.18.1698 или выше. Это позволяет устранить паразитный расход ресурсов на бесконечную переиндексацию логов.
Разберем вопрос совместимости. Часто возникает дилемма: конфигурация (например, ЗУП 3.1) требует версию не ниже 8.3.17, а текущая версия платформы вызывает тормоза. Посмотрим на рекомендации:
Проанализируем еще один важный аспект. В современных версиях 1С по умолчанию используется формат журнала регистрации SQLite (файл с расширением .lgd). В условиях терминального сервера, когда 20 человек одновременно записывают события в один файл базы данных SQLite, возникают серьезные очереди на запись. Это напрямую коррелирует с загрузкой ЦП.
Рассмотрим по шагам, как можно снизить нагрузку, вернувшись к старому текстовому формату (.log):
Выясним, как графическая подсистема влияет на сервер. Платформа 8.3.17+ активно использует возможности видеокарты для отрисовки интерфейса. Однако на терминальном сервере (Windows Server 2019) полноценной видеокарты чаще всего нет, и функции отрисовки ложатся «плечами» на центральный процессор. Чтобы разгрузить ЦП, рекомендуется отключить аппаратное ускорение.
Для этого мы можем внести изменения в файл conf.cfg, расположенный в каталоге установки платформы (обычно C:\Program Files\1cv8\conf). Добавим или изменим параметр:
HardwareAcceleration=0
Также полезно добавить параметр, отключающий сбор счетчиков производительности, которые тоже могут нагружать систему в многопользовательском режиме:
EnablePerformanceCounters=0
Проанализируем работу защитных систем. Windows Server 2019 по умолчанию имеет включенный Windows Defender. При работе 20 пользователей в файловой базе 1С генерируется огромное количество дисковых операций. Антивирус пытается проверить каждый доступ к файлам .1CD и временным файлам в папке AppData.
Что необходимо сделать:
*.1CD, *.1CL, *.lgp, *.lgd, *.cdn.1cv8.exe, 1cv8c.exe.C:\Users\*\AppData\Local\1C и C:\Users\*\AppData\Roaming\1C.Посмотрим на внутренние процессы самой «Бухгалтерии 3.0». В файловом варианте регламентные задания выполняются в сеансе одного из активных пользователей. Если запускается «Обновление индекса полнотекстового поиска», этот сеанс начинает потреблять максимум ресурсов процессора, замедляя работу остальных 19 человек.
Если пользователи не используют глобальный поиск по всей базе (строка поиска в верхней части программы), рекомендуется отключить полнотекстовый поиск:
Мы проанализировали основные причины высокой загрузки ЦП и нашли решение. Главным шагом является обновление платформы до версии 8.3.18.1698 или выше для устранения багов индексации. Однако стоит помнить, что 20 активных пользователей для файлового режима — это предел стабильной работы.
Рассмотрим долгосрочную перспективу: при такой нагрузке единственным по-настоящему надежным решением станет переход на клиент-серверный вариант работы (SQL). Это позволит вынести всю тяжелую нагрузку по обработке данных на сервер СУБД, а пользователи в терминале будут работать с «легким» тонким клиентом, что снизит нагрузку на ЦП сервера в несколько раз.