diadocsdk-1c-docs
diadocsdk-1c-docs copied to clipboard
diadoc
Потребление памяти компонентой
Здравствуйте. Используем компоненту 5.39.1.865 x64 для произвольных систем, собственное решение. Компонента установлена у нас на сервере, через приложении Component Servises. Используем ее в многопоточном режиме. Если открыть диспетчер задач, видно активное потребление памяти, похожее на утечку. Приходится автоматически принудительно завершать выделенный процесс при превышении некоторого объема памяти. На самом деле оно было на разных версиях компоненты, поэтому не могу сказать, что это проблема именно указанной версии. Хотелось бы разобраться до конца. Последнее что пытались сделать - кэшируем com-объект и соединение с Organization, но к особым успехам не привело. Может быть есть какие-нибудь методы по освобождению памяти или рекомендации по работе с компонентой? Действия выполняем классические: создание объекта, подключение к ящику организации по сертификату, создание задания на отправку и отправка документов (УПД, неформализованные документы).
Если нужна дополнительная информация (dump с сервера (?), логи какие-либо (?)), напишите, пожалуйста, какая.
Добрый день
Можете поточнее описать последовательность действий, которая приводит к утечке памяти, в идеале минимальный пример: заполняете ли динамический контент, достаточно ли для воспроизведения отправлять документы в одному и тому же получателю или нужно всегда разным, сохраняете ли объект отправленного документа куда-то и что потом с этим объектом происходит и т.п.
Если вкрадце: У нас есть очередь, в нее помещаем документы информационной системы. Документов много. В очереди на каждый документ два этапа: отправка документа, подписание документа. Элементов очереди много. Очередь обрабатывается в несколько потоков (оба этапа в несколько потоков). На каждый элемент очереди выполняется последовательность действий:
- Создание com-объекта (ДиадокАПИ);
- Подключение по сертификату (ДиадокСоединение =ДиадокАПИ.CreateConnectionByCertificate);
- Подключение к ящику организации (КонтекстОрганизации = ДиадокСоединение.GetOrganizationById);
- Получение (Document = Organization.GetDocumentById) / отправка (SendTask = КонтекстОрганизации.CreatePackageSendTask2()) документа;
- Заполняем контент при отправке (UtdSellerContent = SendTask.Content.UniversalTransferDocumentWithHyphens);
- Читаем динамический контент: Document.GetDynamicContent("Seller") / Document.GetDynamicContent("Buyer");
- Сохраняем информацию из сервиса Диадок в нашу внутреннюю систему (Document.SaveAllContent(КаталогВыгрузкиФайлов, Истина)).
В рамках каждого потока кэшируем п.1-п.3.
достаточно ли для воспроизведения отправлять документы в одному и тому же получателю или нужно всегда разным Есть мнение, что все зависит от количества потоков и обрабатываемых элементов очереди. В тестовом окружении нагрузочного тестирования не проводим, поэтому потребление памяти незаметно. В рабочем же, время жизни процесса примерно 5 минут, достигает 6 Гб.
сохраняете ли объект отправленного документа куда-то и что потом с этим объектом происходит Нет, не сохраняем. Получаем Document, если никаких действий выполнять не нужно, переходим к следующему.
Настройка Component Servises:
Добрый день.
А можно узнать сколько памяти съедается и за какой период?
Просто я пару лет назад уже находил намеки на утечки, сообщал разработке, были правки и теперь все более-менее нормально. Раньше жестко утекало.
Сейчас тоже есть что-то похожее на постоянный жор памяти. Но происходит это относительно медленно. У нас на сервере ЭДО 16 Гб памяти и она постепенно "выжирается" в течение суток. Но, т.к. у нас каждое утро плановый перезапуск кластера, то с таким жором памяти мы живем нормально. Ну как - нормально - терпим, т.к. текущий уровень утечки пока не приводит к проблемам.
Но, вообще говоря, явно какие-то утечки остались, т.к. пусть очень медленно, но за день на серваке вся память стабильно съедается. Плюс бывают "всплески" этого выжирания. Вот даже специально не напрягаясь, просто зашел на сервер и увидел:
На этом сервере кластера у нас кроме фоновых ЭДО не крутиться больше вообще ничего.
А часто бывает, и так: еще день не прошел, вся память выжралась, кластер перезапускает rphost и получаем (вот только что произошло):
Т.е. мы "выживаем" скорее даже не потому, что память мало жреться, а потому, что rphost постоянно перезапускается, когда все выжрано.
Но было бы здорово, если бы такого жора не было!
После сброса сперва выжирается куча памяти (ну это нормально), а затем не спеша, гигов с 10 начинает потихоньку выжирать все до конца:
А часто бывает, и так: еще день не прошел, вся память выжралась, кластер перезапускает rphost и получаем (вот только что произошло):
Т.е. мы "выживаем" скорее даже не потому, что память мало жреться, а потому, что rphost постоянно перезапускается, когда все выжрано.
Но было бы здорово, если бы такого жора не было!
Вот из-за того, что rphost падает пришлось использовать Component Servises. При этом растет потребление памяти выделенного dllhost, а rphost не падает. Падение rphost для нас критично, т.к. в информационной системе работает большое количество пользователей и вместе с diadoccomapi падали они.
У нас падение rphost'a не критично, т.к. это отдельный сервер в кластере. И на этом сервере только фоновые ЭДО работают, больше ничего.
Но хотелось бы, конечно, чтобы этот жор памяти как-то победили.
Добрый день.
Раз тема по утечкам памяти по прежнему "висит", сделаю маленькое дополнение:
После перехода на версию 5.52.1.982 наблюдаем гораздо меньшее потребление памяти, чем на версии 5.46.1.920.
46-я постепенно на сервере потихоньку выжирала у нас всю память (16 Гб) за несколько часов. А 52-я на потреблении памяти показывает практически горизонтальную линию (выходит в район 8-9 Гб и там и остается, плавая потихоньку вверх-вниз).
Такое ощущение, что что-то поменяв и исправив последние ошибки, будто случайно, что-то задели и грохнули какую-то багу, которая ранее жрала память.
Сейчас проблем практически нет!
@JohnSergeev
Это замечательные новости! Мы действительно в последних релизах много чего переделывали и где-то могли поправить баги с утечками памяти. Предлагаю понаблюдать поведение подольше. Если не будет течь, то закроем тикет
Хотя кажется, 8-9 Гб как-то многовато для компоненты... Подумаем ещё и в этом направлении