Долгое подключение к хранилищу 1с

Обновлено: 06.07.2024

При коллективной разработке требуется контроль за историей разработки, отслеживание объектов, которые дорабатываются в текущий момент.

Для этого и предназначено хранилище конфигурации.

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

Значит вам надо разворачивать хранилище конфигураций.

Как это делается поэтапно:

Работа с хранилищем

При каждом старте запуске конфигурации требуется :

Это можно произвести двумя способами:

Далее, вы работаете с объектом как обычно.

После окончания у вас два основных варианта:

отменить захват, при этом у вас объект восстановится их хранилища (этим отменяются также внесенные правки)
поместить измененный объект

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

Это основные команды для работы с хранилищем.

Особенности работы

Отбор захваченных объектов

можно отобрать все захваченные
захваченные определенным пользователем

В целом, хранилище работает очень стабильно:

Для резервного копирования достаточно настроить сохранение

1Cv8ddb.1CD и ПОЛНОСТЬЮ папку data, расположенную в той же папке, что и файл 1Cv8ddb.1CD

Уменьшилось удобство при повторном подключении

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

Особенности хранения

Механизм оптимизации

Производится упаковка файлов метаданных в папку pack

Рекомендация будет предлагаться при достижении:

Количества неупакованных файлов больше 5000.
Количества архивов более 50.

Планируется переход на версию 8.3, поэтому на данный момент работают две платформу 8.2.19.83 и 8.3.5.1486. (ключ 64 битный)
7 баз 8.2 с кол-во пол-ей не более 30 (sql1)
5 баз 8.3 с кол-по пол-ей от 1-2 (sql2)

Имеем хаотические проблемы связанные с кластером 8.3 , периодически очень долго запускаются базы 8.3 ( от 30 -5 минут)
и вылетают пол-и из за нехватки памяти.

Были проделаны работы:

а) Оптимизация работа по памяти кластера 8.3
параметры кластера:
Интервал перезапуска:86400
Интервал превышения допустимого объема памяти:30
Включенные процессы останавливать через:30
Приоритет по памяти

параметры рабочего сервера:
Безопасный расход памяти 512мб
Объем памяти рабочих процессов, до которого сервер считается проивод 700 мб
Кол-во ИБ на процесс: 1
Кол-во соединений на процесс 25

Решило проблему с вылетами

2) Перенастройка клиентов на поиск лицензии со стороны сервера с исправлением файла на сервере nethasp.ini
NH_SERVER_ADDR = 192.168.112.18
NH_USE_BROADCAST = Disabled
В данном случаи у нас 30 лицензий программных и ключ на 10 на 18 сервере.

3) После старта службы агента 8.3 в логах зафиксирована проблема:

Сбойное приложение ragent.exe, версия 8.3.5.1486, штамп времени 0x54f76689, сбойный модуль rtrsrvc.dll, версия 8.3.5.1486, штамп времени 0x54f7685d, код исключения 0xc0000005, смещение ошибки 0x00000000000020f4, ИД процесса 0xcb4, время запуска приложения 0x01d065fa56ec19bd.

4) Была попытка переставить платформу (8.3) с нуля, но ошибка осталась.

5) Было принято решение совместить базы с первым скулем.

6) Технический журнал 1с отдан по ИТС поддержке, ошибок не обнаружено.

На данный момент все ВМ лежат к кластере Hyper-V. Из предполаемых решений только 2:

а) Разнести службы на разных пользователей
6) Сменить диапазон портов на 8.3 службе
в) Поднять 2012 r2 (запланирован переход инфраструктуры под hyper-v 3.0) и установить скуль внутрь машины, посмотреть что будет.

Когда кластер 1c функционировал только как 1с 8.2, объем памяти был равен - 2 гб с 1 ядром. И никаких проблем с производительностью никогда не было. Поэтому увеличение ОЗУ до 4 гб и ядер до 2- ух, обусловлено тем, что базы работают в тестовом режиме. Учитывая что все транзакции у нас обрабатывает скуль а запросы делает пользователь как толстый клиент. Выставлять большее значение я на тот момент не видел смысла. При чем проблемы зафиксированы в основном утром, неважно один человек заходит или 4 сразу. В середине дня проблем не зафиксировано.

P.S. 8.2 работает как и раньше, с ней все хорошо.

Победа далась не легко….
Я постараюсь описать все детально, хотя и прошло довольно много времени. Надеюсь информация, собранная мною поможет системным администраторам и даст пишу для размышления.
Перенес я базы на 1 скуль и переназначил я пользователя для 8.3 агента – не помогло…

Исколесил я наш рунет вдоль и поперек и нашел две интересные статьи, которые предлагаю и вам ознакомиться.

Покопавшись где-то с недельку и перепробовав несколько методик, проблему с первым запуском я решить не смог. Но заметил одну интересную закономерность… При работе тонкого клиента, второй запуск системы происходит почти моментально. Изменил настройки кол-во ИБ на процесс: 8 (баз на 8.3 пока что 5). В итоге так как на создание RPHOST сервер перестал тратить время при заходе в след. базу и оставшееся он тратил только на выгрузку конфы из скуля. Сократил время старта второй баз на 10-7 секунд.

Такой вариант меня в принципе устраивает полностью, учитывая, что с каждой базой работает по 7-10 пользователей, конфа держится постоянно в RPHOSTe и время захода равняется 4-8 секундам с аутентификацией вместе.

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

Но всплыл еще один неприятный момент, на одном из форумов я получил вот такой ответ:
Offtop. У вас лицензии КОРП?

Расширенные возможности сервера уровня КОРП «1С:Предприятия 8.3» по сравнению с 64-разрядным сервером уровня ПРОФ:
* безопасный расход памяти за один вызов;
* количество ИБ на процесс;
* объем памяти рабочих процессов, до которого сервер считается производительным;
* максимальный объем памяти рабочих процессов;
*стратегия балансировки (по памяти, по производительности);

Использование перечисленных функциональных возможностей при помощи продуктов «1С:Предприятие 8. Лицензия на сервер (x86-64)» уровня ПРОФ, то есть не имеющих в названии обозначения КОРП, является неправомерным.

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

Фактически при использовании Платформы ПРОФ ,согласно лицензии, можно использовать только дефолтные настройки кластера.

Если при настройках кластера "по умолчанию" у Вас возникают проблемы (нехватка памяти, невозможность обновить конфигурацию и тд), то
данное поведение является ошибкой (либо платформы либо данного прикладного решения).
Просьба с конкретными примерами создавать обращения на исправление.
На время исправления ошибки может быть письменно выдано разрешение (за подписью директора ЗАО "1С") на использования функционала лицензии Корп.
2) >>> Прошу уточнить, т.е. есть две платформы 8.3?
Нет. Платформа не текущий момент одна.
Однако право использования функционала КОРП появляется только при покупке соответствующей лицензии.
Программного контроля данной лицензии на текущий момент также нет.
Таким образом лицензия КОРП является больше юридическим понятием.

Особой разницы тут нет какой именно скуль - MS или postgres
Особенность работы такая.
Локально все делается очень быстро, по сети немного подтормаживает, но не сильно критично если пинг низкий( в локальной сети) а вот издалека - это уже тормоза.
Cтавьте сервер разработчика рядом и работайте по RDP.
Хотя это конечно костыль.

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

А зачем в данном случае быстрый пинг? При обновлении конфигурации миллиард запросов что-ли идет на сервер? Странная схема обмена данными.
Скорее всего на винде поставлю сервер и с конфигуратором по RDP буду работать, чтобы конфигуратор локально находился.

При обновлении конфигурации миллиард запросов что-ли идет на сервер?

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

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

А зачем. Ну серьезно, зачем вам открывать конфигуратор на рабочей базе? АртемЪ, а разве можно потом накатить модернизированную конфигурацию на рабочую базу без конфигуратора?

webiru, Так кто мешает сделать это прямо на сервере?
Ставите платформу, и потом скриптом, что нибудь вроде -

Ну а потом UpdateDBCfg
То же самое с выгрузкой баз, и работой с хранилищем, реиндексацией, и прочими нужными вещами.

Я и на винде только скриптом обновления накатываю - в конфигураторе чтобы обновить приходится тыкнуть десяток раз на кнопки, причем между тыканьем кнопок приходится ждать по несколько минут или десятков минут, мне банально времени своего жалко.
Так оно без запуска графической оболочки еще и шустрее заметно работает.
На той же винде если обновление в конфигураторе накатывается 10минут, то с командной строки за 3-4минуты проскочит.

Нет, это ненормально. УНФ-ская конфа должна быстро загружаться. У меня на виртуальном сервере с Убунтой таких тормозов на этой конфигурации не было. Точно не помню, но сохранение явно было не дольше 10 минут (возможно даже в рамках 5 минут - уже года 3 не обслуживаю их сервер, просто забыл).

Мысли в слух:
1) Диск далеко не SSD и вообще на последнем издыхании.
2) Диск в порядке, но система в бесконечном свопе.
3) Администратор сервера урезал доступ к ресурсам для процессов сервера 1С (cgroup или подобное).

У меня на виртуальном сервере с Убунтой таких тормозов на этой конфигурации не было

А виртуальный сервер у вас далеко был? Какой пинг до него - 1мс или 60-100мс.

Пинги по разному шли 5-10-20. Но проблемы были на нашей стороне, а Хетцнер выдавал отличный канал связи. Вот только конфигуратором я пользовался прямо там (на хостинге), а потому все было довольно быстро.

Если Конфигуратор на другом конце Интернета.

Давай подумаем - при работе конфигуратора локальная копия конфигурации находится в локальном кеше единым файлом. Когда нажимаем на сохранение инициируется передача копии из кеша на сервер 1С с запись в СУБД в таблицу ConfigSave (где, на сколько я помню, делается единая запись с данными конфигурации). Т.е. выполняется копирование на сервер единого 400Мб-файл. Т.е. часы уходят на то, что бы скопировать один файл и записать его в СУБД.

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

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

Еще раз повторюсь: часовые затраты на обновление УНФ - это ненормально. Как же ERP будет обновляться? Сутками? :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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