Почему постоянно зависает IIS при работе с базами 1С и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Работа 1С:Предприятия через веб-сервер IIS (Internet Information Services) — это стандартное решение для организации удаленного доступа, особенно когда речь идет о файловых базах. Однако многие системные администраторы и программисты сталкиваются с неприятной ситуацией: веб-сервер начинает «капризничать», рабочие процессы зависают, а пользователи теряют соединение. Часто проблема проявляется локально — зависает только одна база из нескольких опубликованных, но из-за архитектуры IIS приходится перезапускать весь сервер, прерывая работу всех сотрудников.

В этой статье мы подробно разберем, почему это происходит, проанализируем основные причины нестабильности и предложим пошаговый план по приведению системы в рабочее состояние.

Разберем основную причину: архитектура пулов приложений

Проанализируем ситуацию, описанную в первом сообщении: зависает одна база, но приходится перезапускать весь веб-сервер. Выясним причину такого поведения. По умолчанию при публикации нескольких баз 1С через консоль управления IIS они часто попадают в один и тот же Пул приложений (обычно DefaultAppPool). Это означает, что все базы работают внутри одного процесса w3wp.exe.

Если в одной из баз происходит критическая ошибка, утечка памяти или бесконечный цикл в фоновом задании, этот процесс блокируется целиком. Рассмотрим, как это исправить. Для обеспечения стабильности нам необходимо изолировать базы друг от друга. Выполним следующие действия:

  1. Откроем Диспетчер служб IIS.
  2. Перейдем в раздел Пулы приложений и создадим для каждой информационной базы отдельный пул (например, 1C_Trade и 1C_Retail).
  3. В разделе Сайты найдем наши опубликованные приложения 1С.
  4. Для каждого приложения выберем «Основные настройки» и укажем соответствующий персональный пул.

Теперь, если зависнет «Розница», процесс «Управления торговлей» продолжит работу в штатном режиме, а администратору достаточно будет перезапустить только один конкретный пул, не выгоняя всех пользователей из системы. Для удобной настройки и администрирования пулов и веб-сервера можно использовать инструмент для управления веб-публикациями 1С.

Проанализируем влияние полнотекстового поиска

Как отмечают участники обсуждения (сообщения №4, №7, №21), одной из самых частых причин «мертвого» зависания является регламентное задание Обновление индекса полнотекстового поиска. В платформе 1С 8.3.6 и более поздних версиях была замечена ошибка: при интенсивной работе веб-сервера во время индексации происходит аварийное завершение или блокировка потока.

Посмотрим на ситуацию практически. Индексация — это ресурсоемкий процесс, который активно работает с файловой системой. В файловом варианте базы 1С это создает огромную нагрузку на механизм блокировок. Если в этот момент пользователь отправляет тяжелый HTTP-запрос, система может войти в клинч.

Решение проблемы:

Рассмотрим вариант переноса этого задания на время минимальной нагрузки. Вместо автоматического обновления каждые несколько минут, настроим его запуск один раз в сутки (например, в 3 часа ночи). Если полнотекстовый поиск в программе не является критически важным для оперативной работы, попробуем его полностью отключить в меню «Администрирование» — «Поддержка и обслуживание» — «Управление полнотекстовым поиском».

Выясним причину зависания из-за разрядности платформы

Особое внимание стоит уделить сообщению №35, где автор утверждает, что переход на 64-разрядную версию 1С решил все проблемы. Разберем, почему это сработало. 32-битный рабочий процесс IIS (w3wp.exe) имеет жесткое ограничение на использование оперативной памяти — не более 2–4 ГБ. При работе с тяжелыми конфигурациями, такими как УТ 11 или ERP, формирование сложного отчета или выполнение фонового задания может мгновенно «съесть» этот лимит.

Когда память заканчивается, 32-битный процесс не всегда корректно завершается. Часто он просто перестает отвечать на новые запросы (зависает). Переход на 64-битную платформу снимает эти ограничения, позволяя процессу использовать всю доступную оперативную память сервера.

Важный технический момент: если вы используете 32-битную версию 1С на 64-битной Windows, обязательно проверьте настройки пула приложений в IIS. Параметр Разрешить 32-разрядные приложения (Enable 32-Bit Applications) должен стоять в значении True. Однако для стабильности мы крайне рекомендуем переходить на 64-битную платформу 1С.

Настроим права доступа и временные папки

Часто зависания связаны с тем, что рабочий процесс IIS не может записать временные данные. Проанализируем права доступа. Процесс IIS работает от имени специально созданной учетной записи (например, IIS AppPool\ВашеИмяПула). Этой учетной записи необходимы полные права (Full Control) на следующие объекты:

  1. Каталог с самой файловой базой данных (где лежит 1Cv8.1CD).
  2. Системную папку временных файлов C:\Windows\Temp. 1С активно использует её для формирования веб-отчетов.
  3. Папку с установленной платформой 1С (особенно на чтение и выполнение).

Если папка Temp переполнена (содержит сотни тысяч мелких файлов), IIS может «зависать» на этапе попытки создания нового временного файла. Регулярная очистка этой папки — залог здоровья веб-сервера.

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

Если стандартные средства не помогают, нам придется «заглянуть под капот» и собрать Технологический журнал (ТЖ). Как правильно заметил пользователь в сообщении №24, без логов диагностика превращается в гадание. Создадим в папке с настройками 1С (обычно C:\Program Files\1cv8\conf) файл logcfg.xml со следующим содержанием:


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="C:\1C_Logs" history="24">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <property name="All"/>
  </log>
</config>

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

Подведем итоги: чек-лист стабильности

Для того чтобы забыть о постоянных перезагрузках IIS, выполним комплексную проверку системы по следующим пунктам:

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

← На главную