Сборка мусора в Biztalk, какой будет мудрый подход?

Question

Наше приложение Biztalk 2006 содержит две оркестровки, которые вызываются на частой основе (около 15 запросов в секунду). Мы выявили возможные утечки памяти в нашем приложении, выполнив определенные изменения порога регулирования на хосте. Когда мы отключили регулирование памяти, память процесса начала увеличиваться до 1400 МБ, и после этого мы начали испытывать исключения из нехватки памяти.
При возникновении такой ситуации мы вынуждены перезапустить экземпляры хоста.
Нам было интересно, если явный вызов GC.Collect из Orchestration будет плодотворным в таком случае. и какие могут быть недостатки использования этого подхода?

Спасибо.

Answer 1

Исключения нехватки памяти возникают, только если сборщик мусора не смог освободить достаточно памяти для выполнения запрошенного выделения. Это может произойти, если у вас есть утечка памяти, которая на платформе сбора мусора означает, что некоторые ссылки на объекты хранятся дольше, чем нужно. Частыми причинами утечек являются объекты, которые содержат глобальные данные (статические переменные), такие как одноэлементный файл, кэш или пул, который хранит ссылки слишком долго.

Если вы явно вызовете GC.Collect, он также не сможет освободить память по тем же причинам, что и при сбое неявного сбора. Поэтому вызов explit GC.Collect приведет только к замедлению оркестровки.

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

Также возможно, что утечки нет, но каждый экземпляр потребляет слишком много памяти одновременно. BizTalk обычно может обезвоживать оркестровки, когда сочтет это необходимым, но это может быть запрещено для этого, если выполнение шага в оркестрации (или большой атомный объем) занимает слишком много времени.

1400 МБ также выглядит большим только для 15 одновременных экземпляров. Вы делаете манипуляции с большими сообщениями в оркестровке? В этом случае вы можете значительно сократить использование памяти, избегая операций, которые заставляют все сообщение загружаться в память, и вместо этого манипулировать сообщением с использованием потоковой передачи.

Answer 2

Не зная Biztalk, мой ответ может быть далеко ...

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

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

Answer 3

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

Я хотел бы добавить, однако, что регулирование существует, чтобы защитить вашу среду от перебоев в работе, если вы столкнетесь с внезапным увеличением потребления ресурсов; без регулирования возможно, что BizTalk (как и любой другой сервер) достигнет точки, когда он не сможет продолжить обработку и эффективно "застрять"; регулирование позволяет замедлить его, чтобы гарантировать, что обработка все еще происходит, пока уровень потребления ресурсов (надеюсь) не вернется к нормальному уровню;

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

Answer 4

Сборка мусора не освобождает утечку памяти, так как на нее все еще (по ошибке) ссылаются ваши приложения. Вы бы позвонили в GC.Collect только в том случае, если вы много раз создавали недолговечные объекты и знали, что вы готовы освободить их.

Вы должны идентифицировать и исправить код утечки!

Answer 5

Я согласен с постером выше. Попытка очистить память или сбросить экземпляр хоста - это не решение проблемы, а всего лишь помощь. вам нужно найти, где у вас течет память. Я бы посмотрел на все приложение, а не только на оркестровку; Возможно, что порты также могут быть причиной утечки памяти. Используете ли вы пользовательские функтоиды на ваших картах? как насчет встроенного кода? Кастомный xslt? Я бы также посмотрел на пользовательские конвейеры, если вы их используете. Если бы это было возможно, я бы попытался выделить различные компоненты и подвергнуть их индивидуальному стресс-тестированию; почему-то я не думаю, что сама ваша оркестровка - это проблема, а карта или пользовательский компонент.