← На главную

При работе с веб-сервисами и HTTP-сервисами в платформе 1С:Предприятие, особенно в режиме активной отладки, многие пользователи сталкиваются с критической проблемой: процесс отладчика dbgs.exe начинает разрастаться, потребляя чрезмерные объемы оперативной памяти сервера. Это приводит к значительному снижению производительности всей системы, вытеснению других важных процессов (например, СУБД) из памяти и, в конечном итоге, к сбоям или полной остановке работы сервера 1С. Мы разберем эту проблему и предложим проверенные решения, а также рассмотрим сопутствующие аспекты.

Суть проблемы: зависание "предметов отладки"

Основная причина заключается в особенностях функционирования механизма HTTP-отладки в 1С:Предприятии. Когда клиент (будь то мобильное приложение, другая база 1С или внешняя система) обращается к опубликованному веб-сервису или HTTP-сервису, и при этом включен режим отладки, для каждого такого обращения в кластере серверов 1С создается так называемый "предмет отладки". В идеальном сценарии, после завершения запроса и сеанса отладки, этот предмет должен быть корректно уничтожен, а связанные с ним ресурсы – освобождены.

Однако, как показывает практика и многочисленные обсуждения, предметы отладки не всегда корректно завершаются и очищаются. Это особенно актуально, если соединение прерывается нештатно, клиент не закрывает его должным образом, или если логика работы отладчика неверно определяет завершение сессии. В результате, эти "висячие" предметы отладки накапливаются, и каждый из них продолжает удерживать часть памяти процесса dbgs.exe. Со временем, при большом количестве запросов, процесс отладчика может разрастись до десятков гигабайт, что критически сказывается на стабильности работы сервера.

Например, пользователи сообщают, что за день в списке отладки могут повисать тысячи соединений, а процесс dbgs.exe разрастается до 55-60 ГБ за полдня, что приводит к вытеснению из памяти даже СУБД, такой как SQL Server. Перезапуск веб-сервера (Apache или IIS) или даже службы агента сервера 1С 1C:Enterprise 8.3 Server Agent не всегда полностью решает проблему, поскольку "висячие" предметы отладки могут сохраняться.

Влияние параметра reuseSessions

Ключевую роль в возникновении и усугублении этой проблемы играет параметр reuseSessions, который указывается в файле публикации веб-сервиса или HTTP-сервиса (например, default.vrd или другом файле с расширением .vrd). Этот параметр управляет поведением сервера 1С относительно повторного использования существующих сеансов для обработки входящих запросов.

1. reuseSessions="autouse" (значение по умолчанию): Данное значение предписывает серверу 1С по возможности повторно использовать уже существующие сеансы для обработки новых запросов. Теоретически, это должно повышать производительность, так как сокращаются накладные расходы на создание нового сеанса для каждого запроса. Однако, в контексте отладки веб-сервисов, именно это поведение может конфликтовать с корректным завершением предметов отладки. Логика переиспользования сеансов может приводить к тому, что старые предметы отладки не всегда своевременно уничтожаются, даже если сеанс, к которому они были привязаны, уже неактивен. Это способствует их накоплению в памяти dbgs.exe.
2. reuseSessions="dontuse": При установке этого значения сервер 1С принудительно создает новый сеанс для каждого входящего запроса к веб-сервису/HTTP-сервису и не пытается его переиспользовать. После завершения обработки запроса, сеанс с большей вероятностью будет корректно завершен, а с ним и соответствующий предмет отладки. Именно это изменение, как показывают обсуждения, является наиболее эффективным решением проблемы зависания предметов отладки.

Подробное решение: изменение параметра reuseSessions

Мы предлагаем вам подробный алгоритм действий для устранения проблемы зависания предметов отладки, используя изменение параметра reuseSessions.

Шаг 1: Определение файла публикации

Прежде всего, нам необходимо найти файл публикации вашего веб-сервиса или HTTP-сервиса. Обычно это файл с именем default.vrd, расположенный в каталоге публикации вашего веб-приложения на веб-сервере (IIS или Apache). Если вы публиковали несколько баз, или использовали нестандартные имена для публикации, файл может называться иначе. Путь к каталогу публикации можно найти в настройках веб-сервера или в процессе публикации базы через конфигуратор 1С.

Типичные пути могут быть следующими:

1. Для IIS: C:\inetpub\wwwroot\ИмяПубликации\default.vrd
2. Для Apache: C:\Program Files\Apache Software Foundation\Apache2.4\htdocs\ИмяПубликации\default.vrd или аналогичный путь.

Выясним точное местоположение файла, обратившись к настройкам вашего веб-сервера.

Шаг 2: Редактирование файла .vrd

После того как мы нашли нужный файл (например, default.vrd), откроем его с помощью любого текстового редактора (например, Блокнот или Notepad++). Этот файл представляет собой XML-структуру, описывающую параметры публикации.

Найдем в файле строку, содержащую параметр reuseSessions. Она может выглядеть примерно так:

<ws publishExtensionsByDefault="true" reuseSessions="autouse" />

Наша задача – изменить значение атрибута reuseSessions с "autouse" на "dontuse".

После изменения строка должна принять следующий вид:

<ws publishExtensionsByDefault="true" reuseSessions="dontuse" />

Важно: Убедимся, что мы сохранили изменения в файле.

Шаг 3: Перезапуск веб-сервера или службы агента 1С

Чтобы изменения вступили в силу, необходимо перезапустить веб-сервер, на котором опубликованы сервисы, или службу агента сервера 1С. Это позволит серверу 1С перечитать настройки публикации и начать применять новое поведение. Мы рассмотрим два основных варианта:

1. Перезапуск веб-сервера (IIS или Apache):
   • Для IIS: Откроем "Диспетчер служб IIS", найдем пул приложений, соответствующий нашей публикации, и перезапустим его. Или же можно перезапустить службу "Веб-публикация" (World Wide Web Publishing Service) или выполнить команду iisreset в командной строке с правами администратора.
   • Для Apache: Перезапустим службу Apache через "Диспетчер служб" Windows или выполним команду перезапуска, соответствующую вашей операционной системе.
2. Перезапуск службы агента сервера 1С:
   • Откроем "Службы" (services.msc), найдем службу 1C:Enterprise 8.3 Server Agent (x86-64) (или аналогичную, в зависимости от разрядности и версии платформы) и перезапустим ее. Этот шаг также может помочь, так как он принудительно обновит состояние кластера 1С.

После выполнения этих шагов мы должны заметить значительное уменьшение или полное прекращение разрастания процесса dbgs.exe, а количество зависших предметов отладки должно стабилизироваться и постепенно уменьшаться.

Последствия изменения: снижение производительности

Хотя изменение reuseSessions="dontuse" эффективно решает проблему зависания предметов отладки, важно понимать, что оно может привести к некоторому снижению производительности. Поскольку для каждого запроса теперь будет создаваться новый сеанс 1С, увеличиваются накладные расходы на инициализацию этих сеансов. В условиях высокой нагрузки и большого количества запросов к веб-сервисам, это может проявиться в незначительном замедлении отклика.

Мы взвесим этот компромисс: стабильность работы сервера и отсутствие утечек памяти в dbgs.exe против потенциально небольшой потери производительности. Для большинства систем, особенно если проблема с dbgs.exe является критической, выгода от стабильности значительно перевешивает незначительное снижение скорости.

Другие подходы и их эффективность

Помимо основного решения, в процессе поиска путей устранения проблемы предлагались и другие подходы. Мы проанализируем их эффективность:

1. Отключение отладки по HTTP/HTTPS: Это самый простой, но наименее желательный вариант. Полное отключение отладки, конечно, устранит проблему с dbgs.exe, но сделает невозможной отладку веб-сервисов и HTTP-сервисов, что критически важно для разработки и поддержки. Разработчикам придется прибегать к менее удобным методам, таким как отладка по TCP/IP или отладка на самом сервере, что замедляет процесс.
2. Изменение настроек веб-сервера (количество соединений, время жизни): Некоторые предлагали уменьшить количество соединений или время их жизни на закладке "Прочие публикации веб-сервера". Однако, как отмечалось в обсуждении, это не касается "предметов отладки", которые являются сущностью сервера отладки 1С, а не веб-сервера. Эти настройки влияют на обычные веб-соединения, но не на процесс dbgs.exe.
3. Разделение сервера 1С и веб-сервера (IIS/Apache) на разные машины: Идея заключается в том, чтобы разнести веб-сервер и сервер 1С на разные физические или виртуальные машины. Это может помочь распределить нагрузку и изолировать проблему: если dbgs.exe и будет разрастаться, то на отдельной машине, не влияя напрямую на производительность СУБД или других компонентов основного сервера 1С. Однако, это не устраняет корневую причину зависания предметов отладки, а лишь локализует её.
4. Обновление платформы 1С:Предприятие: Хотя проблема проявляется на разных версиях платформы (от 8.3.15 до 8.3.20 и выше), обновление до более свежих релизов всегда рекомендуется. Иногда новые версии содержат исправления, которые могут изменить характер проявления проблемы или улучшить стабильность. Тем не менее, как показывает опыт, обновление не всегда полностью устраняет данную конкретную проблему с dbgs.exe, а лишь может повлиять на её поведение.
5. Завершение неактивных сеансов в конфигураторе: Некоторые пользователи предлагали установить завершение неактивных сеансов через настройки конфигурации. Однако, это относится к обычным сеансам пользователей 1С, а не к предметам отладки, которые обрабатываются процессом dbgs.exe. Поэтому это решение неэффективно для данной проблемы.

Диагностика и мониторинг проблемы

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

1. Диспетчер задач Windows / Монитор ресурсов: Регулярно отслеживаем потребление оперативной памяти процессом dbgs.exe. Если процесс продолжает разрастаться, это указывает на то, что проблема не устранена или требуется дополнительное вмешательство.
2. Консоль кластера серверов 1С:Предприятия: В консоли кластера мы можем видеть активные сеансы и, в некоторых случаях, предметы отладки. Хотя прямое отображение "висячих" предметов отладки может быть затруднено, мы можем косвенно судить по общей загрузке и поведению сервера.
3. Технологический журнал 1С:Предприятия: Настройка и анализ технологического журнала 1С может предоставить ценную информацию о создании и завершении сеансов, ошибках, связанных с отладкой, и общем состоянии системы. Анализируя логи, мы можем выявить закономерности в появлении и накоплении предметов отладки.

Мониторинг позволяет нам не только увидеть проблему, но и подтвердить, что предпринятые меры действительно привели к желаемому результату.

Особенности HTTP-отладки и роль мобильных клиентов

Отладка по протоколу HTTP/HTTPS имеет свои уникальные сложности по сравнению с традиционной отладкой по TCP/IP. При HTTP-отладке взаимодействие с сервером отладки происходит через веб-сервер, что добавляет дополнительный уровень абстракции и потенциальных точек отказа. Именно в этом механизме часто возникают сбои с корректным завершением отладочных сессий и очисткой памяти. Отладка по TCP/IP, напротив, обычно более стабильна в этом отношении, поскольку имеет более прямое соединение с сервером отладки.

Мобильные клиенты, которые часто обмениваются данными с центральной базой через веб-сервисы (например, каждые 60 секунд), также вносят свой вклад в проблему. Специфика мобильных устройств, нестабильность соединений, аварийное завершение процессов на клиенте или отсутствие явного механизма закрытия соединения на стороне мобильного клиента могут приводить к большому количеству "висячих" предметов отладки. Сервер отладки может не получать своевременной информации о том, что клиент больше не активен, и продолжает удерживать ресурсы.

Заключение

Проблема зависания предметов отладки веб-сервисов в 1С:Предприятии, приводящая к разрастанию процесса dbgs.exe и критическому снижению производительности, является системной особенностью работы отладчика с HTTP-сервисами. Самым эффективным и проверенным решением на данный момент является изменение параметра reuseSessions="autouse" на reuseSessions="dontuse" в файлах публикации ваших веб-сервисов и HTTP-сервисов (например, default.vrd).

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