Ситуация, когда современное и мощное оборудование (процессоры с высокой частотой, SSD-накопители, большой объем ОЗУ) не обеспечивает комфортную работу в 1С, встречается довольно часто. Особенно остро эта проблема проявляется в конфигурации Управление торговлей 11 (УТ 11). Разберем по шагам, почему возникают зависания, как продиагностировать «узкие места» и какие изменения помогут ускорить систему.
Рассмотрим исходные данные: процессор AMD Ryzen 5 2400G с частотой до 3.9 ГГц и 32 ГБ оперативной памяти. На первый взгляд, это отличные показатели для базы объемом 4.5 ГБ и 6–9 пользователей. Однако важно понимать специфику работы 1С в терминальном режиме. Проанализируем ключевой момент: база находится в файловом режиме. Именно здесь кроется основная причина проблем.
В файловой базе 1С при записи любого документа происходит блокировка всей таблицы, к которой обращается пользователь. Если один сотрудник проводит тяжелый документ, остальные 8 человек выстраиваются в очередь. На мощном процессоре это выглядит как минимальная загрузка (1–5%), так как ядра простаивают в ожидании снятия блокировки с файла 1Cv8.1cd. Проверим производительность с помощью теста Гилева. Результат в 39 попугаев считается «хорошим», но он отражает скорость работы одного пользователя. При коллективной работе этот показатель деградирует в геометрической прогрессии.
Прежде чем менять архитектуру базы, проверим настройки серверной ОС и аппаратной части. Процессоры Ryzen чувствительны к режимам энергосбережения. Выясним, не занижает ли система частоты в моменты ожидания.
C-States и Cool'n'Quiet. Это заставит процессор всегда работать на максимальной тактовой частоте, исключая просадки производительности.Для конфигурации УТ 11 использование файлового режима при наличии более 5 пользователей — это «путь в тупик». Система постоянно выполняет фоновые задания, обновляет кэши и пересчитывает остатки. Единственным надежным решением станет переход на клиент-серверный вариант.
Рассмотрим два пути:
Если переход на SQL по каким-то причинам невозможен немедленно, попробуем промежуточный вариант — публикацию базы на веб-сервере (Apache или IIS). Проанализируем, что это дает:
Работа через веб-сервер меняет механизм обращения к файлу базы данных. Вместо прямого доступа по протоколу SMB (который крайне чувствителен к задержкам сети и WiFi), запросы обрабатываются веб-сервисом. Это значительно повышает стабильность работы в терминале и снижает вероятность повреждения базы при аварийном завершении сеанса пользователя.
Конфигурация УТ 11 перенасыщена функционалом, который в файловом режиме создает колоссальную нагрузку. Выполним следующие настройки:
Чтобы точно определить, кто или что блокирует базу, настроим минимальный Технологический журнал. Создадим файл logcfg.xml в папке с настройками платформы:
<config xmlns="http://v8.1c.ru/7.4/config">
<log location="C:\1C_Logs" history="24">
<event>
<eq property="Name" value="DBV8DBEng"/>
</event>
<event>
<eq property="Name" value="TLOCK"/>
</event>
</log>
</config>
Анализ этих логов покажет события TLOCK — это и есть те самые ожидания блокировок. Если в логах много таких записей, значит, аппаратная мощность сервера ни при чем, и проблема чисто программная (файловый режим).
Посмотрим на дисковый массив RAID1 из SSD Samsung 860 Pro. Программные RAID-контроллеры иногда могут вносить задержки при записи. Важно убедиться, что Windows Defender или сторонний антивирус не сканируют файл 1Cv8.1cd при каждом обращении. Добавим в исключения антивируса:
*.1cd, *.1cl, *.vrd.1cv8.exe, 1cv8c.exe.Также полезно вынести временные файлы пользователей из системного раздела на отдельный физический диск. Для этого изменим переменные среды TEMP и TMP для пользователей терминала.
Подведем итог нашему исследованию. Файловая УТ 11 — это тяжелое решение для многопользовательской работы. Основные шаги для исправления ситуации:
После выполнения этих действий даже при 9 активных пользователях работа станет плавной, а ресурсы процессора Ryzen будут использоваться эффективно.