← На главную

При работе с платформой 1С:Предприятие 8.3, особенно в больших и нагруженных системах, пользователи могут столкнуться с ситуацией, когда после перезапуска службы агента сервера (ragent) выполнение отчетов, которые ранее занимали считанные секунды, начинает отнимать несколько минут. Эта проблема усугубляется тем, что стандартные средства замера производительности в конфигураторе могут показывать нормальное время выполнения, что вводит в заблуждение.

Рассмотрим подробнее данную проблему, проанализируем её возможные причины и предложим комплексные решения для её диагностики и устранения.

Суть проблемы:

Пользователи сообщают, что после перезапуска службы ragent (например, после ночного обслуживания сервера) и последующего переподключения клиентских сеансов, формируются те же самые отчеты, которые до перезапуска выполнялись за 3 секунды, но теперь их выполнение занимает 3 минуты и 3 секунды. При этом замер производительности в конфигураторе показывает, что чистое время выполнения кода отчета составляет всего 1.5 секунды, что противоречит наблюдаемому замедлению.

Важный диагностический признак: запуск клиентского приложения 1С с параметром /РежимОтладки полностью устраняет проблему, и отчеты вновь формируются быстро (за 2-4 секунды). Это указывает на то, что причина кроется в механизмах, которые активно работают в обычном режиме, но отключаются или ведут себя иначе в режиме отладки.

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

Причина 1: Фоновые обращения к внешним интернет-ресурсам

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

Почему это происходит?

Современные конфигурации 1С активно интегрированы с множеством онлайн-сервисов для повышения функциональности и удобства. К таким сервисам относятся:

1. Сервисы 1С: Проверка наличия обновлений платформы и конфигурации (например, через 1С:Обновление программ), обращение к порталу 1С:ИТС для проверки лицензионности, получения новостей или актуальных данных.
2. Проверка контрагентов: Такие сервисы, как СПАРК Риски или другие интеграции, могут выполнять фоновую проверку благонадежности контрагентов.
3. Классификаторы: Загрузка и обновление различных классификаторов (например, адресный классификатор, ОКТМО) или метаданных из внешних репозиториев (пользователь упоминал classifier-repository.1c.ru).
4. Курсы валют: Регламентные задания для автоматической загрузки курсов валют с сайта Центрального Банка РФ или других источников.
5. Электронный документооборот и интеграции с банками: Проверка входящих транзакций, статусов ЭДО, сертификатов электронной подписи. Пользователь упоминал ФинОтчетностьВБанкиСлужебныйКлиент.ПолучитьИнформациюОВходящихТранзакцияхОтБанков.
6. Проверка статуса интернет-поддержки: Система регулярно проверяет подключение интернет-поддержки.
7. Авторизация и безопасность: Обращения к сервисам авторизации (например, login.1c.ru), проверка токенов авторизации (упоминалось ИнтерфейсАвторизацииИСМПКлиент.ВыполнитьОбновлениеНастроекОтветственногоЗаАктуализациюТокеновАвторизации).

Проблема значительно усугубляется, если доступ к этим внешним ресурсам с сервера 1С ограничен, нестабилен или вовсе отсутствует. В таких случаях система пытается установить соединение и ожидает ответа в течение установленного таймаута, который часто составляет от 30 до 60 секунд. Если подобных обращений несколько (например, три по 60 секунд), общая задержка может легко достигать нескольких минут, что идеально соответствует описанной ситуации (дополнительные 3 минуты).

Как диагностировать обращения к внешним ресурсам:

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

1. TCPView (Windows Sysinternals): Запустим TCPView на сервере 1С. В момент формирования "тормозящего" отчета внимательно отслеживайте все исходящие сетевые соединения от процессов rphost.exe. Мы увидим IP-адреса и порты, к которым пытается подключиться система. Это поможет выявить внешние ресурсы.
2. Wireshark: Более мощный инструмент для анализа сетевого трафика. Запустите захват трафика на сетевом интерфейсе сервера 1С. Отфильтруйте трафик по процессам rphost.exe и анализируйте попытки установки TCP-соединений (SYN/ACK). Мы сможем увидеть запросы, которые долго не получают ответа или приводят к повторным попыткам.

Поиск проблемного кода в конфигурации:

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

1. Полнотекстовый поиск: Выполним поиск по всей конфигурации (общим модулям, объектам метаданных, макетам) по строкам, содержащим URL-адреса (например, http://, https://), доменные имена, идентифицированные с помощью сетевых утилит, или ключевые слова, связанные с интернет-соединениями.
2. Поиск по функциям и объектам: Ищите использование следующих объектов и методов 1С, отвечающих за работу с интернетом:
   • HTTPСоединение
   • WSОпределение, WSПрокси
   • FTPСоединение
   • ПолучитьФайлИзИнтернета
   • ЗагрузитьИзИнтернета
   • ИнтернетПочтовыйПрофиль
   • Обращения к регламентным заданиям, имена которых могут указывать на синхронизацию или проверку (например, ПроверкаОбновлений, ЗагрузкаКурсовВалют, АктуализацияКлассификаторов).

Как решить проблему с внешними запросами:

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

Причина 2: Проблемы с кешированием на сервере 1С и SQL Server

Перезапуск службы ragent, хотя и выглядит как "чистый старт", не всегда полностью очищает все виды кеша, которые могут влиять на производительность. Некорректный или неоптимальный кеш может значительно замедлять работу системы, даже если сам код отчета выполняется быстро.

Почему это происходит?

1. Кеш метаданных 1С: На сервере 1С хранится кеш метаданных конфигурации, который используется рабочими процессами (rphost). Если этот кеш по какой-то причине стал некорректным или устаревшим после перезапуска ragent, система может тратить время на его перестроение или использовать неоптимальные данные, что приводит к замедлениям.
2. Кеш планов выполнения запросов SQL Server: SQL Server кеширует планы выполнения запросов для ускорения работы. Иногда после перезапуска сервера 1С или обновления конфигурации СУБД может начать использовать неэффективные "старые" планы запросов для стандартных операций, что приводит к деградации производительности.

Как диагностировать и решить проблемы с кешированием:

1. Очистка кеша 1С на сервере:

   Мы можем принудительно очистить кеш на сервере 1С. Для этого:

   1. Остановим все рабочие процессы rphost.exe (например, через оснастку "Администрирование серверов 1С:Предприятия" или перезапуском службы 1C:Enterprise 8.3 Server Agent, если нет активных пользователей).
   2. Перейдем в каталог кластера сервера 1С (обычно C:\Program Files\1cv8\srvinfo или C:\Program Files\1cv8\8.3.X.XXX\bin\conf, далее в подкаталог с GUID вашего кластера).
   3. Удалим все содержимое каталога sncc. Это очистит кеш метаданных сервера.
   4. Запустим службы 1С обратно.

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

2. Очистка кеша планов запросов SQL Server:

   Для очистки кеша планов запросов в SQL Server мы можем использовать команду DBCC FREEPROCCACHE. Это заставит SQL Server перестроить планы запросов, используя актуальную статистику и параметры.

   Скопировать код

   
   DBCC FREEPROCCACHE;
   GO
   

   Эту команду следует выполнять с осторожностью на продуктивных базах, так как она может кратковременно увеличить нагрузку на SQL Server за счет компиляции новых планов. Однако, при наличии проблем с производительностью, это может быть эффективным шагом. Перезапуск службы SQL Server, хотя и очищает кеш планов, является более радикальной мерой, чем просто DBCC FREEPROCCACHE, и обычно не требуется.

Причина 3: Влияние технологического журнала (ТЖ)

Технологический журнал (ТЖ) 1С:Предприятия — это мощный инструмент для диагностики производительности и ошибок. Однако, если он некорректно настроен или имеет очень большой размер, он сам может стать причиной замедлений.

Почему это происходит?

Если технологический журнал включен на сервере 1С с очень подробной детализацией (например, собирает события CALL, SDBL, DBMSSQL для всех процессов) и его размеры начинают переваливать за десятки гигабайт, дисковая подсистема сервера может не справляться с постоянной записью такого объема данных. В результате рабочие процессы rphost вынуждены ожидать завершения дисковых операций по записи в журнал, что со стороны пользователя выглядит как "зависание" или длительное выполнение операций.

Как диагностировать и решить проблему с ТЖ:

1. Проверка файла logcfg.xml:

   Мы должны проверить файл настройки технологического журнала logcfg.xml, который обычно находится в каталоге conf сервера 1С (например, C:\Program Files\1cv8\8.3.X.XXX\bin\conf). Обратите внимание на следующие параметры:

   • <log level="5">: Уровень детализации логов. Уровень 5 (самый высокий) собирает очень много информации и может серьезно влиять на производительность. Для продуктивной системы обычно достаточно уровня 4 или даже 3.
   • Список событий: Внимательно просмотрите, какие события собираются (например, <event filter='all' enable='1'/> или конкретные <event name='CALL' enable='1'/>, <event name='SDBL' enable='1'/>). Слишком широкий набор событий приводит к большим файлам.
   • <size limit='xxxx'>: Размер файла журнала. Убедимся, что лимит установлен адекватно и не позволяет файлам расти бесконечно.

   Если ТЖ был включен для отладки, но забыт, он может продолжать собирать избыточную информацию.

2. Проверка размера файлов ТЖ:

   Посмотрим на фактический размер файлов технологического журнала, которые обычно находятся в каталоге, указанном в logcfg.xml (параметр path в элементе <log>). Если файлы имеют размер в десятки гигабайт, это явный признак того, что ТЖ может быть причиной замедлений.

3. Решение:

   Для устранения проблемы мы можем:

   • Отключить ТЖ: Если ТЖ не нужен для текущей диагностики, его можно полностью отключить, установив enable='0' для всех событий или для всего <log>.
   • Уменьшить детализацию: Для продуктивной системы обычно рекомендуется использовать менее подробные настройки ТЖ, собирая только критичные события (например, EXCP, DEADLOCK) или уменьшая уровень детализации.
   • Перенести на быстрый диск: Если ТЖ необходим, но дисковая подсистема не справляется, можно настроить его запись на более быстрый диск (например, SSD), если это возможно.

   После изменения logcfg.xml необходимо перезапустить службу 1C:Enterprise 8.3 Server Agent, чтобы изменения вступили в силу.

Дополнительные диагностические шаги

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

1. Временное отключение регламентных заданий:

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

   1. Запустим 1С в режиме конфигуратора.
   2. Откроем список "Регламентные задания" (Администрирование -> Регламентные и фоновые задания -> Регламентные задания).
   3. Временно снимем флажки "Включено" для всех подозрительных или некритичных заданий.
   4. Перезапустим ragent и проверим, сохранится ли проблема. Если проблема исчезнет, это укажет на то, что причина была в одном из отключенных заданий. Затем мы можем включать их по одному, чтобы выявить конкретного "виновника".
2. Анализ журнала регистрации 1С:

   Журнал регистрации 1С также может содержать полезную информацию о длительных операциях, ошибках или предупреждениях, которые совпадают по времени с замедлением отчетов. Мы можем проанализировать его, отфильтровав события по времени, когда отчеты начали "тормозить", и по критичным событиям, таким как "Ошибка" или "Предупреждение".

3. Отладка в режиме "тонкого клиента + сервер":

   Хотя стандартный замер производительности в режиме отладки показал нормальные результаты, мы можем попробовать пошаговую отладку в режиме "тонкий клиент + сервер". Пользователь упоминал, что при добавлении "сервера" в предметы отладки конфигуратор вылетает. Это само по себе является признаком нестабильности платформы или конфликта. Если все же удастся запустить отладку, мы можем пошагово пройтись по коду отчета и посмотреть, на каких вызовах происходит длительное ожидание. Обратим особое внимание на вызовы, которые явно или неявно обращаются к внешним ресурсам или выполняют тяжелые запросы.

Заключение:

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