1с планировщик заданий висит соединение

Обновлено: 08.07.2024

Извиняюсь что некрасиво оформлено. Ткните носом в ФАК по оформлению. Добавлю скрины.

я бы для начала оставил 1 процесс, нафига вам 3 на 64 битном сервере с 40 пользаками? 1 рабочий+1резеврный оптимальный вариант.

Проблема не давала о себе знать 4 дня. Сегодня опять появляется 3 дополнительных планировщика с подключением к базе, "Превышено время ожидания запроса на блокировку" или невозможно получить доступ к объекту, ничего не проводиться и даже в справочники записать нельзя. Мониторинг список сеансов на предмет блокировок не выявил ничего криминального, только одна блокировка у пользователя который запустил 2 сеанса одновременно. Перевод на новую платформу запланирован на 22-е.

процессы значит не убрали, почему? рестарт службы агента сервера ночью делается?

что-то похожее было. Из-за проблем с электричеством сервак вырубился. После этого, в Журнале регистрации - планировщик заданий запускается, но не завершается, и так каждые 5 минут. + сеансы пользователей тоже рвались. Вылечили переустановкой сервера 1с

Обновил платформу до 219, оставил 1н рабочий процесс. Проблема повторяеться. Как водиться искал не там где нужно и не то что нужно. SQL Profiler смотрел как раз на взаимные блокировки, их небыло. А нужно было мониторить на долгие запросы. Есть запрос на провидение по партиям который очень долго выполняется если документ проводиться задним числом. При попытки провести другие документы, запускается дополнительный планировщик с подключением к базе, проведение завешались неудачей «Конфликт блокировок» и планировщик исчезал. Т.к. попытки проведения были постоянными, планировщик висел постоянно и я принял его за виновника всех моих бед. Для меня так и осталось непонятным, зачем он собственно запускается. Ниже сам запрос, план выполнения и пр. Буду очень благодарен если подскажите как подкрутить индексы для ускорения работы.

Переписал запрос по рекомендациям на , подзапросы вынес во временные таблицы. Заметно уменьшилось время выполнения (2

3 раза быстрее). Отложить восстановление последовательности на ночь нельзя, т.к. предприятие работает круглосуточно и львиная доля документов вводиться при ночной отгрузке. Есть только 2е субботы в месяц, за которые с горем пополам пытаемся восстановить движение по партиям. Проблема не решена.

вообще там в типовых беспредел с этими регламентными заданиями. Например, в БП 2.0 есть регламентное задание "ПересчетИтоговРегистровНакопленияБухгалтерии". Если посмотреть у него в расписании, то там написано - делать 5-го числа каждого месяца один раз в час. И вчера как раз было 5-е число месяца. Бухгалтерия полдня на ушах стояла, пока не разобрались в чем дело. В общем, надо брать калаш и ехать на Селезневку разбираться.

бред процессов должно быть мин(КоличествоКамней-1, КоличествоОдновременыхСеансов) при 40 пользователей нужно ставить колличество камней - 1

Может всё таки ядер? Где то читала рекомендацию по процессу на 12-15 пользователей. Исходя из этого и делал 3 раб.процесса. При уменьшении с 3х до 1го процесса разница особой не увидел. Следует иметь ввиду что на этой же машине работает и MS SQL Server. По мониторю пару дней после перерасчёта итогов и поставлю 4 процесса (ядер 8). Ткните носом в обработку фонового восстановления последовательности для УТ.

В рамках одной СУБД SQL развернуто порядка 25 баз. Активных пользователей в пики до 350.
Заметил одну особенность:
Волнообразно т.е. в одну секунду запускается порядка 200 сеансов планировщиков заданий.
Потом потихоньку, примерно по одному в секунду, соединения завершаются.
Естественно в этот момент у всех все тупит. Отловить причину никак не можем.

Кто-нибудь сталкивался? Может подсказать где искать?

(1) Gukov10,
если у вас фоновые задания запускаются, то что значит не можете найти причину? Запуск фоновых заданий и есть причина запуска фоновых заданий :)

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

(1) Gukov10, Полностью согласем с предыдущим постом.
Хочу лишь дополнить, что есть в нете обработки по управленью фоновыми заданиями.
Можно конечно поставить галочку "Блокировка регламентных заданий включена" свойстве каждой базы в консоле 1С сервера, но этим вы можете заблокировать выполнение нужных заданий по расписанию Журнале регистрации галочку на Фоновых заданиях оставьте и по времени можно примерно интервал ограничить и смотрите. Прошу прощения, описался.
не фоновый, а планировщики заданий!
Куча соединений без сеансов.

Принскрины сервера 1С во вложении.

Выявили следующую закономерность:
На сервере SQL вместе с базами 1С есть внешняя база куда 1С пишет данные.
При возникновении блокировок в этой внешней базе и попытки записи в нее средствами 1С
на сервере 1С возникает куча соединений планировщиков задач.
Соединяемся с базой через адо.

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

(6) Gukov10, возможно фоновые задания не отрабатывают корректно. В любом случае нужно копать в сторону регламентных и фоновых заданий, смотреть как они выполняются.
служба сервера 1С у вас рестартится регламентно? (6) Добрый день! Столкнулись тоже с подобной задачей и именно 20.12.2016 и не можем понять ЧТО могла произойти.
У Вас было решение по этому вопросы? Как Вы справились? (12) Добрый день! У нас проблема возникла в следствии частых обращений внешней системы в 1С. На момент возникновения проблемы платформа не успевала закрыть соединение или не закрывало их в общем, точно не помню. Мы решили ограничив внешнюю систему пятью активными соединениями за сеанс. Что как то нам помогло. Далее в какой то из версий платформ поведение системы (1С+внешняя) стабилизировалось. Т.е. платформа начала корректно и быстро отрабатывать запросы от внешней системы.

Даже если поставить блокировку фоновых заданий и выключить их все в Консоле заданий,
то соединения все равно создаются.
Причем количество соединений равно количеству рабочих процессов умноженных на количество активных баз 1С.
Т.е. в моем случае 8 раб.процессов на 24 базы = 192 - соединения планировщиков заданий.

Как только блокировка к внешней БД пропадает - соединений по одному (раз в секунду) завершаются.

Рестартяться рабочие процессы каждые 8 часов.

Добрый день!
Ловлю такие же артефакты на своих тестовых базах.
НЕ подскажите как решили проблему? ну вот сам и сказал нужно псомотреть где идет планировка заданий раз в 8 часов. Думаю в 1с в планировщик регламентных заданий по отрубай половину. да никак)) уменьшили количество рабочих процессов.
а так, копай в сторону блокировок в СУБД.
Такая штука у нас возникала при зависании 1с из-за блокировок на СУБД. Перешли на 8.3 - появился планировщик раз в несколько дней.

Всплывает данная проблема раз в месяц-два, причину найти не удается, но в качестве решения всплывающей проблемы помогает следующее:

1. Останавливаем службу сервера 1С.
2. Ждем завершения всех процессов, связанных с 1С (ragent, rmngr, rphost). Те, которые зависли и не вырубились сами - убиваем через диспетчер задач.
3. Чистим серверный кэш: удаляем все папки гуидами в названии отсюда C:\Program Files\1cv8\srvinfo\reg_1541
4. Перезагружаем сервер.

Соединения с кластером и регламентный перезапуск рабочих процессов

Раздел поясняет влияние соединений с кластером на управление рабочими процессами.

Соединения кластера

Утилита администрирования кластера серверов позволяет посмотреть список соединений:

кластера в целом (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Соединения");
рабочего процесса (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Процессы/ <имя рабочего процесса>/ Соединения" или ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Рабочие серверы/ <имя рабочего сервера>/ Процессы/ <имя рабочего процесса>/ Соединения");
информационной базы (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ Информационные базы/ <имя информационной базы>/ Соединения").

Среди соединений имеются:

пользовательские соединения (1С:Предприятие, Конфигуратор, COM-соединения, WS-соединение, Фоновое задание, Консоль кластера, COM-администратор)
служебные соединения (Планировщик заданий, Отладчик)

Пользовательские соединения относятся к информационной базе и видны в списке соединений:

своей информационной базы;
своего рабочего процесса;
кластера в целом.

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

своего рабочего процесса;
кластера в целом.

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

Разрыв соединения

если по инициативе пользовательского соединения на сервере не выполняется никакого действия, то соединение может быть разорвано всегда;
если в момент разрыва соединения соединение выполняет на сервере код на встроенном языке, то разрыв соединения возможен при переходе выполнения от одной строки кода на встроенном языке к другой;
если соединение выполняет запрос к базе данных, то для MS SQL Server и IBM DB2 1С:Предприятие предпринимает попытку прервать выполнение запроса сервером баз данных. Соединение будет разорвано, если пользователь базы данных, от имени которого сервер 1С:Предприятия выполняет обращение к базе данных, имеет соответствующие права, и СУБД готово выполнить функцию прекращения исполнения запроса;
в других случаях попытка принудительного разрыва пользовательского соединения может не привести к фактическому разрыву соединения.

Принудительный разрыв служебных соединений невозможен.

Выключение и остановка рабочего процесса

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

После выключения запущенного рабочего процесса он останавливается не сразу, а только тогда, когда с ним не будет установлено ни одного пользовательского соединения. При этом новых пользовательских соединений с данным рабочим процессом устанавливаться не будет. Для обеспечения возможности остановки рабочего процесса даже в том случае, когда с ним еще установлены пользовательские соединения, в Утилите администрирования кластера серверов предусмотрен параметр "Выключенные процессы останавливать через. " в свойствах кластера, а в средствах программного администрирования кластера - свойство ExpirationTimeout объекта "Кластер серверов" (IClusterInfo).

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

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

Регламентный перезапуск рабочих процессов

Для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах может быть предусмотрен их автоматический перезапуск. В 1С:Предприятие встроена возможность автоматического перезапуска рабочих процессов через заданные интервалы времени. Для этого в Утилите администрирования кластера серверов предназначен параметр "Рабочие процессы перезапускать через. " в свойствах кластера, а в средствах программного администрирования кластера - свойство LifeTimeLimit объекта "Кластер серверов" (IClusterInfo). Если этот параметр отличен от 0, то для каждого рабочего процесса через заданное количество секунд после его запуска:

создается и запускается новый процесс;
текущий процесс выключается.

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

установить время принудительной остановки рабочих процессов (свойство ExpirationTimeout объекта "Кластер серверов");
согласно установленным критериям выбрать рабочий процесс, который необходимо перезапустить;
запустить новый процесс;
выключить выбранный процесс;
после того, как выключенный процесс будет остановлен, удалить его из кластера.

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

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

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

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

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

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

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

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

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 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 Мб), и они представляют собой большое количество сложных вложенных структур.

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

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

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

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

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

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

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