Ошибка времени выполнения 1с

Обновлено: 02.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 Мб), и они представляют собой большое количество сложных вложенных структур.

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

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

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

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

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


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

    В свойствах COM+ приложения 1CV8 на серверном компьютере на закладке Identity установлен Interactive user, но никакой ользователь интерактивно не вошел в серверный компьютер.

    приложение 1CV8 или сомпонента v8.server.1 выключена, если сервер на Windows Server 2003. см. статью "Особенности настройки Windows Server 2003 при установке сервера 1С:Предприятия 8.0" на диске ИТС.

    Клиент не имеет прав на доступ к серверу (access denied). Выполните рекомендации статьи "Вопросы установки и настройки 1C:Предприятия 8.0 варианте "клиент-сервер"" из раздела методической поддержки
    1С:Предприятия 8.0 на диске ИТС.

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

    На клиентском компьютере запрещено использование DCOM. Помогает

    запустить на клиентском компьютере dcomcnfg.exe на закладке Default Properties установить флаг Enable distributed COM on this computer.

    • dcomcnfg/ Default protocols:
    • Connection oriented TCP/IP
    • dcomcnfg/ Default properties:
    • Enable distributed COM on this computer
    • Default authentication level: Connect
    • Default impersonation level: Identify

    3. Попробуйте на серверном и клиентском компьютере понизить уровень аутентификации:

    4. Проверьте, не установлено ли сетевых экранов. Откройте порт 135 и те, которые указаны на клиенте и сервере в диалоге:

    • dcomcnfg/ Default protocols/ Properties/ Post Ranges. Если там диапазонов портов не указано - задайте их.

    На сервере произошло неожиданное исключение. Сервер упал. Нужны записи из Event Log с сервера.

    Ошибка возникает при рассогласовании протоколов аутентификации между DCOM клиентом и сервером в том случае, если для связи между ними используется Microsoft Internet Information Services (IIS).
    Возможно, для DCOM используется протокол Tunneling TCP/IP.

    • Установите а компьютере - сервере 1С:Предприятия и на клиентских компьютерах для DCOM протокол Connection-oriented TCP/IP.

    Запустить DcomCnfg.exe и проверить протокол для DCOM должен быть TCP/IP с ориентацией на подключения

    Юрий , а обновление-то прошло? Фоновые задания, запущенные перед обновлением, и должны завершаться принудительно.

    У меня при обновлении конфигурация баз данных не обновилась. При попытке переобновить через конфигуратор выдает критическая ошибка, поврежден файл инфобазы. В режиме предприятия предупреждает о несоответствии конфигураций, но запускается и работает, только не обновляется. Никто не сталкивался. Заранее благодарен.

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

    Не обновляться автоматически
    Обновляйтесь из конфигуратора

    При автоматическом обновлении (ихз пользовательского режима) резервная копия делается автоматически

    Добрый день. Помогите пожалуйста. Не нашла как вопрос задать, решила в похожей теме задать. Выключилось электричество во время работы. Файл базы данных поврежден. Проделала все инструкции (восстановление утилитой и конфигуратором). Выдает, что ошибок нет. Загрузила последнюю сохраненную выгрузку. Так теперь даже войти не получается, сразу всплывает окно-Файл базы данных поврежден. Что делать? (1С Предприятие 8.3 Управление торговлей базовая, редакция 11.3)

    Попробуй почисти кэш

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

    Юрий , пробовала-не выходит. Попробую кэш очистить.

    Добрый вечер. Теперь кэш не могу найти(( Открываю окно запуска 1С, выбираю настройки. Там адрес (в инете пишут что это и есть адрес кэша): С\Users\Admin\AppDate\Roaming\1C\1cv8\tmplts. Нашла я вот С\Users\Admin\AppDate\Roaming но там одна папка uTorrent и в ней ничего похожего на 1С нет(((
    Когда ошибка вылазит :файл поврежден, то, если нажать на Информацию для техподдержки, то поврежденный файл указывают С\Users\Admin\AppDate\Local\1C\1cv8\7a60182b-39cc-4aca-88e2-0ff20c4f8b07\5a0a991a-1fea-4e4b-a1c2-13d6326e0ae8\vrs-cache\cache/1CD
    В uTorrent есть папка dlimagecache. В ней три файла с длинными названиями. Может это и есть кэш?

    Длительные операции на сервере

    Область применения: управляемое приложение.

    1. При разработке конфигураций следует избегать длительных вызовов из клиентского кода в серверный. Все длительные серверные вызовы, которые могут выполняться более 8 секунд в обычных сценариях работы пользователя, следует выполнять асинхронно, с помощью фонового задания.

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

    В противном случае такие вызовы могут привести к потере работоспособности приложения или затруднению работы с ним:

    • браузер может предложить прекратить длительно выполняющийся сценарий, после чего приложение станет неработоспособным;
    • веб сервер может прервать длительное обращение к серверу 1С:Предприятия и вернуть ошибку 504 (шлюз не отвечает);
    • в случае длительного выполнения операции, у пользователя нет возможности отменить ее.

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

      Код, выполняющий длительную обработку данных, располагается в модуле менеджера объекта* или в общем модуле. Результат своей работы он помещает во временное хранилище;


    а для прочих мест – выводится блокирующая форма ( РежимОткрытияОкна = БлокироватьОкноВладельца ), на которой размещена декорация с анимированной картинкой и кнопка «Отмена» :

    2.2. Асинхронное формирование отчета требуется только для тех отчетов, которые

    • разработаны без использования СКД или с использованием СКД, но с переопределенной процедурой формирования отчета (переопределен обработчик кнопки «Сформировать» или в обработчике модуля отчета ПриКомпоновкеРезультата устанавливается СтандартнаяОбработка = Ложь ).
    • и формирование которых, как правило, занимает длительное время.

    Поведение таких отчетов должно быть максимально похожим на поведение отчетов на базе СКД, а именно:

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

    3. При использовании в конфигурации Библиотеки стандартных подсистем в распоряжении разработчика имеются вспомогательные функции и процедуры общих модулей ДлительныеОперации , ДлительныеОперацииКлиент , а также процедура УстановитьСостояниеПоляТабличногоДокумента общего модуля ОбщегоНазначенияКлиентСервер .

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

    Функция ОпределитьНастройкиУчетнойЗаписи(АдресЭлектроннойПочты, Пароль) Экспорт
    .
    Возврат Настройки;
    КонецФункции

    В форме объекта выполняется вызов этой функции в фоновом задании в три этапа:
    1) запуск фонового задания на сервере,
    2) подключение обработчика завершения фонового задания на клиенте,
    3) обработка результата выполнения фонового задания.

    &НаКлиенте
    Процедура НастроитьПараметрыПодключенияАвтоматически()
    // 1. Запуск фонового задания на сервере.
    ДлительнаяОперация = НачатьПоискНастроекУчетнойЗаписи();

    // 2. Подключение обработчика завершения фонового задания.
    ПараметрыОжидания = ДлительныеОперацииКлиент.ПараметрыОжидания(ЭтотОбъект);
    Оповещение = Новый ОписаниеОповещения("ПриЗавершенииПоискаНастроек", ЭтотОбъект);
    ДлительныеОперацииКлиент.ОжидатьЗавершение(ДлительнаяОперация, Оповещение, ПараметрыОжидания);
    КонецПроцедуры

    &НаСервере
    Функция НачатьПоискНастроекУчетнойЗаписи()
    ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияФункции(УникальныйИдентификатор);
    Возврат ДлительныеОперации.ВыполнитьФункцию(ПараметрыВыполнения, "Справочники.УчетныеЗаписиЭлектроннойПочты.ОпределитьНастройкиУчетнойЗаписи",
    АдресЭлектроннойПочты, Пароль);
    КонецФункции

    // 3. Обработка результата выполнения фонового задания.
    &НаКлиенте
    Процедура ПриЗавершенииПоискаНастроек(Результат, ДополнительныеПараметры) Экспорт

    Если Результат = Неопределено Тогда // Пользователь отменил задание.
    Возврат;
    КонецЕсли;

    Если Результат.Статус = "Ошибка" Тогда
    ВызватьИсключение Результат.КраткоеПредставлениеОшибки;
    КонецЕсли;

    Настройки = ПолучитьИзВременногоХранилища(Результат.АдресРезультата);
    УдалитьИзВременногоХранилища(Результат.АдресРезультата);
    УстановитьНастройкиУчетнойЗаписи(Настройки);

    Методическая рекомендация (полезный совет)

    3.1. При каждом выполнении фонового задания его результат помещается во временное хранилище на время жизни формы:

    ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияФункции(УникальныйИдентификатор);
    ДлительныеОперации.ВыполнитьФункцию(ПараметрыВыполнения, ПараметрФоновогоЗадания);

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

    Настройки = ПолучитьИзВременногоХранилища(Результат.АдресРезультата);
    УдалитьИзВременногоХранилища(Результат.АдресРезультата); // Данные во временном хранилище больше не требуются.

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

    &НаСервере
    Процедура ПриСозданииНаСервере(Отказ)
    АдресРезультатаФоновогоЗадания = ПоместитьВоВременноеХранилище(Неопределено, УникальныйИдентификатор); // Резервируем адрес временного хранилища
    КонецПроцедуры

    &НаСервере
    Функция НачатьПоискНастроекУчетнойЗаписи()
    ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияФункции(УникальныйИдентификатор);
    ПараметрыВыполнения.АдресРезультата = АдресРезультатаФоновогоЗадания; // всегда используем одно и то же временное хранилище

    Возврат ДлительныеОперации.ВыполнитьФункцию(ПараметрыВыполнения,
    "Справочники.УчетныеЗаписиЭлектроннойПочты.ОпределитьНастройкиУчетнойЗаписи",
    АдресЭлектроннойПочты, Пароль);
    КонецФункции

    4. Если в конфигурации реализуются алгоритмы, инициирующие запуск фоновых заданий или запись данных информационной базы без участия пользователя (например, регулярное обновление информации в открытой форме), то в них следует проверять, что в текущем сеансе не установлен монопольный режим. В противном случае, следует блокировать попытки выполнения таких действий. Например:

    Если МонопольныйРежим() Тогда
    Возврат;
    КонецЕсли;

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

    Обновление данных ИБ при первом интерактивном запуске программы после обновления конфигурации; Выгрузка данных информационной базы в файл для перехода в сервис; Использования монопольного режима для снижения времени выполнения массовых операций по изменению данных;

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

    На время выполнения этого фонового задания следует блокировать весь интерфейс приложения, открывая форму ожидания завершения операции в режиме РежимОткрытияОкна = БлокироватьВесьИнтерфейс. Блокировать интерфейс приложения требуется потому, что на время выполнения задания полноценная работа пользователя с приложением уже невозможна:

    • Если пользователь(*) попытается записать какой-либо объект, это приведет к ошибке (из-за установленного монопольного режима);
    • В ряде случаев могут запускаться фоновые задания в качестве реакции на действия пользователя случае (при поиске в динамическом списке, при вводе по строке, формировании отчетов и пр.), которые также завершатся с ошибкой.
      Кроме того, на самой форме ожидания длительной операции не следует размещать элементы управления, которые могут приводить к запуску таких фоновых заданий. Например: поля ввода, динамические списки и отчеты.

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

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