파일 수신 위치가있는 응용 프로그램이 있습니다. 호스트 인스턴스가 몇 시간 동안 실행 된 후 수신 위치는 모니터링중인 폴더에 놓인 새 파일을 식별하지 못합니다. 그것들 모두를 잊지 않고, 단지 그 성능이 기어 다니기 만하면됩니다. 수신 위치는 매 60 초마다 대상 폴더를 폴링하도록 구성되지만 호스트 인스턴스가 1 시간 정도 실행 된 후에는 대상 폴더가 30 분마다 폴링되는 것으로 보입니다. 호스트 인스턴스를 다시 시작하면 대상 폴더에서 대기중인 파일이 즉시 수집되고 다음 시간 정도 성능이 양호합니다.느린 BizTalk 파일 받기
동일한 응용 프로그램이 다른 환경에서 정상적으로 실행됩니다. 문제와 관련된 이벤트 로그에 명백한 항목이 있습니다. 백업 BizTalk Server (BizTalkMgmtDb)를 제외한 모든 BizTalk SQL 작업이 제대로 실행 중입니다.
감사의 말씀을드립니다.
감사
롭
다음은 BizTalk 데이터베이스 문제를 식별하고 진단하는 데 도움이되는 몇 가지 추가 도구입니다. 자신의 위험에
사용 ... glogs 및 문서를 읽어 여기에
이 확인 된 오류를 복구하는 도구입니다. 메시지 상자 뷰어로 시작하여 결과를 알려주십시오.나는이 문제가 msgbox와 관련이 없다고 생각합니다. BizTalk SQL 서버의 상태를 철저히 검사하면 아무런 문제가 없습니다. 이 응용 프로그램을 다른 환경에서 실행해도 문제가 발생하는 환경은로드 테스트를받는 유일한 환경이며 문제가있는 수신 위치가이 특정 NAS 상자에서 수신되도록 구성된 유일한 환경입니다 –
사과 Chris - 네가 자리하고 있었어. MsgBox 뷰어를 실행하여 수신 호스트가 데이터베이스 크기로 인해 조절되고 있음을 알 수있었습니다. msgbox를위한 공간을 확보하고 DB를 추적 할 때 스로틀 링이 중지되었습니다. 조절을 식별하는 프로세스를 설명하는 http://blogs.msdn.com/biztalkcpr/default.aspx에 멋진 블로그가 있습니다. 남은 문제 - 터미네이터를 사용하면 도움이 될 수 있지만 웹에 연결되어있을 때만 실행될 수 있습니다. 불행히도 BizTalk DB 서버에 액세스 할 수있는 모든 서버에서 웹에 연결할 수 없습니다. –
터미네이터는 DB에 액세스 할 수있는 모든 관리자가 실행할 수 있습니다. BizTalk에서 실행할 필요가 없습니다. 결국 DB 도구입니다. 나는 다른 이유로 블로그 게시물을 읽으려는 중 일부 문제를 겪고 있습니다. 고마워! –
자세한 내용은없이, 가장 큰 텔이 백업 작업이 실패한다는 것입니다. 백업 작업이 실패하면 제대로 구성되지 않았을 수 있습니다. 제대로 구성되어 여전히 실패하면 다른 문제가 있습니다. BizTalk 설치에 대한 추가 정보를 제공해 줄 수 있습니까?
안녕하세요 Chris, SQL Server 2005를 사용하는 두 노드 BizTalk 그룹에서 BTS2006 엔터프라이즈를 실행하고 있습니다. 그룹의 BTS 데이터베이스는 다른 서버에 설치됩니다. 모든 서버는 높은 사양이며, BTS 박스는 42GB RAM을 갖춘 쿼드 CPU이며, SQL 상자는 84GB 램을 가진 8cpu입니다. BTS 및 SQL 상자는 거의 유휴 상태로 실행됩니다. 이제 모든 BizTalk 작업이 문제없이 구성되고 실행됩니다. 추적 DB는 현재 9GB의 데이터, 1GB의 트랜잭션 로그입니다. MsgBox db는 현재 4GB 데이터, 4GB 트랜잭션 로그입니다. 장기 실행 블록이 없습니다. –
또 다른 고려해야 할 사항은 보내기, 수신 및 오케스트레이션 호스트가 실행중인 사용자 계정입니다. BizTalk 관리 콘솔을 확인하십시오. 모두 동일한 계정을 실행하고있는 경우 오케스트레이션은 보내고받는 CPU 시간의 프로세스를 굶주릴 수 있습니다. 오케스트레이션에 우선 순위를 부여한 다음 수신 한 다음 보내십시오. 개발 중이 라해도 별도의 계정을 사용하는 것이 좋습니다. 또한 보안이 향상됩니다.
Wrox BizTalk Server 2006은 튜닝 조언도 제공합니다.
receive, orchestration 및 send에 대해 별도의 호스트 인스턴스가 있습니다. 이들 각각은 동일한 도메인 계정을 사용하지만 문제가 발생할 것이라고 생각하지 않습니다. –
서버와 관련된 다른 모든 작업은 무엇입니까? 그렇지 않으면 BizTalk가 고정되어 있습니까? 아니면 유휴 상태입니까?
그렇지 않으면 유휴입니다 –
솔루션은 다른 환경에서는 문제가 없으므로 구성 문제가있을 수 있습니다.
는 다음을 확인하십시오
SQL Server에 대한 일부 상위 메모리 제한을 설정 SQL 서버에**. 기본적으로 SQL Server는 얻을 수있는 모든 것을 사용하고 그 위에 걸려 있으므로 합리적인 한도를 설정하여 시스템이 하드 드라이브에 메모리를 페이징하는 데 많은 시간을 소비하지 않고도 작동 할 수 있도록하십시오.
** 사용 가능한 디스크 공간이 충분한 지 확인하십시오. 어쩌면 낮은 상태 일 수 있습니다. 이렇게하면 모든 종류의 이상한 문제가 발생할 수 있습니다.
** 시스템의 페이징 파일을 물리적 드라이브로 분할하십시오 (시스템에 둘 이상의 드라이브가있는 경우). 또한 더 빠른 드라이브 사용을 고려하거나 많은 현금을 가지고 있다면 SAN을 얻으십시오.
** BizTalk에서 추적 기능을 사용할 수 있습니까? 그렇다면 메시지 본문을 추적하고 있습니까? 압정이나 메시지 본문 추적을 비활성화하고 차이점이 있는지 확인하십시오. 솔루션을 실행할 때
** 성능 모니터를 시작하고 다음 카운터를 모니터링
카운터 : 문서를 수신/초
대상 : BizTalk 메시징
카운터 : 문서/초를
객체를 보냄 : XLANG/S 오케스트레이션
%% 호스트가 하나만 있어도됩니다. BizTalk 구성이 다양하기 때문에 호스트에 대해 일반적인 이름을 사용하고 있습니다.
앞의 카운터는 서버의 가장 기본적인 측면을 모니터링하지만 더 자세히 보일 수있는 곳을 좁히는 데 도움이 될 수 있습니다. 물론 CPU와 메모리를 추가 할 수도 있습니다. 시간이 있다면 (일 ... 어쩌면 몇 주) 메모리를 할당하는 프로세스를 모니터링하고 결코 해제 할 수 없습니다. 다음 카운터를 사용하여 ...
느린 쇠퇴가 프로세스가 시스템에 모두 영향을 미치는 메모리를 해제하지 않음을 나타냅니다 .
어떻게되는지 알아 보겠습니다.
다른 사람들로부터 좋은 제안. 내가 추가 할 것입니다 :
수신 위치에 사용자 지정 수신 파이프 라인 구성 요소가 있습니까? 그렇다면 아마도 하나의 메모리가 누수되고, 외부 구성 요소 (예 : 오랜 시간이 걸리는 데이터베이스)를 호출 할 것입니까?
받는 파일의 크기는 얼마나됩니까?
수신 위치의 파일 전송 속성에서 "파일 이름 바꾸기"를 설정하면 파일 이름이 60 초 이내에 바뀌게됩니다.
제 오케스트레이션이 한동안 유휴 상태 였을 때 첫 번째 메시지를 처리하는 데 오랜 시간이 걸렸습니다. Evyoung 기사를 통해이 문제를 해결할 수있었습니다.
"BizTalk 호스트 프로세스 내에서 응용 프로그램 도메인 언로드로 인해 발생합니다. 유휴 상태에서 AppDomain이 종료되면 다음에 오는 메시지는 오케스트레이션이 다시 컴파일 될 때까지 기다려야합니다. 디자인의 복잡성에 따라 낮은 대기 시간 요구 사항 시나리오에서이를 방지하려면 BTSNTSVC.EXE.config 파일을 수정하고 SecondsIdleBeforeShutdown 속성을 -1로 설정하면 유휴로 인해 AppDomain이 종료되지 않습니다. " http://blogs.msdn.com/b/biztalkcpr/archive/2008/05/08/thoughts-on-orchestration-performance.aspx
그것은 응답하는 긴 날을했다하지만 난 내가 누군가를 도와 줄 알았는데 :
여기에있는 문서를 찾을 수 있습니다. 건배 :
네트워크와 관련이 있습니까? UNC 경로를 통해 파일을 가져 오는 중입니까? – Riri