Slow BizTalk File Receive

Question

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

То же приложение отлично работает в другой среде. В журнале событий есть очевидные записи, связанные с проблемой. Все задания BizTalk SQL работают отлично, за исключением Backup BizTalk Server (BizTalkMgmtDb).

Любые предложения с благодарностью получены.

Благодаря

Роб

Answer 1

Вот некоторые дополнительные инструменты, которые могут помочь вам идентифицировать и диагностировать проблемы базы данных BizTalk.

BizTalk MsgBox Viewer

Вот инструмент для ремонта выявленных ошибок:

Terminator

Используйте на свой страх и риск ... читать Glogs и документы. Начните с просмотра окна сообщений и сообщите нам о наших результатах.

Answer 2

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

1. В какой версии вы работаете?
2. Каковы размеры нашей базы данных?
3. Каковы настройки вашей очистки и архива?
4. Есть ли какие-нибудь длинные блоки в вашей базе данных SQL Server из BizTalk?

Answer 3

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

Wrox BizTalk Server 2006 также предоставит рекомендации по настройке.

Answer 4

Что еще происходит с сервером? Разве BizTalk привязан иначе или он простаивает?

Answer 5

Вы упомянули, что решение не имеет проблем в другой среде, поэтому вполне вероятно, что проблема с конфигурацией.

Проверьте следующее:

** На SQL Server, установить некоторые верхний предел памяти для SQL Server. По умолчанию SQL Server использует все, что он может получить, а затем зависает на нем, поэтому установите разумный предел, чтобы ваша система могла работать, не тратя много времени на пейджинговую память на ваш жесткий диск (и).

** Убедитесь, что у вас есть свободное место на диске - возможно, вы работаете на низком уровне - это может привести к возникновению всех странных проблем.

** Попробуйте разделить файл подкачки системы между его физическими дисками (если в системе имеется более одного диска). Также подумайте о том, чтобы использовать более быстрый диск, или если у вас много наличных денег, получите SAN.

** В BizTalk отслеживание включено? Если да, то вы также отслеживаете тела сообщений? Отключить слежение за движением или сообщениями и посмотреть, есть ли разница.

** Запустите монитор производительности и контролировать следующие счетчики при запуске вашего решения

• объект: BizTalk сообщения
• Instance: (выберите хост-получатель) %%

• Счетчик: Документы, полученные/Раздел

• объекта: сообщения BizTalk

• экземпляр: (выбери т ransmitting хост) %%

• Счетчик: документы, отправленные/сек

• Объекта: оркестровки XLANG/с

• Instance: (выберите хост обработки) %%
• счетчика: оркестровки Законченных/сек.

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

Предыдущие счетчики отслеживают самые основные аспекты вашего сервера, но могут помочь сузить места, чтобы смотреть дальше. Конечно, вы можете добавить процессор и память. Если у вас есть время (дни ... может быть, недели), вы можете отслеживать процессы, которые выделяют память и не выпускают ее. Используйте следующий счетчик ...

• Объект: Память
• Счетчик: Бассейн Nonpaged Bytes

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

Дайте нам знать, как все получится!

Answer 6

Некоторые хорошие предложения от других. Я добавлю:

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

Сколько у вас больших файлов?

В свойствах переноса файлов вашего места получения установите «переименование файлов», чтобы файлы были переименованы в течение 60 секунд.

Answer 7

У меня была такая же проблема, когда моя оркестровка была бездействующей в течение некоторого времени, потребовалось много времени для обработки первого сообщения. Статья EvYoung помогла мне решить эту проблему.

«Это вызвано разгрузкой домена приложения в хост-процессе BizTalk. Если AppDomain выключен после простоя, то следующее сообщение должно ждать повторной компиляции Orchestration. В зависимости от сложности вашего дизайна это может быть заметным ожиданием. Чтобы избежать этого в сценарии с низкой задержкой, вы можете изменить файл BTSNTSVC.EXE.config и установить для свойства SecondsIdleBeforeShutdown значение -1. ​​Это предотвратит выключение AppDomain из-за незанятости. "

Вы можете найти статью здесь: http://blogs.msdn.com/b/biztalkcpr/archive/2008/05/08/thoughts-on-orchestration-performance.aspx

меня ушло много времени, чтобы ответить, но я думал, что я мог бы помочь кому-то. ура :)