В процессе эксплуатации систем на базе 1С:Предприятие через веб-сервер IIS системные администраторы часто сталкиваются с внезапным снижением производительности. Если вы хотите точно определить источник проблем, имеет смысл выполнить замер производительности контура 1С и поиск узких мест, однако часто симптомы говорят сами за себя: 100% нагрузка на дисковую подсистему, зависания у всех пользователей и стремительный рост лог-файлов IIS (иногда до 70 ГБ и выше за несколько часов). Проанализируем эту ситуацию, выясним причины аномалии и разберем по шагам методы ее устранения.
Рассмотрим детально, что происходит «под капотом» системы. В современных версиях платформы 1С (начиная с 8.3.25 и выше, включая 8.3.27) для взаимодействия тонкого клиента с сервером через HTTP используется механизм Long Polling. Клиент отправляет специальный запрос e1csys/cn с параметром cmd=poll. Этот запрос предназначен для получения уведомлений от сервера (например, сообщений системы или обновлений динамических списков).
В нормальном состоянии такой запрос имеет длительный таймаут (обычно timeout=60000, то есть 60 секунд). Сервер «держит» соединение открытым, пока не появится информация для передачи. Однако, если возникает ошибка конфигурации веб-сервера или баг платформы, сервер вместо ожидания мгновенно возвращает ответ с HTTP-статусом 301 (Moved Permanently). Клиент, получив такой ответ, интерпретирует его как необходимость немедленного повторного обращения по «новому» адресу. В результате возникает бесконечный цикл: миллионы запросов в минуту забивают очередь диска записью в логи и парализуют работу сервера. Для минимизации последствий таких зависаний некоторые администраторы настраивают автоматический перезапуск рабочих процессов (rphost) кластера 1С, но в данном случае необходимо устранять первопричину редиректа.
Одной из самых коварных причин является чувствительность IIS к регистру или именованию базы. Выясним, как это влияет на работу. Если при публикации в консоли IIS или в файле default.vrd имя базы указано как UNF, а в настройках подключения у пользователей (в списке баз) адрес прописан как http://server/unf (в нижнем регистре), IIS может инициировать редирект для приведения URL к каноническому виду. Чтобы исключить подобные ошибки на клиентах, удобно использовать лаунчер для 1C с проверкой доменной авторизации, который унифицирует параметры запуска.
Разберем, что нужно проверить в первую очередь:
Еще одна классическая ситуация — отсутствие символа / в конце строки подключения. Рассмотрим пример: если в настройках базы указано http://myserver/base, платформа при выполнении низкоуровневых запросов к e1csys может ожидать адрес http://myserver/base/. В некоторых конфигурациях IIS это вызывает автоматическое перенаправление (301) на адрес со слешем. В сочетании с механизмом poll это порождает тот самый шторм запросов.
Проанализируем ситуацию, описанную в теме форума. Пользователь столкнулся с проблемой на версии 8.3.27.1719. В ранних сборках этой ветки был зафиксирован баг, связанный с некорректной обработкой сеансовых данных при работе через IIS. Платформа могла терять контекст и отправлять редиректы там, где должен был быть ответ 200 OK.
Для решения этой проблемы рассмотрим последовательность действий — поможет мониторинг ошибок 1С с уведомлением в Telegram:
8.3.27.1989 или выше.webinst.В сообщении №12 упоминается смена варианта получения ошибок. Это критически важный момент для снижения нагрузки на диск. Рассмотрим, как отредактировать файл публикации default.vrd, который обычно находится в папке C:\inetpub\wwwroot\ИмяБазы\.
Найдем секцию <debug>. Если в ней включены избыточные логи или специфические режимы передачи дампов ошибок, это может провоцировать IIS на запись огромных массивов данных при каждом сбойном запросе. Попробуем привести параметры к стандартному виду или отключить детальный дебаг на стороне публикации, если он не требуется для разработки.
Пример структуры файла default.vrd с корректными настройками протокола:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/UNF"
ib="File="C:\Base\UNF";">
<httpServices publishByDefault="true"/>
<standardOdata enable="true"/>
</point>
Иногда помогает явное указание версии протокола обмена. Для этого в корень тега <point> можно добавить атрибут communicationProtocolVersion="2" или "1", чтобы стабилизировать соединение между клиентом и сервером.
Выясним влияние системных настроек ОС. Windows Server 2019 по умолчанию активно использует HTTP/2. Этот протокол имеет свои особенности реализации мультиплексирования запросов. Замечено, что механизм Long Polling в 1С иногда некорректно работает поверх HTTP/2, что приводит к обрывам «длинных» запросов. Сервер возвращает ошибку, клиент делает редирект, и цикл замыкается.
В качестве диагностической меры попробуем принудительно переключить сайт на протокол HTTP/1.1:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.EnableHttp2Tls и EnableHttp2Cleartext со значением 0.Если вы прямо сейчас наблюдаете рост логов и тормоза системы, выполните следующие шаги:
Шаг 1. Моментальная остановка записи логов.
Чтобы диск не переполнился, временно отключите логирование в IIS. Выберите сайт -> «Logging» -> «Disable». Это даст вам время на анализ без риска остановки всей ОС из-за нехватки места.
Шаг 2. Очистка кэша и перепубликация.
Попробуйте удалить текущую публикацию через конфигуратор и создать ее заново в новый каталог. Если у вас много сервисов, поможет специализированный Публикатор 1С, позволяющий публиковать базы с комфортом и избегать ошибок ручной настройки. Иногда в папке публикации остаются старые версии web.config или default.vrd, которые конфликтуют с новой платформой.
Шаг 3. Проверка полнотекстового поиска.
Как советовали в сообщении №2, на время диагностики стоит отключить регламентное задание «Полнотекстовый поиск». В файловых базах при работе через веб-сервер оно может создавать дополнительную нагрузку на дисковые операции чтения, мешая нормальной обработке HTTP-запросов. Рекомендуется также проверить информацию по рабочему каталогу центрального сервера (srvinfo), чтобы оценить, сколько места занимают индексы ППД и не требуется ли их очистка.
Шаг 4. Анализ логов специализированным ПО.
Для открытия гигантских файлов логов не используйте Блокнот. Рекомендуем воспользоваться инструментами типа LogViewPlus или командами PowerShell (например, Get-Content -Tail 100), чтобы увидеть последние записи в реальном времени. Если вы видите бесконечные строки с e1csys/cn и кодом 301 — значит, вы столкнулись именно с описанной выше проблемой редиректа — решить задачу поможет анализ HTTP-запросов и кодов ошибок. Если же логи IIS чисты, стоит проанализировать SQL сервер глазами 1С-ника, чтобы исключить проблемы на уровне СУБД.
Итог: Сочетание обновления платформы до актуального стабильного билда (8.3.27.1989+) и тщательная проверка URL-адресов на соответствие регистру и наличие завершающего слеша позволяют полностью устранить данную аномалию.