Проблема с сервером BizTalk

How many host instances do you have?

From the line:

The send and receive ports have a lot of different types: File, MQSeries, SQL, MLLP, FTP. Each of these types have a different host instances, to balance out the load. Our orchestrations use the BiztalkApplication host

It sounds like you have a lot - I recently did an audit of a system where BizTalk was self throttling and the issue was in part due to too many host instances. Each host instance places its own load upon the BizTalk messagebox, as well as chewing up a minimum of 200mb memory.

Reading your comment, you have 20 - this is too many and would be a big part of your problems.

A good starting host setup would be:

• A dedicated tracking host
• One host that contains all receive handlers for adapters
• One host that contains all orchestrations
• One host that contains all send handlers for adapters
• One host for adapters that need to be clustered (like FTP and MSMQ)

You can then also consider things like introducing "real time" hosts and batched hosts, so you can tune the real time hosts for low latency.

You can also have hosts for specific applications if there are known to be unstable, but in general this should not be done.

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

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

Боюсь, что я еще не решил проблему, но я нашел несколько вещей, которые могут решить эту проблему:

1. Увеличьте объем памяти для данного процесса, чтобы дросселирование не происходило или не происходило позже
2. Каждый хост Экземпляр, хотя и информативен, имеет дополнительные накладные расходы. Попробуйте объединить хосты, которые не являются вашими проблемными детьми, вместе, чтобы уменьшить объем памяти.
3. Используйте оборудование, оперативная память стоит дешево

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

   BizTalk: MessageAgent (*) \ Использование памяти процессом (МБ)

   BizTalk: MessageAgent (*) \ Пороговое значение использования памяти процесса

   Память \ Доступные МБ

Еще несколько моментов, на которые стоит обратить внимание. Убедитесь, что все настраиваемые конвейеры используют правильные методы работы с памятью BizTalk (т. Е. Никаких скрытых манипуляций с XML DOM и т. Также теоретически уменьшение количества потоков для данного хоста должно снизить объем памяти, который он может занять за один раз. Похоже, мне не повезло с этим. Возможно, регулирование BizTalk перекрыло его, как упоминали другие, я не знаю. Кроме того, в заключение, если вы сбрасываете результаты perfmon в csv, с помощью Excel вы можете сделать несколько красивых графиков использования памяти. Это может быть полезно для разговора с руководством о покупке дополнительного оборудования. Предполагается, что ваша проблема также соответствует этому сценарию.

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

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

We fixed the problem temporarily due to a combination of all ur answers.

We set the process memory usage throttling parameters of some hosts higher.

We divided the balance of the host instances better after I analyzed all the memory usage of all hosts, thanks to performance counters and also with the use of a tool called MsgBoxViewer.

And now we're trying to get more physical memory & hopefully also an extra server or a 64bit server.

Thanks for all replies!

Недавно мы установили 64-разрядный сервер в кластере с нашим старым сервером. Благодаря этому мы можем еще лучше сбалансировать память, что решило множество проблем.

Хотя 64-разрядная версия не дала нам особых улучшений (за исключением немного большего объема памяти), так как она не может использовать 64-разрядную версию в конвейерах IBM MQ, MLLP, HL7 и т. Д ...

{{1 }}