Ожидание окончания загрузки данных сервером 1с виснет

Обновлено: 05.07.2024

Методика расследования причин медленной работы операции на примере открытия управляемой формы

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

Сбор и анализ стандартных данных

Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".

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

Настройка технологического журнала на клиенте может быть такой:

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).

После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.

Замеры времени средствами БСП будут выглядеть следующим образом:


Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.

Замер отладчиком конфигуратора изображен на следующем рисунке:


Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.

'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000

а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).


Точное время начала замера (минут:секунд.миллисекунд): 25:10.779


Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801

Найдем теперь записи технологического журнала, соответствующие данному замеру, они будут примерно следующими:


Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.

Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.

Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:

  • Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
  • Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.

Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:


После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).

После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:


По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.

Запомним этот результат и проанализируем траффик.

Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.

При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:


Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.

Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:


В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.

После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.

Подведем промежуточный итог:

  • Проблем с медленной работой прикладного кода 1С или запросов нет.
  • Большая часть времени открытия формы состоит из сетевого взаимодействия.
  • Размер пакета с формой подозрительно велик.
  • После получения пакетов имеем высокую утилизацию ЦП тонким клиентом 1С (или веб-клиентом).
  • Потерянное время находится где-то между окончанием/началом работы прикладного кода 1С и сетевой передачей.

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

  • Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
  • Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
    • Хранилище значения, Строка(0);
    • Большие коллекции (Таблица, Дерево, Список);
    • Произвольный тип (концентрация проблем).

    Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту "Объект".

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


    Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
    Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:


    И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:


    Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.

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

    Выводы и рекомендации

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

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

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


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

    shaivam

    1) посмотрите на количество памяти выделяемой rphost на сервере 1С. Если у вас x32 версия сервера то процесс сможет использовать максимум 1, 75 Гб ОЗУ
    Если памяти не хватает, то сервер не может принять новые соединения или зависает когда текущему сеансу требуется дополнительная память
    www.viva64.com/ru/k/0036
    2) Посмотрите настройки "Параметры рабочего сервера" возможно установлены неверные настройки. У меня была такая проблема и сервер постоянно зависал. Мои настройки во вложение. Серверу выделено 11 Гб.
    3) Возможны проблемы в настройке Postgressql.

    ddb0daf5dde44d23953ed6d29573368a.jpg

    Предоставьте характеристики вашего сервера, размеры баз, конфиги Postgressql. Без информации сказать сложно.

    Приведите все характеристики вашего сервера: сервер 1С8 и БД физический или виртуальный, операционка, количество ОЗУ на каждом сервере, ЦП какой, сколько занимают ОЗУ процессы rphost, сколько их? Используете ли вы RAID массив?

    Ранее сам использовал PostgreSQL но, в процессе работы столкнулись с некоторыми проблемами при работе базы на PostgreSQL и недавно перешли на MS SQL.

    Сервер у вас не плохой для данных баз. Для того чтобы использовать PostgreSQL нужно очень хорошо разбираться в его настройке. Когда базы маленькие многие ошибки настройки "прощаются". Когда мы только начинали внедрять 1С + PostgreSQL у нас тоже были очень частые проблемы с работой БД (были частые зависания, медленно работала). PostgreSQL лучше использовать на Linux, а не на windows. Я сам не спец по БД, для настройки сервера БД мы нанималь специалиста из 1СБит и он нам его настроил и проблем в работе после этого не возникало.

    Совет:
    Базы у вас большие не поскупитесь наймите спеца по БД который вам сможет её настроить. Один человек не может быть специалистм во всём.

    1) давно ли вы делали проверку самой БД и реиндексацию? VACUUM и REINDEX
    2) давно ли делали тестирование и исправление базы средствами 1С?
    3) файл лога БД вынесен на отдельный HDD?
    4) сильно ли нагружен HDD?

    Задумайтесь о переходе на MS Sql зачастую он не требует "практически" никакой настройки и его проще использовать. В отличие от PostgreSQL MS Sql готов уже из коробки работать, а PostgreSQL нужно настраивать.

    Будут вопросы пишите может смогу чемнибудь помочь в Skype: tisartisar

    Наимите спеца по настроке БД

    Почему мы перешли на MS SQL:
    мы используем конфигурацию УТ и при закрытие месяца иногда возникали ошибки которые никак не удавалось решить. Если перенести базу на файловый режим и запустить закрытие месяца, то всё закрывалось нормально, этуже базу заружали на сервер PostgreSQL при рассчёте себестоимость возникали ошибки. На тот момнет мы на пол года отставали по закрытию месяцев из-за возникновения плавующих ошибок. Создали тестовую базу на MS SQL и месяц который немогли закрыть на PostgreSQL на MS Sql закрылся. Также на PostgreSQL не работает корректно округление цен в прайс листе. По факту работа 1С на PostgreSQL поддерживается, но рекомендуется всётаки использовать MS SQl.
    Из-за этого было принято решение перейти на MS SQL т.к. стабильность работы 1С дороже.

    Рад что смог помочь, обращайтесь ещё, если будут вопросы и проблемы.

    У некоторый пользователей иногда происходит зависание 1с, причем намертво.
    Работают они в терминале на win2008 r2.
    Зависание происходит у произвольного пользователя.
    При этом, на самом терминальнике ресурсов свободных дуром, и по оперативке и по процессору, также нет проблем с ресурсами на сервере, на котором крутится 1с + MS SQL.
    Если завершить процесс 1с на терминальнике - потом он запускается и нормально работает.
    Что интересно, если выполнить отключение и подключение к терминалу - 1с отвисает.
    С чем может быть связана проблема и каковы пути ее решения?

    • Вопрос задан более трёх лет назад
    • 2583 просмотра

    zhenyat

    Возможно, в 1с открывается модельное окно, которое "уходит взад" и к которому в стандартном виндовом терминале очень тяжело получить доступ :(

    zhenyat

    Угу, естественно модальное, но то что вы пишите получится только в remote desktop сессии, если 1с работает как remote application - то увы, такой фокус не проходит :( Изредка помогает, разрыв сессии с последующим к ней подключением, но не всегда :(
    У Citrix-а кстати такой проблемы не наблюдается, только у родного майкрософтовского терминала, независимо от версии - я начинала работать с 2000 и до 2012r2 это проблема сохраняется.
    Топикстартеру могу только посоветовать либо искать возможность перейти на Citrix XenApp, либо озадачить своих 1с программистов исключить модальные окна, если это обычное приложение. Если же конфа в режиме управляемого приложения - отказаться от использования терминала в пользу публикации на вебсервере.

    Я сталкивался с проблемой модальных окон, особенно на 1с 7. Но это не та проблема. Зависание происходит просто при просмотре списка документов. Никаких модальных окон в этот момент не появлялось. Здесь что-то другое и я не могу понять что именно. Скрин приложить не могу, ибо не позволяет политика безопасности.

    zhenyat

    cckfnn: Тогда надо больше подробностей: - какая версия 1с, какая конфигурация, какая сессия терминала - десктоп или приложение?

    📌 Если 1С выдает «Ошибка соединения с сервером 1С:Предприятие. Не запущен ни один рабочий процесс. Соединение с базой невозможно».

    Если 1С выдает «Ошибка соединения с сервером 1С:Предприятие» Если 1С выдает «Ошибка соединения с сервером 1С:Предприятие»

    Варианты поиска ошибок и решений:

    1. Проверьте в Диспетчере задач наличие процессов ragent, rphost и rmngr. Через оснастку « Службы » перезапустите « Агент сервера 1С:Предприятия ».
    2. При внезапном отключении питания или подобных ситуациях — возможно повреждение конфигурационных файлов:
    • Остановите Агент сервера 1С, удалите данные из папки srvinfo в « %ProgramFiles%\1cv8 » в зависимости от разрядности ОС.
    • Запустите службу « Агент сервера 1С:Предприятие ».
    • Через Администрирование серверов 1С Предприятия заново создайте кластер 1С и добавьте информационные базы.

    3. Переименование ПК с установленной ролью сервер 1С.

    После этого перестает работать Агент сервера 1С — запускается на несколько секунд и останавливается. В консоли управления появляется ошибка сетевого доступа к серверу.

    Настройки кластера серверов 1С:Предприятие хранятся в файлах в каталоге srvinfo (путь к нему указывает параметр -d в свойствах службы « Агент сервера 1С:Предприятие »).

    После изменения имени компьютера выполните следующее — найдите папку srvinfo в каталоге установки 1С, отредактируйте два файла:

    • . \1cv8wsrv. lst;
    • . \reg_1541\1CV8Clst. lst.

    Замените в этих файлах старое имя сервера на новое. Запустите службу « Агент сервера 1С:Предприятие ».

    ✅ Это типовые и быстрые варианты решений, но в сложных ситуациях требуется дополнительный разбор и поиск ошибок.

    ⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.

    Читайте также: