PAL(로그 성능 분석) 도구를 사용하여 성능 카운터를 사용하여 보고서 및 차트 생성 BizTalk Server

아티클
09/28/2023

PAL(로그 성능 분석) 도구는 성능 모니터 카운터 로그(알려진 형식)를 읽고 복잡하지만 알려진 임계값(제공됨)을 사용하여 분석합니다. 이 도구는 중요한 성능 카운터를 그래픽으로 차트로 표시하고 임계값을 초과할 때 경고를 throw하는 HTML 기반 보고서를 생성합니다. 임계값은 원래 BizTalk Server 및 Microsoft 지원 구성원을 포함하여 Microsoft 제품 팀에서 정의한 임계값을 기반으로 합니다. 이 도구는 기존 성능 분석을 대체하는 것은 아니지만 시간을 절약할 수 있을 만큼 성능 카운터 로그 분석을 자동화합니다. PAL 도구:

임계값에 대한 성능 카운터 로그 분석
큰 Perfmon 로그에 유용합니다.
임계값을 분석하여 BizTalk Server 및 운영 체제 성능 카운터 병목 상태를 식별합니다.
성능 카운터에서 분석을 수행할 수 있습니다.
사용자 고유의 카운터를 작성하는 데 사용할 수 있습니다.

PAL은 GitHub에서 무료로 다운로드할 수 있습니다. Microsoft Log Parser가 필요합니다. 로그 파서는 로그 파일, XML 파일 및 CSV 파일과 같은 텍스트 기반 데이터뿐만 아니라 이벤트 로그, 레지스트리, 파일 시스템 및 Active Directory 디렉터리® 서비스와 같은 Windows 운영 체제의 주요 데이터 원본에 대한 범용 쿼리 액세스를 제공하는 강력하고 다양한 도구입니다. 이 도구를 사용하여 상당한 양의 로깅 정보를 쿼리할 수 있습니다. 로그 파서 도구를 다운로드할 수 있습니다.

다른 언어로 성능 카운터 로그와 함께 PAL 사용

PAL 도구는 영어로만 성능 카운터 로그를 분석합니다. PAL 도구를 다른 언어의 성능 카운터 로그와 함께 사용하려면 먼저 로그를 영어로 번역해야 합니다. Perfmon Log Translator를 사용하여 원래 성능 카운터 로그 파일을 영어로 변환할 수 있습니다.

Microsoft BizTalk Server 2010용 PAL 도구 보고서 이해

PAL 도구는 Windows 운영 체제, Microsoft SQL Server 및 BizTalk Server 대한 임계값에 대한 Perfmon 로그 분석을 제공합니다. 이 섹션에서는 PAL 도구의 BizTalk Server 임계값 보고서에 있는 대부분의 분석에 대해 설명합니다.

참고

이 항목은 PAL 도구에 대한 포괄적인 정보를 한 곳에 포함하여 쉽게 참조할 수 있도록 하는 데 오래 걸립니다.

PAL 도구에서 보고하는 분석 및 임계값은 다음과 같습니다.

분석 유형 및 이름	분석 설명
디스크: 커널 덤프에 사용할 수 있는 디스크 공간	이 분석은 운영 체제가 모든 메모리를 디스크에 덤프할 수 있는 충분한 사용 가능한 디스크 공간이 있는지 확인합니다. 디스크 공간이 부족한 경우 운영 체제에서 커널 덤프의 근본 원인을 분석하는 데 필요한 memory.dmp 파일을 만들지 못합니다.
디스크: 논리/실제 디스크 인터페이스 분석	이 분석은 각 실제 디스크의 유휴 시간을 확인합니다. 디스크가 유휴 상태일수록 디스크가 더 적게 사용됩니다. 이 카운터는 논리 디스크에서 하나의 디스크를 사용할 때 가장 적합합니다. "% 유휴 시간"은 디스크가 유휴 상태인 샘플 간격 동안의 시간 백분율을 보고합니다. 참조: Disk-Bound 문제 배제
디스크: 논리/실제 디스크 읽기/쓰기 대기 시간 분석	Windows에서 디스크 성능 병목 상태를 감지하는 가장 신뢰할 수 있는 방법은 응답 시간을 측정하는 것입니다. 응답 시간이 보수적 임계값인 .025(25밀리초)보다 큰 경우 사용자에게 영향을 주는 눈에 띄는 속도 저하 및 성능 문제가 발생할 수 있습니다. 자세한 내용은 이 항목의 논리/실제 디스크 읽기/쓰기 대기 시간 분석을 참조하세요.
디스크: 논리 디스크 전송/초	"Disk Transfers/sec"는 디스크의 읽기 및 쓰기 작업 속도입니다. 이 분석에 대한 임계값은 논리 디스크 중 하나라도 응답 시간이 좋지 않은지(I/O 작업에 대한 응답 시간 25ms 초과)를 표시하는지 확인하는 검사. 이 경우 초당 디스크 전송은 80 이상이어야 합니다. 그렇지 않은 경우 디스크 아키텍처를 조사해야 합니다. 디스크 I/O 불량의 가장 일반적인 원인은 SAN에서 LUN 오버로드입니다. 자세한 내용은 이 항목의 논리 디스크 전송/초를 참조하세요.
디스크: LogicalDisk % 사용 가능한 공간	"% 사용 가능한 공간"은 선택한 논리 디스크 드라이브에서 사용 가능한 총 공간의 백분율입니다. 사용 가능한 디스크 드라이브 공간이 30% 미만일 때까지 성능에 영향을 미치지 않아야 합니다. 디스크 드라이브의 70%를 사용하는 경우 나머지 사용 가능한 공간은 낮은 성능 수준에서 작동하는 디스크 드라이브의 중앙에 있는 디스크의 스핀들 가까이에 위치합니다. 사용 가능한 디스크 공간이 부족하면 디스크 성능이 저하될 수 있습니다.
디스크: 프로세스 IO 데이터 작업/초 및 프로세스 IO 기타 작업/초 분석	이러한 카운터는 파일, 네트워크 및 디바이스 I/O를 포함하기 위해 프로세스에서 생성된 모든 I/O 작업을 계산합니다. 이러한 분석은 프로세스가 초당 1,000개 이상의 I/O를 수행하고 경고로 플래그를 지정하는 경우 검사. 이러한 분석은 디스크 분석과 같은 다른 분석과의 상관 관계에 가장 잘 사용되어 I/O 활동에 포함될 수 있는 프로세스를 결정합니다.
메모리: 사용 가능한 메모리	이 분석은 사용 가능한 총 메모리가 낮은지 여부를 확인합니다. 사용 가능한 메모리가 10%인 경고 및 사용 가능한 5%의 위험 경고를 확인합니다. 시간당 10MB의 감소 추세가 감지되면 경고가 표시되며, 이는 예정된 메모리 상태를 나타낼 수 있습니다. 실제 메모리가 부족하면 권한 있는 모드 CPU 및 시스템 지연이 증가할 수 있습니다. 자세한 내용은 이 항목의 사용 가능한 MemoryAnalysis를 참조하세요.
메모리: 무료 시스템 페이지 테이블 항목	무료 시스템 페이지 테이블 항목(PTE)은 현재 시스템에서 사용하지 않는 페이지 테이블 항목의 수입니다. 이 분석은 무료 PTE가 10,000개 미만인 경우 경고와 함께 5,000개 미만의 무료 PTE가 있는지 확인하여 시스템이 PTE가 부족한지 여부를 결정합니다. 충분한 PTE가 부족하면 시스템 전체 중단이 발생할 수 있습니다. 또한 /3GB 스위치는 무료 PTE의 양을 크게 낮출 것입니다. 자세한 내용은 이 항목의 무료 시스템 페이지 테이블 항목 분석을 참조하세요.
메모리: 메모리 누수 감지	이 분석은 프로세스 중 어느 프로세스에서 많은 양의 시스템 메모리를 소비하는지 여부와 시간이 지남에 따라 프로세스가 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 프로세스에서 메모리를 다시 시스템으로 반환하는 한 많은 양의 메모리를 사용하는 프로세스는 괜찮습니다. 차트에서 증가하는 추세를 찾습니다. 오랜 기간 동안 추세가 증가하면 메모리 누수일 수 있습니다. "프라이빗 바이트"는 이 프로세스가 다른 프로세스와 공유할 수 없는 할당된 메모리의 현재 크기(바이트)입니다. 이 분석은 시간당 10MB, 시간당 5MB 증가 추세를 확인합니다. PAL에서 사용 가능한 메모리 분석과 상관 관계로 이 분석을 사용합니다. 자세한 내용은 이 항목의 메모리 누수 감지 분석을 참조하세요.
메모리: 누수 감지 처리	이 분석은 모든 프로세스를 검사하여 각 프로세스에 열려 있는 핸들 수를 확인하고 핸들 누수 의심 여부를 확인합니다. 핸들 수가 많거나 공격적인 상승 추세가 있는 프로세스는 핸들 누수를 나타낼 수 있으며, 이로 인해 일반적으로 메모리 누수가 발생할 수 있습니다. 이 프로세스에서 현재 열려 있는 총 핸들 수는 이 프로세스의 각 스레드에서 현재 열려 있는 핸들의 합계와 같습니다. 참조: 디버그 진단 도구
메모리: Memory Pages Input/sec	"Pages Input/sec"는 하드 페이지 오류를 resolve 디스크에서 페이지를 읽는 속도입니다. 하드 페이지 오류는 프로세스가 가상 메모리의 작업 집합이나 실제 메모리의 다른 위치에 있지 않고 디스크에서 검색해야 하는 페이지를 참조할 때 발생합니다. 이 분석은 초당 10개 이상의 페이지 파일 읽기가 있는지 확인합니다.
메모리: Memory Pages/sec	이 분석은 "Pages/sec"가 높은지 확인합니다(1,000 이상). 높은 경우 시스템에서 메모리를 디스크에 페이징하려고 시도하여 메모리가 부족할 수 있습니다. "Pages/sec"는 하드 페이지 오류를 resolve 위해 디스크에서 페이지를 읽거나 디스크에 쓰는 속도입니다. 이 카운터는 시스템 전체 지연을 유발하는 오류의 종류에 대한 기본 지표입니다. PAL에서 사용 가능한 메모리 분석 및 메모리 누수 감지 분석과 상관 관계에 이 분석을 사용합니다. 이러한 모든 분석이 동시에 경고를 throw하는 경우 시스템이 메모리 부족 및 관련된 의심되는 프로세스를 나타내고 PAL의 메모리 누수 감지 분석에 언급된 분석 단계를 따를 수 있습니다. 자세한 내용은 이 항목의 메모리 페이지/초 분석을 참조하세요.
메모리: 메모리 시스템 캐시 상주 바이트	"시스템 캐시 상주 바이트"는 파일 시스템 캐시에 있는 페이징 가능한 운영 체제 코드의 크기(바이트)입니다. 이 값은 현재 실제 페이지만 포함하며 현재 상주하지 않는 가상 메모리 페이지는 포함하지 않습니다. 이 값은 현재 실제 메모리에 있는 모든 페이징 가능한 운영 체제 코드를 나타내는 "Memory\\System Code Resident Bytes"의 구성 요소입니다. 이 카운터는 마지막으로 관찰된 값만 표시하며, 평균이 아닙니다. 이 분석은 시간당 10MB의 증가 추세를 확인합니다. 로드 중인 서버는 디스크와 같은 I/O 작업을 캐시하기 위해 시스템 캐시를 사용할 수 있습니다. PAL에서 Process IO Data Operations/sec 및 Process IO Other Operations/sec 분석과 상관 관계에 사용합니다. 참조: 파일 캐시 성능 및 튜닝
메모리: 풀 비 페이징 바이트	"풀 비페이지 바이트"는 디스크에 쓸 수 없지만 할당된 경우 실제 메모리에 남아 있어야 하는 개체의 시스템 메모리 영역인 비페이징 풀의 크기(바이트)입니다. 이 분석은 시스템이 페이징되지 않은 최대 풀 메모리 크기에 근접하는지 확인합니다. /3GB, 실제 메모리 크기 및 32비트/64비트 등을 고려하여 풀 크기를 추정한 다음, 값이 예상 풀 크기의 60%보다 높은지 여부를 결정합니다. 시스템이 최대 크기에 가까워지면 시스템에서 시스템 전체 중단이 발생할 수 있습니다. boot.ini 파일의 /3GB 스위치 옵션은 이 메모리 풀의 크기를 크게 줄입니다. 자세한 내용은 이 항목의 풀 비 페이징 바이트 분석을 참조하세요.
메모리: 풀 페이징 바이트	이 분석은 시스템이 최대 풀 페이징 메모리 크기에 근접하는지 확인합니다. /3GB, 실제 메모리 크기 및 32비트/64비트 등을 고려하여 풀 크기를 추정한 다음, 값이 예상 풀 크기의 60%보다 높은지 여부를 결정합니다. 시스템이 최대 크기에 가까워지면 시스템에서 시스템 전체 중단이 발생할 수 있습니다. boot.ini 파일의 /3GB 스위치 옵션은 이 메모리 풀의 크기를 크게 줄입니다. 자세한 내용은 이 항목의 풀 페이징 바이트 분석을 참조하세요.
메모리: 프로세스 스레드 수	이 분석은 모든 프로세스를 검사하여 프로세스에 500개 이상의 스레드가 있는지 여부와 스레드 수가 시간당 50개 스레드씩 증가하는지 여부를 확인합니다. 많은 수의 스레드 및/또는 공격적인 상향 추세가 있는 프로세스는 일반적으로 메모리 누수 또는 높은 컨텍스트 전환을 초래하는 스레드 누수를 나타낼 수 있습니다. 높은 컨텍스트 전환으로 인해 높은 권한 모드 CPU가 발생합니다.
메모리: 프로세스 작업 집합	"작업 집합"은 이 프로세스의 작업 집합의 현재 크기(바이트)입니다. 작업 집합은 프로세스의 스레드에서 최근에 터치한 메모리 페이지 집합입니다. 컴퓨터의 여유 메모리가 임계값을 초과하면 페이지가 사용되지 않더라도 프로세스의 작업 집합에 남아 있습니다. 사용 가능한 메모리가 임계값 아래로 떨어지면 페이지가 작업 집합에서 잘립니다. 필요한 경우 기본 메모리를 떠나기 전에 작업 세트로 다시 소프트 폴트가 발생합니다. 이 분석은 각 프로세스에서 10MB 이상의 증가 추세를 확인합니다. PAL에서 사용 가능한 메모리 분석과 상관 관계에 사용합니다. 참조: 병목 현상 찾기 및 제거
네트워크: 네트워크 출력 큐 길이 분석	이 분석은 네트워크 어댑터에서 대기 중인 스레드 수를 확인합니다. 많은 스레드가 네트워크 어댑터에서 대기하는 경우 시스템은 네트워크 대기 시간 또는 네트워크 대역폭으로 인해 네트워크 I/O를 포화시키는 것일 수 있습니다. "출력 큐 길이"는 출력 패킷 큐의 길이(패킷)입니다. 이 시간이 2보다 긴 경우 지연이 표시되며 가능한 경우 병목 상태를 찾아 제거해야 합니다. 네트워크 출력 큐의 일반적인 원인으로는 적은 수의 네트워크 요청 및 네트워크 대기 시간이 많이 포함됩니다.
네트워크: 네트워크 사용률 분석	"Bytes Total/sec"는 프레임 문자를 포함하여 각 네트워크 어댑터를 통해 바이트를 보내고 받는 속도입니다. "Network Interface\Bytes Received/sec"는 "Network Interface\Bytes Received/sec" 및 "Network Interface\Bytes Sent/sec"의 합계입니다. 이 카운터를 사용하면 네트워크 어댑터의 트래픽이 포화 상태에 있는지 여부와 다른 네트워크 어댑터를 추가해야 하는지 여부를 알 수 있습니다. 문제를 얼마나 빨리 식별할 수 있는지는 가지고 있는 네트워크 유형과 다른 애플리케이션과 대역폭을 공유하는지 여부에 따라 달라집니다. 이 분석은 "Bytes Total/sec"를 비트로 변환하고 네트워크 어댑터의 현재 대역폭과 비교하여 네트워크 사용률을 계산합니다. 다음으로 50% 이상의 사용률을 확인합니다. 참조: .NET Core에서 EventCounters를 사용하여 성능 측정
페이징 파일: 페이징 파일 % 사용량 및 % 사용량 최고	사용 중인 페이지 파일의 instance 백분율입니다. "Process\\Page File Bytes"도 참조하세요. 이 분석은 사용 비율이 70%보다 큰지 확인합니다.
프로세서: 프로세서 사용률 분석 및 프로세스별 과도한 프로세서 사용	이 카운터는 프로세서 작업의 기본 표시기이며 샘플 간격 동안 관찰된 사용 시간의 평균 백분율을 표시합니다. 서비스가 비활성 상태인 시간을 모니터링하고 해당 값을 100%에서 빼서 계산합니다. 이 분석은 각 프로세서에서 60% 이상의 사용률을 확인합니다. 그렇다면 높은 사용자 모드 CPU인지 높은 권한 모드인지 확인합니다. 높은 권한 모드 CPU가 의심되는 경우 PAL에서 권한 있는 모드 CPU 분석을 참조하세요. 사용자 모드 프로세서 병목 현상이 의심되는 경우 프로세스 프로파일러를 사용하여 높은 CPU 사용량을 유발하는 함수를 분석하는 것이 좋습니다.
프로세서: 프로세서 큐 길이	이 분석은 평균 프로세서 큐 길이가 프로세서 수를 초과하는지 여부를 결정합니다. 그렇다면 프로세서 병목 상태를 나타낼 수 있습니다. PAL에서 권한 있는 모드 CPU 분석 및 프로세스별 과도한 프로세서 사용 분석과 상관관계에서 이 분석을 사용합니다. 자세한 내용은 이 항목의 프로세서 큐 길이 분석을 참조하세요.
프로세서: 권한 있는 모드 CPU 분석	이 카운터는 스레드가 권한 있는 모드에서 실행되는 시간의 백분율을 나타냅니다. 애플리케이션이 운영 체제 함수를 호출하는 경우(예: 파일 또는 네트워크 I/O를 수행하거나 메모리를 할당하기 위해) 이러한 운영 체제 함수는 권한 있는 모드로 실행됩니다. 이 분석은 권한 있는 모드 CPU가 총 CPU의 30% 이상을 사용하는지 확인합니다. 그렇다면 CPU 사용량은 네트워크, 메모리 또는 디스크 I/O와 같은 프로세서 이외의 다른 병목 현상으로 인해 발생할 수 있습니다. 프로세서와의 상관 관계에 사용: % 인터럽트 시간 및 프로세서: PAL에서 높은 컨텍스트 전환 분석. 자세한 내용은 이 항목의 권한 있는 모드 CPU 분석을 참조하세요.
프로세서: 인터럽트 시간	"% 인터럽트 시간"은 프로세서가 샘플 간격 동안 하드웨어 인터럽트 수신 및 서비스를 소비하는 시간입니다. 이 값은 시스템 클럭, 마우스, 디스크 드라이버, 데이터 통신 회선, 네트워크 인터페이스 카드 및 기타 주변 장치 등과 같이 인터럽트를 발생시킨 장치 활동의 간접 표시기입니다. 일반적으로 이러한 장치는 작업을 완료하거나 주의가 필요한 경우에 프로세서를 인터럽트합니다. 인터럽트 동안 일반 스레드 실행은 일시 중단됩니다. 대부분의 시스템 클럭은 프로세서를 10밀리초마다 인터럽트하여 인터럽트 작업 백그라운드를 만듭니다. 이 카운터의 급격한 증가는 잠재적인 하드웨어 문제를 나타냅니다. 이 분석은 30% 이상의 "% 인터럽트 시간"을 확인합니다. 이 경우 이 경고와 상관 관계가 있는 하드웨어용 디바이스 드라이버를 업데이트하는 것이 좋습니다. 참조: .NET Core에서 EventCounters를 사용하여 성능 측정
프로세서: 높은 컨텍스트 전환	컨텍스트 전환은 우선 순위가 높은 스레드가 현재 실행 중인 우선 순위가 낮은 스레드를 선점하거나 우선 순위가 높은 스레드가 차단되는 경우에 발생합니다. 많은 스레드가 동일한 우선 순위 수준을 공유하는 경우 높은 수준의 컨텍스트 전환이 발생할 수 있습니다. 이는 시스템의 프로세서에 대해 너무 많은 스레드가 경쟁하고 있음을 나타내는 경우가 많습니다. 일반적으로 프로세서당 초당 5,000개 미만의 컨텍스트 전환 속도는 걱정할 가치가 없습니다. 컨텍스트 전환 속도가 프로세서당 초당 15,000을 초과하는 경우 제약 조건이 있습니다. 자세한 내용은 이 항목의 높은 컨텍스트 전환 분석을 참조하세요.
Microsof BizTalk Server: BizTalk 탈수 오케스트레이션	많은 장기 실행 비즈니스 프로세스가 동시에 실행되는 경우 메모리 및 성능 문제가 발생할 수 있습니다. 오케스트레이션 엔진은 오케스트레이션 인스턴스를 "디하이드레이션" 및 "리하이드레이션"하여 이러한 문제를 해결합니다. 디하이드레이션은 오케스트레이션의 상태를 SQL Server 데이터베이스로 serialize하는 프로세스입니다. 리하일레이션은 데이터베이스에서 오케스트레이션의 마지막 실행 상태를 역직렬화하는 이 프로세스의 반대입니다. 디하이드레이션은 메모리에서 한 번에 인스턴스화되어야 하는 오케스트레이션 수를 줄여 시스템 리소스의 사용을 최소화하는 데 사용됩니다. 따라서 디하이레이션은 메모리 소비를 절약하지만 비교적 비용이 많이 드는 작업입니다. 이 분석은 10개 이상의 탈수를 확인합니다. 이 경우 BizTalk Server 메모리가 부족하거나(가상 또는 물리적) 메시지에서 많은 오케스트레이션이 대기 중이거나 탈수 설정이 제대로 설정되지 않습니다. 참조: 오케스트레이션 탈수 및 리하이드레이션
Microsoft BizTalk Server: BizTalk High Database Sessions	이 카운터에는 정상(0) 또는 초과(1)의 두 가지 가능한 값이 있습니다. 이 분석은 값 1을 확인합니다. 그렇다면 BizTalk가 허용되는 데이터베이스 세션 수 임계값을 초과했습니다. 이 값은 BizTalk 호스트 제한 설정의 "CPU당 데이터베이스 연결" 값에 의해 제어됩니다. "CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. BizTalk:Message Agent 성능 개체 범주에 있는 Database session 성능 카운터를 사용하여 활성 데이터베이스 연결 수를 모니터링할 수 있습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. 자세한 내용은 이 항목의 BizTalk High Database Sessions Analysis를 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 데이터베이스 크기	데이터베이스 임계값의 메시지 수에 대해 나열된 조건 중 하나가 발생하는 경우 이 카운터는 값 1로 설정됩니다. 기본적으로 데이터베이스 제한 임계값의 호스트 메시지 수는 50,000 값으로 설정되며, 이 값은 다음과 같은 상황에서 제한 조건을 트리거합니다. - 호스트가 게시한 총 메시지 수가 구독 호스트의 작업, 상태 및 일시 중단된 큐에 instance 50,000을 초과합니다. - 스풀 테이블 또는 추적 테이블의 메시지 수가 500,000개 메시지를 초과합니다. 이 경우 데이터베이스의 메시지 수를 줄이는 작업 과정을 고려합니다. 예를 들어 BizTalk Server SQL Server 작업이 오류 없이 실행되고 있는지 확인하고 BizTalk Server 관리 콘솔의 그룹 허브 페이지를 사용하여 메시지 빌드가 많은 수의 일시 중단된 메시지로 인해 발생하는지 확인합니다. 자세한 내용은 이 항목의 BizTalk 높은 데이터베이스 크기 분석을 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 In-Process 메시지 수	이 분석은 높은 In-Process 메시지 수 카운터를 확인하여 이러한 종류의 제한이 발생하는지 여부를 확인합니다. 그렇다면 "CPU당 In-Process 메시지" 설정을 조정하는 것이 좋습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. CPU당 In-Process 메시지 수에 따라 제한을 사용하지 않도록 설정하려면 "CPU당 메시지 처리 중" 설정에 0 값을 입력합니다. "CPU당 In-Process 메시지" 설정의 기본값은 1,000입니다. 이 값을 수정하면 메시지 대기 시간이 짧거나 BizTalk 리소스의 효율성에도 영향을 미칠 수 있습니다. 자세한 내용은 이 항목의 BizTalk High In-Process 메시지 수 분석을 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 메시지 배달률	이 분석은 높은 메시지 배달률 카운터에서 값 1을 확인합니다. 높은 메시지 배달 속도는 높은 처리 복잡성, 느린 아웃바운드 어댑터 또는 시스템 리소스의 순간적인 부족으로 인해 발생할 수 있습니다. 자세한 내용은 이 항목의 BizTalk 높은 메시지 배달률 분석을 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 메시지 게시 속도	메시지 게시 조정이라고도 하는 BizTalk Server의 인바운드 호스트 조정은 MessageBox 데이터베이스에 메시지를 게시하는 수신 어댑터 또는 오케스트레이션을 포함하는 호스트 인스턴스에 적용됩니다. 이 분석은 높은 메시지 게시 속도 카운터에서 값 1을 확인합니다. 이 경우 데이터베이스는 BizTalk MessageBox 데이터베이스에 대한 메시지 게시 속도를 따라갈 수 없습니다. 참조: - 호스트 제한 성능 카운터 - BizTalk Server 호스트 제한을 구현하는 방법 - 속도 기반 제한 설정 수정 - 호스트 제한이란?
Microsoft BizTalk Server: BizTalk High Process Memory	BizTalk 프로세스 메모리 사용량 제한 임계값 설정은 1에서 100까지의 값을 입력한 경우 프로세스에 사용 가능한 총 가상 메모리 및 작업 집합 크기의 합계에 비해 사용된 메모리의 백분율입니다. 백분율 값을 지정하면 프로세스 메모리 임계값이 정기적으로 다시 계산됩니다. 이 분석은 High Process 메모리 카운터에서 값 1을 확인합니다. 자세한 내용은 이 항목의 BizTalk High Process Memory Analysis를 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 시스템 메모리	BizTalk 물리적 메모리 사용량 제한 임계값 설정은 1에서 100까지의 값을 입력하는 경우 사용 가능한 실제 메모리의 총 양에 비해 메모리 사용량의 백분율입니다. 이 설정은 100보다 큰 값을 입력하는 경우 사용 가능한 실제 메모리의 총 크기(MB)일 수도 있습니다. 실제 메모리 사용률 기반 조정을 해제하려면 값 0을 입력합니다. 기본값은 0입니다. 자세한 내용은 이 항목의 BizTalk High System Memory Analysis를 참조하세요.
Microsoft BizTalk Server: BizTalk 높은 스레드 수	"CPU당 스레드 수"는 어댑터에서 사용되는 스레드를 포함하여 호스트 프로세스의 총 스레드 수입니다. 이 임계값을 초과하는 경우 BizTalk Server EPM 스레드 풀 및 메시지 에이전트 스레드 풀의 크기를 줄이려고 시도합니다. 스레드 기반 조정은 과부하로 인해 많은 수의 스레드가 만들어질 수 있는 시나리오에서 설정해야 합니다. 이 매개 변수는 인바운드 조정과 아웃바운드 조정 모두에 영향을 미칩니다. 스레드 기반 제한은 기본적으로 사용하지 않도록 설정됩니다. 자세한 내용은 이 항목의 BizTalk 높은 스레드 수 분석을 참조하세요.
Microsoft BizTalk Server: BizTalk 호스트 큐 길이	BizTalk 호스트 큐 길이는 특정 호스트 큐의 총 메시지 수를 추적합니다. 길이 크기(예: BizTalk:MessageBox:HostCounters:Host Queue – Length)를 사용하여 개별 호스트의 큐 깊이를 표시하여 내부적으로 큐에 대기 중인 메시지 수를 보다 자세히 볼 수 있습니다. 이 카운터는 특정 호스트가 병목 상태인지 확인하는 데 유용할 수 있습니다. 각 전송에 고유한 호스트가 사용한다고 가정하면 잠재적인 전송 병목 상태를 확인하는 데 도움이 될 수 있습니다. 이 분석은 평균 큐 길이가 1보다 큰지 확인합니다. 호스트 큐 길이는 대상 호스트의 모든 큐(작업 Q, 상태 Q, 일시 중단된 Q)의 레코드 수를 집계하여 가중치가 지정된 큐 길이입니다. 참조: BizTalk Server 2010: BizTalk Server 성능 테스트 방법론
Microsoft BizTalk Server: BizTalk 호스트 일시 중단된 메시지 큐 길이	이 카운터는 특정 호스트에 대해 일시 중단된 메시지의 총 수를 추적합니다. 일시 중단된 메시지는 시스템 또는 메시지의 오류로 인해 BizTalk Server 처리를 중지한 메시지 또는 오케스트레이션의 instance. 일반적으로 시스템 오류로 인해 일시 중단된 인스턴스는 시스템 문제를 해결할 경우 다시 시작할 수 있습니다. 메시지 문제로 인해 일시 중단된 인스턴스는 다시 시작할 수 없는 경우가 많으며 메시지 자체를 수정하고 BizTalk Server 시스템에 다시 전송해야 합니다. 일시 중단된 메시지 큐는 처리 중에 오류 또는 오류가 발생한 작업 항목을 포함하는 큐입니다. 일시 중단된 큐는 메시지가 수정되어 다시 처리되거나 삭제될 때까지 메시지를 저장합니다. 이 분석은 일시 중단된 메시지의 발생을 확인합니다. 추세가 증가하면 심각한 처리 오류가 발생할 수 있습니다. 참조: - 상태 및 성능 모니터링 BizTalk Server - Microsoft BizTalk Server 문제 해결
BizTalk Server: BizTalk 유휴 오케스트레이션	호스트 인스턴스가 현재 호스팅하는 유휴 오케스트레이션 인스턴스 수입니다. 이 카운터는 진행되지 않지만 탈수할 수 없는 오케스트레이션을 나타냅니다. 이 상황은 오케스트레이션이 차단되어 원자성 트랜잭션에서 수신, 수신 또는 지연을 기다리는 경우에 발생할 수 있습니다. 탈수할 수 없는 오케스트레이션이 많은 경우 BizTalk는 메모리가 부족할 수 있습니다. 디하이드레이션은 오케스트레이션의 상태를 SQL Server 데이터베이스로 serialize하는 프로세스입니다. 리하일레이션은 데이터베이스에서 오케스트레이션의 마지막 실행 상태를 역직렬화하는 이 프로세스의 반대입니다. 디하이드레이션은 메모리에서 한 번에 인스턴스화되어야 하는 오케스트레이션 수를 줄여 시스템 리소스의 사용을 최소화하는 데 사용됩니다. 엔진은 상태를 저장하여 인스턴스를 디하이드레이션하고 이 인스턴스에 사용되던 메모리를 비웁니다. 엔진은 유휴 오케스트레이션 인스턴스를 디하이드레이션하여 여러 장기 실행 비즈니스 프로세스가 동일한 컴퓨터에서 동시에 실행될 수 있도록 만듭니다. 이 분석은 시간당 하나의 유휴 오케스트레이션의 증가 추세를 확인합니다. 참조: 오케스트레이션 탈수 및 리하이드레이션.
BizTalk Server: BizTalk 인바운드 대기 시간	메시징 엔진이 어댑터에서 문서를 받는 시점부터 MessageBox에 게시될 때까지의 평균 대기 시간(밀리초)입니다. 대기 시간을 줄이는 것은 BizTalk의 일부 사용자에게 중요하므로 인바운드 어댑터에서 문서가 소비하는 시간을 추적하는 것이 중요합니다. 자세한 내용은 이 항목의 BizTalk 인바운드 대기 시간 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 배달 지연	이는 각 메시지 배달 일괄 처리에 적용되는 밀리초(밀리초)의 현재 지연입니다(메시지 배달이 제한되는 경우 적용 가능). 제한과 관련하여 메시지가 인바운드인지 아웃바운드인지에 따라 메시지 게시 또는 처리에 지연이 적용됩니다. 지연 기간은 제한 조건의 심각도에 비례합니다. 심각도 제한 조건이 높을수록 더 낮은 심각도 제한 조건보다 더 긴 제한 기간이 시작됩니다. 이러한 지연 기간은 상태가 변경됨에 따라 조정 메커니즘에 의해 특정 범위 내에서 길이가 조정됩니다. 현재 지연 기간은 BizTalk:Message Agent 성능 개체 범주와 연결된 메시지 배달 지연(ms) 및 메시지 게시 지연(ms) 성능 카운터를 통해 노출됩니다. 이 분석은 5초보다 큰 메시지 배달 지연을 확인합니다. 긴 메시지 배달 지연은 높은 부하로 인한 과도한 제한을 나타낼 수 있습니다. 참조: BizTalk Server 호스트 제한을 구현하는 방법입니다.
BizTalk Server: BizTalk 메시지 배달 제한 상태	BizTalk 메시지 배달 제한 상태는 제한의 기본 지표 중 하나입니다. 시스템이 메시지 배달을 제한하고 있는지 여부를 나타내는 플래그입니다(XLANG 메시지 처리 및 아웃바운드 전송에 영향을 줍니다). 제한 조건은 카운터의 숫자 값으로 표시됩니다. 자세한 내용은 이 항목의 BizTalk 메시지 배달 제한 상태 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 게시 지연	메시지 게시를 제한하기 위해 각 적격 일괄 처리에 삽입된 지연입니다. 제한과 관련하여 메시지가 인바운드인지 아웃바운드인지에 따라 메시지 게시 또는 처리에 지연이 적용됩니다. 지연 기간은 제한 조건의 심각도에 비례합니다. 심각도 제한 조건이 높을수록 더 낮은 심각도 제한 조건보다 더 긴 제한 기간이 시작됩니다. 이러한 지연 기간은 상태가 변경됨에 따라 조정 메커니즘에 의해 특정 범위 내에서 길이가 조정됩니다. 현재 지연 기간은 BizTalk:Message Agent 성능 개체 범주와 연결된 메시지 배달 지연(ms) 및 메시지 게시 지연(ms) 성능 카운터를 통해 노출됩니다. 이 분석은 5초보다 큰 메시지 게시 지연을 확인합니다. 긴 메시지 배달 지연은 높은 부하로 인한 과도한 제한을 나타낼 수 있습니다. 참조: BizTalk Server 호스트 제한을 구현하는 방법입니다.
BizTalk Server: BizTalk MessageBox 데이터베이스 연결 실패	이 성능 카운터는 호스트 instance 시작된 이후 실패한 데이터베이스 연결 횟수입니다. 어떤 이유로든 BizTalk 데이터베이스를 호스팅하는 SQL Server 서비스를 사용할 수 없게 되면 데이터베이스 클러스터는 활성 컴퓨터에서 수동 컴퓨터로 리소스를 전송합니다. 이러한 장애 조치(Failover) 프로세스 중에는 BizTalk Server 서비스 인스턴스에서 데이터베이스에 연결할 수 없으므로 자동으로 다시 시작되어 데이터베이스에 다시 연결됩니다. 그러면 장애 조치 동안 리소스를 넘겨 받은 작동 데이터베이스(이전의 수동 컴퓨터) 컴퓨터에서 데이터베이스 연결 처리를 시작합니다. 자세한 내용은 이 항목의 BizTalk MessageBox 데이터베이스 연결 실패 분석을 참조하세요.
BizTalk Server: BizTalk 메시징 대기 시간: 요청 응답 대기 시간	메시징 엔진이 요청 문서를 수신한 다음 응답 문서를 어댑터로 보낼 때까지 걸리는 평균 대기 시간(밀리초)입니다. 이 항목의 BizTalk 인바운드 대기 시간 분석에서 대기 시간을 측정하는 방법을 보여 주는 차트를 참조하세요. 대기 시간이 짧은 환경을 가정하면 이 분석은 5초보다 큰 Request-Response 대기 시간을 확인합니다. 인바운드 어댑터와 아웃바운드 어댑터 간의 처리 지연을 나타낼 수 있습니다. 참조: - 요청/응답 메시징 - 솔루션 크기 조정
BizTalk Server: BizTalk 메시징 게시 제한 상태	BizTalk 메시지 게시 제한 상태는 제한의 기본 지표 중 하나입니다. 시스템이 메시지 게시를 제한하고 있는지 여부를 나타내는 플래그입니다(XLANG 메시지 처리 및 인바운드 전송에 영향을 미치는). 자세한 내용은 이 항목의 BizTalk 메시징 게시 제한 상태 분석을 참조하세요.
BizTalk Server: BizTalk 오케스트레이션 일시 중단/초	일시 중단된 메시지는 시스템 또는 메시지의 오류로 인해 BizTalk Server 처리를 중지한 메시지 또는 오케스트레이션의 instance. 일반적으로 시스템 오류로 인해 일시 중단된 인스턴스는 시스템 문제를 해결할 경우 다시 시작할 수 있습니다. 메시지 문제로 인해 일시 중단된 인스턴스는 다시 시작할 수 없는 경우가 많으며 메시지 자체를 수정하고 BizTalk Server 시스템에 다시 전송해야 합니다. 이 분석은 일시 중단된 메시지/오케스트레이션을 확인합니다. 참조: - 상태 및 성능 모니터링 BizTalk Server - Microsoft BizTalk Server 문제 해결
BizTalk Server: BizTalk 오케스트레이션 완료/초	초당 완료된 BizTalk 오케스트레이션의 수입니다. 이는 BizTalk가 처리하는 처리량에 대한 좋은 지표입니다. 이 분석은 통계만 제공합니다. 참조: 솔루션 크기 조정
BizTalk Server: BizTalk 오케스트레이션 삭제됨	호스트 인스턴스가 시작된 후 메모리에서 삭제된 오케스트레이션 인스턴스 수입니다. 엔진이 오케스트레이션의 상태를 지속하지 못하면 오케스트레이션을 삭제할 수 있습니다. 이 분석은 삭제된 메시지를 확인합니다. 참조: BizTalk Core Engine의 WebLog
BizTalk Server: 메모리에 상주하는 BizTalk 오케스트레이션	호스트 인스턴스에서 현재 호스팅 중인 오케스트레이션 인스턴스 수입니다. 이 분석은 메모리에 상주하는 오케스트레이션의 증가 추세와 메모리에 상주하는 오케스트레이션의 50% 이상이 탈수할 수 없는지 여부를 확인합니다. 자세한 내용은 메모리 분석의 BizTalk 오케스트레이션 상주를 참조하세요.
BizTalk Server: BizTalk 아웃바운드 어댑터 대기 시간	어댑터가 메시징 엔진에서 문서를 가져오는 시점부터 어댑터가 보낸 시간까지의 평균 대기 시간(초)입니다. 이 항목의 BizTalk 인바운드 대기 시간 분석에서 대기 시간을 측정하는 방법을 보여 주는 차트를 참조하세요. 대기 시간이 짧은 환경을 가정하면 이 분석은 평균 5초보다 큰 아웃바운드 어댑터의 대기 시간을 확인합니다. 이는 이 호스트 instance 아웃바운드 어댑터를 통해 메시지 전송이 지연되는 것을 나타낼 수 있습니다. 이 호스트 instance 여러 아웃바운드 어댑터가 있는 경우 해당 어댑터를 자체 호스트로 분리하여 대기 시간이 긴 아웃바운드 어댑터를 확인하는 것이 좋습니다. 참조: - 요청/응답 메시징. - BizTalk Server 2006: 2006년 BizTalk Server SOAP 어댑터를 사용한 확장성 사례 연구 - BizTalk 계층에서 병목 상태 식별 - BizTalk Server 대한 짧은 대기 시간 시나리오 최적화
BizTalk Server: BizTalk 보류 중인 메시지	MessageBox에 수신된 것으로 승인되지 않은 수신된 메시지 수입니다. 보류 중인 메시지는 메모리로 끌어와 XLANG 오케스트레이션에 전달되었지만 아직 처리되지 않은 메시지입니다. 이 상황은 데이터 손실과는 아무 상관이 없습니다. 오케스트레이션에 메시지를 전달하는 것은 다단계 프로세스이며 데이터베이스의 스풀 테이블에 있는 메시지의 instance. 이러한 보류 중인 메시지는 In-Process 메시지로 계산됩니다. 따라서 메모리에 많은 수의 메모리가 있으면 시스템에서 메모리 제한이 발생할 수 있습니다. 내부 메시지 큐 크기 설정을 조정하면 보류 중인 메시지 수를 제어하는 데 도움이 될 수 있습니다. CPU당 In-Process 메시지 설정은 많은 수의 보류 중인 메시지가 발생할 때 제한이 호출되는 시기에 영향을 줍니다. 이러한 설정은 BizTalk 관리 콘솔의 호스트 속성에 있습니다. 이 분석 검사는 이 카운터에 대한 통계만 표시합니다. 참조: 오케스트레이션 엔진 성능 카운터.
BizTalk Server: BizTalk 지속성 포인트/초	초당 지속된 오케스트레이션 인스턴스의 평균 수입니다. 오케스트레이션 엔진은 다양한 포인트에서 실행 중인 오케스트레이션 인스턴스의 상태를 저장합니다. 오케스트레이션 instance 리하드레이션하거나, 제어된 종료에서 시작하거나, 예기치 않은 종료로부터 복구해야 하는 경우 마지막 지속성 지점에서 오케스트레이션 instance 실행합니다. 오케스트레이션 instance 유지하려면 오케스트레이션이 직접 또는 간접적으로 참조하는 모든 개체 인스턴스를 직렬화할 수 있어야 합니다. 메시지 지속성 빈도(데이터를 유지해야 하는 횟수)가 증가함에 따라 전반적인 성능이 저하됩니다. 실제로 각 지속성 지점은 데이터베이스로의 왕복이므로 가능하면 지속성 지점을 피하거나 통합하여 지속성 지점의 빈도를 줄일 수 있습니다. 지속성 지점이 발생하는 시기에 대한 자세한 내용은 아래 참조를 참조하세요. 이 분석은 평균 초당 10개 이상의 지속성 지점을 확인합니다. 이것은 일반적인 시작점입니다. 참조: - 오케스트레이션의 지속성 - 지속성 및 오케스트레이션 엔진
BizTalk Server: BizTalk 프라이빗 바이트	호스트 instance 할당된 프라이빗 메모리의 메가바이트이며 "\Process(*)\Private Bytes" 성능 카운터와 비슷합니다. 이 분석은 호스트 인스턴스가 시스템 메모리의 큰 크기를 사용하는지 여부와 호스트 instance 시간이 지남에 따라 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 자세한 내용은 이 항목의 BizTalk 프라이빗 바이트 분석을 참조하세요.
BizTalk Server: BizTalk 스풀 테이블 크기	MessageBox 스풀 테이블에는 시스템의 각 메시지에 대한 레코드가 포함되어 있습니다(활성 또는 "가비지 수집"을 기다리는 중). 시스템 부하를 늘리면서 이 테이블의 행 수와 초당 받은 메시지 수를 모니터링하면 지속 가능한 최대 처리량을 쉽게 찾을 수 있습니다. 스풀 테이블이 무기한 증가하기 시작할 때까지 입력 부하를 늘리거나 2) 초당 수신된 메시지 수(어느 것이든 먼저 제공됨)가 지속 가능한 최대 처리량입니다. 요약하자면, 다른 지표에 관계없이 이 측정값은 시스템이 오버드라이브되고 있는지 여부를 빠르고 쉽게 평가할 수 있는 방법을 제공합니다. BizTalk 스풀 테이블 크기가 증가하는 추세인 경우 불균형 메시지 배달 속도(입력 속도가 출력 속도를 초과)로 인한 제한 또는 데이터베이스 크기로 인한 제한이 발생할 수 있습니다. 이 분석은 BizTalk 스풀 테이블 크기에서 증가하는 추세를 확인합니다. 참조: - BizTalk Server 2004 SP1 처리량 및 용량 이해 - 지속 가능한 부하 테스트 - 엔진 성능을 테스트할 때 권장 사항입니다.
BizTalk Server: BizTalk 추적 데이터 크기	BizTalk Server 시스템에서 점점 더 많은 데이터를 처리함에 따라 BizTalk Tracking 데이터베이스(BizTalkDTADb)의 크기는 계속 증가하고 있습니다. 증가를 제어하지 않으면 시스템 성능이 저하되며 TDDS(추적 데이터 배달 서비스)에서 오류가 생성될 수 있습니다. 일반적인 추적 데이터 외에 추적 메시지도 MessageBox 데이터베이스에 누적되어 디스크 성능이 느려질 수 있습니다. 이 분석은 추적 데이터 크기에서 시간당 5MB 이상의 증가 추세를 확인합니다. 참조: BizTalk 추적 데이터베이스 보관 및 제거
BizTalk Server: BizTalk 트랜잭션 범위 중단됨	호스트 instance 시작된 이후 중단된 장기 실행 또는 원자성 범위의 수입니다. 트랜잭션 scope 중단은 오케스트레이션 내의 트랜잭션 scope 발생하는 오류입니다. scope 보정 처리기는 scope 성공적으로 완료된 경우에만 호출되지만, 주변 scope 중단하기로 결정했기 때문에(프로세스의 뒷부분에서 발생할 수 있는 오류로 인해) 취소해야 한다는 것을 이해하는 것이 중요합니다. 또한 트랜잭션이 중단된 경우 상태의 "자동" 롤백이 발생하지 않습니다. 예외 및 보정 처리기를 통해 프로그래밍 방식으로 이 결과를 달성할 수 있습니다. 트랜잭션 scope 중단은 일반적으로 프로덕션 환경에서 발생하지 않아야 합니다. 따라서 이 분석은 중단된 트랜잭션 범위의 발생을 확인합니다. 참조: 트랜잭션
BizTalk Server: BizTalk 트랜잭션 범위 보정됨	보정은 일부 오류 조건에 대한 응답으로 성공적으로 커밋된 작업의 논리적 실행 취소로 간주될 수 있습니다. scope 보정 처리기는 scope 성공적으로 완료된 경우에만 호출되지만, 주변 scope 중단하기로 결정했기 때문에(프로세스의 뒷부분에서 발생할 수 있는 오류로 인해) 취소해야 한다는 것을 이해하는 것이 중요합니다. 또한 트랜잭션이 중단된 경우 상태의 "자동" 롤백이 발생하지 않습니다. 예외 및 보정 핸들러를 통해 프로그래밍 방식으로 이 작업을 수행할 수 있습니다. 트랜잭션 scope 보정은 일반적으로 프로덕션 환경에서 발생하지 않아야 합니다. 따라서 이 분석은 중단된 트랜잭션 범위의 발생을 확인합니다. 참조: 트랜잭션
BizTalk Server: BizTalk Virtual Bytes	호스트 instance 가상 메모리용으로 예약된 메가바이트입니다. 이 분석은 호스트 인스턴스가 많은 양의 시스템 메모리를 사용하는지 여부와 호스트 instance 시간이 지남에 따라 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 자세한 내용은 이 항목의 BizTalk 가상 바이트 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 데이터베이스 세션 제한	이는 각 BizTalk 제한 설정과 비교하여 MessageBox에 대한 열린 데이터베이스 연결 수입니다. "CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. 자세한 내용은 이 항목의 BizTalk Message Agent 데이터베이스 세션 제한 분석을 참조하세요.
BizTalk Server: BizTalk Message Agent 데이터베이스 세션 제한 임계값	이는 MessageBox에 대한 열린 데이터베이스 연결 수에 대한 현재 임계값입니다. "CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. 자세한 내용은 이 항목의 BizTalk Message Agent 데이터베이스 세션 제한 임계값 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 In-process 메시지 수 제한	서비스 클래스가 처리하는 동시 메시지의 수입니다. 호스트 제한 설정의 "CPU당 In-process 메시지" 설정은 처리되지 않은 EPM(엔드포인트 관리자) 또는 XLANG에 전달되는 최대 메시지 수입니다. 자세한 내용은 이 항목의 BizTalk 메시지 에이전트 In-process 메시지 수 제한 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 In-process 메시지 수 제한 임계값	서비스 클래스가 처리 중인 동시 메시지 수에 대한 현재 임계값입니다. 호스트 제한 설정의 "CPU당 In-process 메시지" 설정은 처리되지 않은 EPM(엔드포인트 관리자) 또는 XLANG에 전달되는 최대 메시지 수입니다. 자세한 내용은 이 항목의 BizTalk 메시지 에이전트 In-process 메시지 수 제한 임계값 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 프로세스 메모리 사용량(MB) 제한	현재 프로세스(MB)의 메모리 사용량입니다. 게시할 일괄 처리에 가파른 메모리 요구 사항이 있거나 너무 많은 스레드가 메시지를 처리하는 경우 BizTalk 프로세스 메모리 제한이 발생할 수 있습니다. 자세한 내용은 이 항목의 BizTalk 메시지 에이전트 프로세스 메모리 사용량(MB) 제한 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 프로세스 메모리 사용량(MB) 제한 임계값	현재 프로세스(MB)의 메모리 사용량에 대한 현재 임계값입니다. 임계값은 이 프로세스에 사용할 수 있는 실제 메모리 양과 해당 메모리 사용 패턴에 따라 동적으로 조정될 수 있습니다. 게시할 일괄 처리에 가파른 메모리 요구 사항이 있거나 너무 많은 스레드가 메시지를 처리하는 경우 BizTalk 프로세스 메모리 제한이 발생할 수 있습니다. 자세한 내용은 이 항목의 BizTalk 메시지 에이전트 프로세스 메모리 사용량(MB) 제한 임계값 분석을 참조하세요.
BizTalk Server: BizTalk 메시지 에이전트 스레드 수 제한	BizTalk 프로세스의 총 스레드 수입니다. "CPU당 스레드 수"는 어댑터에서 사용하는 스레드를 포함하여 호스트 프로세스의 총 스레드 수입니다. 이 임계값이 초과되면 BizTalk Server에서는 EPM 스레드 풀 및 메시지 에이전트 스레드 풀의 크기를 줄입니다. 스레드 기반 조정은 과부하로 인해 많은 수의 스레드가 만들어질 수 있는 시나리오에서 설정해야 합니다. 이 매개 변수는 인바운드 조정과 아웃바운드 조정 모두에 영향을 미칩니다. 스레드 기반 제한은 기본적으로 사용하지 않도록 설정됩니다. 이 분석은 BizTalk 스레드 수가 제한 조건을 나타내는 제한 임계값의 80% 이상인지 확인합니다. 참조: - 호스트 제한 성능 카운터 - BizTalk Server 호스트 제한을 구현하는 방법 - 기본 호스트 제한 설정을 수정하는 방법 - 어댑터 성능에 영향을 주는 구성 매개 변수 - 스레드, DB 세션 및 제한
BizTalk Server: BizTalk 메시지 에이전트 스레드 수 제한 임계값	프로세스의 총 스레드 수에 대한 현재 임계값입니다. "CPU당 스레드 수"는 어댑터에서 사용하는 스레드를 포함하여 호스트 프로세스의 총 스레드 수입니다. 이 임계값이 초과되면 BizTalk Server에서는 EPM 스레드 풀 및 메시지 에이전트 스레드 풀의 크기를 줄입니다. 높은 부하로 인해 많은 수의 스레드가 생성될 수 있는 시나리오에서 스레드 기반 제한을 사용하도록 설정해야 합니다. 이 매개 변수는 인바운드 조정과 아웃바운드 조정 모두에 영향을 미칩니다. 이 분석은 이 제한 설정이 기본값이 아닌 값으로 설정되어 있는지 확인합니다. 스레드 기반 제한은 기본적으로 사용하지 않도록 설정됩니다. 참조: - 호스트 제한 성능 카운터 - BizTalk Server 호스트 제한을 구현하는 방법 - 기본 호스트 제한 설정을 수정하는 방법 - 어댑터 성능에 영향을 주는 구성 매개 변수 - 스레드, DB 세션 및 제한

논리/실제 디스크 읽기/쓰기 대기 시간 분석

Windows에서 디스크 성능 병목 상태를 감지하는 가장 신뢰할 수 있는 방법은 응답 시간을 측정하는 것입니다. 응답 시간이 보수적 임계값인 .025(25밀리초)보다 큰 경우 사용자에게 영향을 주는 눈에 띄는 속도 저하 및 성능 문제가 발생할 수 있습니다.

디스크 대기 시간 저하의 일반적인 원인은 디스크 조각화, 성능 캐시, 과도 SAN 및 디스크에 너무 많은 부하입니다. SPA 도구를 사용하여 디스크를 사용하여 상위 파일 및 프로세스를 식별할 수 있습니다. 또한 "Process IO Data Operations/sec" 및 "Process IO Other Operations/sec"를 검사 가장 많은 디스크 I/O를 사용하는 프로세스를 확인합니다. 성능 모니터 카운터는 관련된 파일을 지정할 수 없습니다.

참조

논리 디스크 전송/초

"Disk Transfers/sec"는 디스크의 읽기 및 쓰기 작업 속도입니다. 디스크 전송은 디스크 I/O와 직접적인 상관 관계가 아니지만, 발생 중인 디스크 작업 수를 알려 줍니다. 순차적 I/O 및 임의 I/O를 평균하는 경우 일반적인 엄지 손가락 규칙으로 초당 약 80 I/O로 끝납니다. 따라서 부하가 있을 때 SAN 드라이브가 초당 80개 이상의 I/O를 수행할 것으로 예상해야 합니다. 이 분석에 대한 임계값은 논리 디스크 중 하나라도 응답 시간이 좋지 않은지(I/O 작업에 대한 응답 시간 25ms 초과)를 표시하는지 확인하는 검사. 이 경우 초당 디스크 전송이 80 이상일 것으로 예상해야 합니다. 그렇지 않은 경우 디스크 아키텍처를 조사해야 합니다. 디스크 I/O 불량의 가장 일반적인 원인은 SAN에서 LUN(논리 단위 번호) 오버로드입니다. 즉, 둘 이상의 LUN이 작은 실제 디스크 배열을 사용하는 조건을 의미합니다.

사용 가능한 메모리 분석

"사용 가능한 Mbytes"는 컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리의 양(메가바이트)입니다. Virtual Memory Manager는 운영 체제 및 프로세스에 사용 가능한 최소 바이트 수를 유지하기 위해 실제 메모리 및 디스크에 사용되는 공간을 지속적으로 조정합니다. 사용 가능한 바이트가 많은 경우 Virtual Memory Manager를 사용하면 작업 프로세스 집합이 증가하거나 추가된 각 새 페이지에 대한 이전 페이지를 제거하여 프로세스를 안정적으로 유지할 수 있습니다. 사용 가능한 바이트가 거의 없는 경우 가상 메모리 관리자는 필요한 최소값을 유지하기 위해 작업 프로세스 집합을 트리밍해야 합니다.

이 분석은 사용 가능한 총 메모리가 낮은지 확인합니다. 사용 가능한 10%의 경고 및 사용 가능한 5%의 위험 경고를 확인합니다. 시간당 10MB의 감소 추세가 감지되면 예정된 메모리 상태가 발생할 수 있음을 나타내는 경고도 표시됩니다. 실제 메모리가 부족하면 권한 있는 모드 CPU 및 시스템 지연이 증가할 수 있습니다.

참조

Memory-Bound 문제 배제

메모리 누수 감지 분석

이 분석은 프로세스 중 어느 프로세스가 시스템의 메모리를 많이 사용하는지 여부와 시간이 지남에 따라 프로세스가 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 프로세스에서 메모리를 다시 시스템으로 반환하는 한 많은 양의 메모리를 사용하는 프로세스는 괜찮습니다. 차트에서 증가하는 추세를 찾습니다. 오랜 기간 동안 증가하는 추세는 메모리 누수일 수 있습니다. 프라이빗 바이트는 이 프로세스가 다른 프로세스와 공유할 수 없는 할당된 메모리의 현재 크기(바이트)입니다. 이 분석은 시간당 10MB 및 시간당 5MB 증가 추세를 확인합니다. 사용 가능한 메모리 분석과 상관 관계에 이 분석을 사용합니다.

또한 새로 시작된 프로세스는 단순히 정상적인 시작 동작일 때 처음에 메모리 누수로 표시됩니다. 메모리 누수는 프로세스가 메모리를 계속 사용하고 오랜 기간 동안 메모리를 해제하지 않을 때 발생합니다.

메모리 누수 상태가 의심되는 경우 디버그 Diag 도구를 설치하고 사용합니다. 디버그 Diag 도구에 대한 자세한 내용은 참조 섹션을 참조하세요.

참조

진단 도구 디버그

메모리 페이지/초 분석

이 분석은 "Pages/sec"가 높은지 확인합니다. 높은 경우 시스템에서 메모리를 디스크에 페이징하려고 시도하여 메모리가 부족할 수 있습니다. "Pages/sec"는 하드 페이지 오류를 resolve 위해 디스크에서 페이지를 읽거나 디스크에 쓰는 속도입니다. 이 카운터는 시스템 전반적으로 지연을 발생시키는 오류 종류의 주요 표시기입니다. "Memory\Pages Input/sec" 및 "Memory\Pages Output/sec"의 합계입니다. 페이지 수로 계산되므로 "Memory\Page Faults/sec"와 같은 다른 페이지 수와 비교할 수 있습니다.

이 카운터는 항상 1,000 미만이어야 합니다. 이 분석은 1,000을 초과하는 값을 확인합니다. 사용 가능한 메모리 분석 및 메모리 누수 검색 분석과 상관 관계에 이 분석을 사용합니다. 모든 분석이 동시에 경고를 throw하는 경우 시스템에 메모리가 부족함을 나타낼 수 있습니다. 이 항목의 메모리 누수 감지 분석과 관련된 추가 정보에 언급된 분석 단계를 따릅니다.

참조

Memory-Bound 문제 배제

메모리 시스템 캐시 상주 바이트 분석

"시스템 캐시 상주 바이트"는 파일 시스템 캐시에 있는 페이징 가능한 운영 체제 코드의 크기(바이트)입니다. 이 값은 현재 실제 페이지만 포함하며 현재 상주하지 않는 가상 메모리 페이지는 포함하지 않습니다. 작업 관리자에 표시된 시스템 캐시 값과 같습니다. 결과적으로 이 값은 파일 시스템 캐시에서 사용 중인 실제 가상 메모리 양보다 작을 수 있습니다. 이 값은 현재 실제 메모리에 있는 모든 페이징 가능한 운영 체제 코드를 나타내는 "Memory\\System Code Resident Bytes"의 구성 요소입니다. 이 카운터는 마지막으로 관찰된 값만 표시하며, 평균이 아닙니다.

이 분석은 시간당 10MB의 증가 추세를 확인합니다. 로드 중인 서버는 디스크와 같은 I/O 작업을 캐시하기 위해 시스템 캐시를 사용할 수 있습니다. 프로세스 IO 데이터 작업/초 및 프로세스 IO 기타 작업/초 분석과 상관 관계에 사용합니다.

프로세서 사용률 분석 및 프로세스별 과도한 프로세서 사용

"% 프로세서 시간"은 프로세서가 유휴 상태가 아닌 스레드를 실행하는 데 소비하는 경과된 시간의 백분율입니다. 유휴 스레드가 샘플 간격에서 활성화된 기간을 측정한 다음 간격 기간에서 해당 시간을 빼서 계산됩니다. (각 프로세서에는 다른 스레드를 실행할 준비가 되지 않은 경우 주기를 사용하는 유휴 스레드가 있습니다.) 이 카운터는 프로세서 작업의 기본 표시기이며 샘플 간격 동안 관찰된 사용 시간의 평균 백분율을 표시합니다. 서비스가 비활성 상태인 시간을 모니터링하고 해당 값을 100%에서 빼서 계산합니다.

이 분석은 각 개별 프로세서에서 60% 이상의 사용률을 확인합니다. 그렇다면 높은 사용자 모드 CPU인지 높은 권한 모드인지 확인합니다. 높은 권한 모드 CPU가 의심되는 경우 "권한 있는 모드 CPU 분석"을 참조하세요. 사용자 모드 프로세서 병목 현상이 의심되는 경우 프로세스 프로파일러를 사용하여 높은 CPU 사용량을 유발하는 함수를 분석하는 것이 좋습니다. 자세한 내용은 참조 섹션의 "방법: 프로덕션 환경에서 서버 애플리케이션에 대한 높은 사용자 모드 CPU 병목 현상을 일으키는 함수 식별" 문서를 참조하세요.

프로세서 큐 길이 분석

"프로세서 큐 길이"는 프로세서 큐의 스레드 수입니다. 디스크 카운터와는 달리 이 카운터는 실행되고 있는 스레드는 제외하며 준비된 스레드만 표시합니다. 다중 프로세서가 있는 컴퓨터일지라도 프로세서 시간에 대해 단일 대기열이 있습니다. 그러므로 컴퓨터에 여러 개의 프로세서가 있는 경우에는 이 값을 작업 부하를 처리하는 프로세서 수로 나누어야 합니다. 작업 부하에 따라 보통 프로세서당 프로세서 대기열에 스레드가 10개 미만으로 유지되는 것이 좋습니다.

이 분석은 평균 프로세서 큐 길이가 프로세서 수를 초과하는지 여부를 결정합니다. 그렇다면 프로세서 병목 상태를 나타낼 수 있습니다. 권한 있는 모드 CPU 분석 및 프로세스별 과도한 프로세서 사용과 상관 관계로 이 분석을 사용합니다. 프로세서 큐는 다른 활성 스레드가 현재 실행 중이므로 준비되었지만 프로세서에서 실행할 수 없는 스레드의 컬렉션입니다. 프로세서 수보다 많은 스레드가 지속되거나 반복되는 큐는 프로세서 병목 상태를 나타내는 좋은 지표입니다.

이 카운터를 "Processor\% Processor Time" 카운터와 함께 사용하여 애플리케이션이 더 많은 CPU의 이점을 얻을 수 있는지 여부를 확인할 수 있습니다. 다중 프로세서 컴퓨터에서도 프로세서 시간에 대한 단일 큐가 있습니다. 따라서 다중 프로세서 컴퓨터에서 "프로세서 큐 길이"(PQL) 값을 워크로드를 서비스하는 프로세서 수로 나눕니다.

CPU가 매우 사용량이 많고(사용률이 90% 이상) PQL 평균이 프로세서 수보다 지속적으로 높은 경우 추가 CPU의 이점을 얻을 수 있는 프로세서 병목 현상이 발생할 수 있습니다. 또는 애플리케이션 수준에서 스레드 및 큐 수를 줄일 수 있습니다. 이로 인해 컨텍스트 전환이 줄어들어 CPU 부하를 줄이는 데 적합합니다. CPU 사용률이 낮은 높은 PQL의 일반적인 이유는 프로세서 시간에 대한 요청이 임의로 도착하고 스레드가 프로세서에서 불규칙한 시간을 요구하기 때문입니다. 즉, 프로세서가 병목 상태가 아닙니다. 대신, 개선해야 하는 스레딩 논리입니다.

사용자 모드 프로세서 병목 현상이 의심되는 경우 프로세스 프로파일러를 사용하여 높은 CPU 사용량을 유발하는 함수를 분석하는 것이 좋습니다. 자세한 내용은 참조 섹션의 "방법: 프로덕션 환경에서 서버 애플리케이션에 대한 높은 사용자 모드 CPU 병목 현상을 일으키는 함수 식별" 문서를 참조하세요.

권한 있는 모드 CPU 분석

이 카운터는 스레드가 권한 있는 모드에서 실행되는 시간의 백분율을 나타냅니다. 애플리케이션이 운영 체제 함수를 호출하는 경우(예: 파일 또는 네트워크 I/O를 수행하거나 메모리를 할당하기 위해) 이러한 운영 체제 함수는 권한 있는 모드로 실행됩니다.

높은 권한 모드 CPU는 컴퓨터가 시스템 I/O와 실제(사용자 모드) 작업에 너무 많은 시간을 소비하고 있음을 나타냅니다. "% Privileged Time"은 프로세스 스레드가 권한 있는 모드에서 코드를 실행하는 데 소요된 경과된 시간의 백분율입니다. Windows 시스템 서비스가 호출될 때 서비스는 종종 권한 있는 모드로 실행되어 시스템-프라이빗 데이터에 액세스할 수 있습니다. 이러한 데이터는 사용자 모드에서 실행되는 스레드에 의해 액세스로부터 보호됩니다. 시스템에 대한 호출은 페이지 오류 또는 인터럽트와 같이 명시적이거나 암시적일 수 있습니다. 일부 초기 운영 체제와 달리 Windows는 기존의 사용자 및 권한 있는 모드 보호 외에도 하위 시스템 보호에 프로세스 경계를 사용합니다. 애플리케이션을 대신하여 Windows에서 수행한 일부 작업은 프로세스의 권한 있는 시간 외에 다른 하위 시스템 프로세스에 나타날 수 있습니다.

이 분석은 권한 있는 모드 CPU가 총 CPU의 30% 이상을 사용하는지 확인합니다. 그렇다면 CPU 사용량은 네트워크, 메모리 또는 디스크 I/O와 같은 프로세서 이외의 다른 병목 현상으로 인해 발생할 수 있습니다. % 인터럽트 시간 및 높은 컨텍스트 전환 분석과 상관 관계에 사용합니다.

높은 컨텍스트 전환 분석

컨텍스트 전환은 우선 순위가 높은 스레드가 현재 실행 중인 우선 순위가 낮은 스레드를 선점하거나 우선 순위가 높은 스레드가 차단되는 경우에 발생합니다. 많은 스레드가 동일한 우선 순위 수준을 공유하는 경우 높은 수준의 컨텍스트 전환이 발생할 수 있습니다. 이는 시스템의 프로세서에 대해 너무 많은 스레드가 경쟁하고 있음을 나타내는 경우가 많습니다. 프로세서 사용률이 많지 않고 컨텍스트 전환 수준이 매우 낮으면 스레드가 차단되었음을 나타낼 수 있습니다.

높은 컨텍스트 전환은 권한 있는 모드 CPU 및 전체 CPU가 높은 경우에만 조사해야 합니다. 일반적으로 프로세서당 초당 5,000개 미만의 컨텍스트 전환 속도는 걱정할 필요가 없습니다. 컨텍스트 전환 속도가 프로세서당 초당 15,000을 초과하는 경우 제약 조건이 있습니다.

이 분석은 높은 CPU, 높은 권한 모드 CPU 및 높은(프로세서당 5,000개 초과) 시스템 컨텍스트 스위치를 동시에 발생시키는지 확인합니다. 높은 컨텍스트 전환이 발생하는 경우 시스템에서 실행되는 스레드 및 프로세스의 수를 줄입니다.

BizTalk High Database 세션 분석

이 카운터에는 정상(0) 또는 초과(1)라는 두 개의 가능한 값이 있습니다. 이 분석은 값 1을 확인합니다. 이 경우 BizTalk가 허용되는 데이터베이스 세션 수의 임계값을 초과했습니다. 이 값은 BizTalk 호스트 제한 설정의 "CPU당 데이터베이스 연결" 값으로 제어됩니다.

"CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. 일반적인 호스트별 세션 풀의 유휴 데이터베이스 세션은 이 값에 추가되지 않으며 호스트 인스턴스에서 실제로 사용하는 세션 수에 대해서만 확인 작업이 수행됩니다. 이 옵션은 기본적으로 사용하지 않도록 설정됩니다. 일반적으로 이 설정은 데이터베이스 서버가 병목 상태이거나 BizTalk Server 시스템의 하위 엔드 데이터베이스 서버에 대해서만 사용하도록 설정해야 합니다. BizTalk:Message Agent 성능 개체 범주에서 데이터베이스 세션 성능 카운터를 사용하여 활성 데이터베이스 연결 수를 모니터링할 수 있습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. 데이터베이스 세션 수에 기반한 조정을 해제하려면 값 0을 입력합니다. 기본값은 0입니다.

참고

"MaxWorkerThreads" 레지스트리 키는 BizTalk에서 사용할 수 있는 스레드 수에 영향을 미치며 대부분의 BizTalk 스레드가 데이터베이스 연결 사용 중인 경우 도움이 될 수 있습니다.

참조

BizTalk 높은 데이터베이스 크기 분석

이 카운터는 이 프로세스가 게시한 데이터베이스 큐의 메시지 수를 나타냅니다. 이 값은 모든 호스트에 대한 큐 테이블의 항목 수와 스풀 및 추적 테이블의 항목 수로 측정됩니다. 큐에는 작업 큐, 상태 큐 및 일시 중단된 큐가 포함됩니다. 프로세스에서 여러 큐에 게시할 경우 이 카운터는 모든 큐의 가중 평균을 반영합니다.

호스트를 다시 시작하면 메모리에 보관되었던 통계가 손실됩니다. 일부 오버헤드가 관련되므로 BizTalk Server 다시 시작된 호스트 프로세스 내에서 총 게시의 5%를 사용하여 100개 이상의 게시가 있는 경우에만 통계 수집을 다시 시작합니다.

데이터베이스 임계값의 메시지 수에 대해 나열된 조건 중 하나가 발생하는 경우 이 카운터는 값 1로 설정됩니다. 이 임계값은 아래에서 참조하는 기본 호스트 제한 설정을 수정하는 방법 항목에 설명되어 있습니다. 기본적으로 데이터베이스 제한 임계값의 호스트 메시지 수는 50,000 값으로 설정되며, 이 값은 다음과 같은 상황에서 제한 조건을 트리거합니다.

호스트 인스턴스에서 등록 호스트의 작업, 상태 및 일시 중단된 큐에 게시한 총 메시지 수가 50,000개를 초과하는 경우
스풀 테이블 또는 추적 테이블의 메시지 수가 500,000개를 초과하는 경우

일시 중단된 메시지는 데이터베이스 계산의 메시지 수에 포함되므로 BizTalk 서버에서 부하가 적거나 없는 경우에도 메시지 게시 제한이 발생할 수 있습니다.

이 분석은 값 1을 확인합니다. 이 경우 데이터베이스의 메시지 수를 줄이는 작업 과정을 고려합니다. 예를 들어 BizTalk SQL Server 작업이 오류 없이 실행되고 있는지 확인하고 BizTalk 관리 콘솔의 그룹 허브를 사용하여 메시지가 대량의 일시 중단된 메시지로 인해 발생하는지 확인합니다.

참조

BizTalk High In-Process 메시지 수 분석

호스트 제한 설정의 "CPU당 In-process 메시지" 설정은 처리되지 않은 EPM(엔드포인트 관리자) 또는 XLANG에 전달되는 최대 메시지 수입니다. 이 번호에는 데이터베이스에서 검색된 메시지가 포함되지 않지만 여전히 메모리 내 큐에서 배달을 기다리고 있습니다. BizTalk:Message Agent 성능 개체 범주 아래의 In-process 메시지 수 성능 카운터를 사용하여 In-Process 메시지 수를 모니터링할 수 있습니다. 이 매개 변수는 제한 조건을 고려할 때 제한 메커니즘에 대한 힌트를 제공합니다. 실제 임계값은 자체 튜닝이 가능합니다. In-process 메시지 수 성능 카운터를 모니터링하여 실제 임계값을 확인할 수 있습니다.

이 매개 변수는 평균 메시지 크기가 높거나 메시지 처리에 많은 수의 메시지가 필요할 수 있는 큰 메시지 시나리오의 경우 더 작은 값으로 설정할 수 있습니다. 이는 시나리오에서 메모리 기반 제한을 너무 자주 경험하고 메모리 임계값이 상당히 낮은 값으로 자동 조정되는 경우에 분명합니다. 이러한 동작은 과도한 메모리 사용을 방지하기 위해 아웃바운드 전송 시 보다 적은 수의 메시지를 동시에 처리해야 함을 나타냅니다. 또한 동시 연결을 제한하는 서버로 메시지를 보내는 경우처럼 어댑터가 한 번에 적은 수의 메시지를 처리할 때 보다 효율적인 시나리오의 경우 이 매개 변수를 기본값보다 작은 값으로 조정할 수 있습니다.

이 분석은 높은 In-Process 메시지 수 카운터를 확인하여 이러한 종류의 제한이 발생하는지 여부를 확인합니다. 그렇다면 "CPU당 In-Process 메시지" 설정을 조정하는 것이 좋습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. CPU당 In-Process 메시지 수에 따라 제한을 사용하지 않도록 설정하려면 "CPU당 In-Process 메시지" 설정에 0 값을 입력합니다. "CPU당 In-Process 메시지" 설정의 기본값은 1,000입니다. 이 값을 수정하면 메시지 대기 시간이 짧거나 BizTalk 리소스의 효율성에도 영향을 미칠 수 있습니다.

참조

BizTalk 높은 메시지 배달 속도 분석

아웃바운드(배달) 메시지의 경우 BizTalk Server 호스트 instance 대한 메시지 배달 수신 속도가 메시지 배달 발신 속도 * 지정된 속도 오버드라이브 비율(백분율) 값을 초과하는 경우 메시지 배달을 제한합니다. 속도 오버드라이브 비율(백분율) 매개 변수는 메시지 처리 제한 설정 대화 상자에서 구성할 수 있습니다. 아웃바운드 메시지에 대한 속도 기반 제한은 주로 메모리 내 큐에서 메시지를 제거하기 전에 지연을 유도하고 처리를 위해 EPM(엔드포인트 관리자) 또는 오케스트레이션 엔진에 메시지를 전달하여 수행됩니다. 아웃바운드 메시지에 대한 속도 기반 제한을 수행하기 위한 다른 작업은 수행되지 않습니다.

아웃바운드 조정으로 인해 메시지 배달이 지연될 수 있으며 메시지가 메모리 내 큐에 쌓여 조정 상태가 완화될 때까지 큐에서 나오는 스레드가 차단될 수 있습니다. 큐 제거 스레드가 차단되면 아웃바운드 배달을 위해 MessageBox에서 메모리 내 큐로 추가 메시지를 끌어오지 않습니다.

이 분석은 높은 메시지 배달률 카운터에서 값 1을 확인합니다. 높은 메시지 배달 속도는 높은 처리 복잡성, 느린 아웃바운드 어댑터 또는 시스템 리소스의 순간적인 부족으로 인해 발생할 수 있습니다.

참조

BizTalk High Process 메모리 분석

BizTalk 프로세스 메모리 사용량 제한 임계값 설정은 1에서 100까지의 값을 입력한 경우 프로세스에 사용할 수 있는 총 가상 메모리 및 작업 집합 크기의 합계에 비해 사용된 메모리의 백분율입니다. 기본적으로 BizTalk 프로세스 메모리 사용량 제한 설정은 25입니다. 백분율 값을 지정하면 프로세스 메모리 임계값이 정기적으로 다시 계산됩니다. 사용자가 백분율 값을 지정하는 경우 커밋할 사용 가능한 메모리 및 현재 프로세스 메모리 사용량을 기준으로 계산됩니다.

이 분석은 High Process 메모리 카운터에서 값 1을 확인합니다. 이 경우 디버그 Diag를 사용하여 메모리 증가의 원인을 확인합니다(메모리 누수 검색 분석 참조). 프로세스는 시작 중에 메모리의 상당 부분을 소비하는 것이 정상이며 처음에는 메모리 누수로 나타날 수 있지만 프로세스가 더 이상 필요하지 않은 메모리를 해제하지 못하면 실제 메모리 누수가 발생하여 시간이 지남에 따라 사용 가능한 메모리 양이 줄어듭니다. BizTalk에서 프로세스 메모리 누수를 일반적으로 분석하는 방법에 대한 자세한 내용은 아래의 "메모리 누수 프로세스의 메모리 덤프를 캡처하는 방법" 참조 및/또는 PAL의 "메모리 누수 검색" 분석을 참조하세요.

게시할 일괄 처리에 가파른 메모리 요구 사항이 있거나 너무 많은 스레드가 메시지를 처리하는 경우 높은 프로세스 메모리 제한이 발생할 수 있습니다. 시스템이 과도하게 제한되는 것처럼 보이는 경우 호스트의 프로세스 메모리 사용 임계값과 관련된 값을 늘리고 호스트 instance "메모리 부족" 오류를 생성하지 않는지 확인합니다. 프로세스 메모리 사용량 임계값을 늘려 "메모리 부족" 오류가 발생하는 경우 CPU 임계값당 내부 메시지 큐 크기 및 In-Process 메시지의 값을 줄이는 것이 좋습니다. 이 전략은 대량 메시지 처리 시나리오에 특히 유용합니다. 또한 메시지당 메모리 요구 사항이 큰 시나리오의 경우 이 값을 낮은 값으로 설정해야 합니다. 낮은 값을 설정하면 초기에 제한이 시작되고 프로세스 내에서 메모리 폭발을 방지합니다.

BizTalk 서버에 정기적으로 가상 메모리가 부족하면 64비트 BizTalk Server 것이 좋습니다. 64비트 서버의 각 프로세스는 최대 4TB의 가상 메모리와 32비트의 2GB를 처리할 수 있습니다. 일반적으로 64비트 BizTalk 및 64비트 SQL Server 권장됩니다. 자세한 내용은 "BizTalk Server 64비트 지원" 참조를 참조하세요.

참조

BizTalk 높은 시스템 메모리 분석

BizTalk 물리적 메모리 사용량 제한 임계값 설정은 1에서 100까지의 값을 입력하는 경우 사용 가능한 실제 메모리의 총 양에 비해 메모리 사용량의 백분율입니다. 이 설정은 100보다 큰 값을 입력하는 경우 사용 가능한 실제 메모리의 총 크기(MB)일 수도 있습니다. 실제 메모리 사용률 기반 조정을 해제하려면 값 0을 입력합니다. 기본값은 0입니다.

이 분석은 높은 시스템 메모리 카운터에서 값 1을 확인합니다. 이 임계값을 설정하면 전체 시스템 메모리가 측정되므로 비 BizTalk Server 프로세스에서 너무 많은 시스템 메모리를 소비하는 경우 조정 상태가 트리거될 수 있습니다. 따라서 이 경우 가장 좋은 방법은 물리적 메모리를 가장 많이 사용하는 프로세스를 식별하거나 서버에 물리적 메모리를 추가하는 것입니다. 또한 EPM 스레드 풀의 기본 크기 및/또는 어댑터 일괄 처리 크기를 줄여 부하를 줄이는 것이 좋습니다. 자세한 내용은 PAL의 메모리 누수 감지 분석을 참조하세요.

참조

BizTalk 높은 스레드 수 분석

"CPU당 스레드 수"는 어댑터에서 사용되는 스레드를 포함하여 호스트 프로세스의 총 스레드 수입니다. 이 임계값을 초과하는 경우 BizTalk Server EPM 스레드 풀 및 메시지 에이전트 스레드 풀의 크기를 줄이려고 시도합니다. 스레드 기반 조정은 과부하로 인해 많은 수의 스레드가 만들어질 수 있는 시나리오에서 설정해야 합니다. 이 매개 변수는 인바운드 조정과 아웃바운드 조정 모두에 영향을 미칩니다. 스레드 기반 제한은 기본적으로 사용하지 않도록 설정됩니다.

참고

사용자 지정 값은 지침으로 사용되며 호스트는 프로세스의 메모리 사용 패턴 및 스레드 요구 사항에 따라 이 임계값을 동적으로 자체 조정할 수 있습니다.

이 분석은 높은 스레드 수 카운터에서 값 1을 확인합니다. 시스템에서 너무 많은 스레드를 만들지 않도록 다른 스레드 풀 크기를 조정합니다. 이 분석은 초당 컨텍스트 스위치 분석과 상관 관계를 지정하여 운영 체제가 너무 많은 스레드로 포화 상태인지 여부를 확인할 수 있지만 대부분의 경우 스레드 수가 많으면 BizTalk 서버보다 백 엔드 데이터베이스에서 더 많은 경합이 발생합니다. 스레드 풀 크기를 수정하는 방법에 대한 자세한 내용은 참조에서 기본 호스트 제한 설정을 수정하는 방법을 참조하세요.

참조

호스트 제한 성능 카운터
BizTalk Server의 호스트 제한 구현 방법
기본 호스트 조정 설정을 수정하는 방법
어댑터 성능에 영향을 주는 구성 매개 변수
스레드, DB 세션 및 제한

BizTalk 인바운드 대기 시간 분석 메시징 엔진이 어댑터에서 문서를 받는 시점부터 메시지 상자에 게시될 때까지의 대기 시간(밀리초)입니다. 대기 시간을 줄이는 것은 BizTalk의 일부 사용자에게 중요하므로 인바운드 어댑터에서 문서가 소비하는 시간을 추적하는 것이 중요합니다.

대기 시간을 측정하는 방법을 보여 주는 차트는 다음과 같습니다.

1	2	3	4	5	6
어댑터는 메시지를 수신하고 엔진에 제출하고, 이러한 성능 카운터에서 캡처되지 않은 엔진에 메시지가 전달되기 전에 어댑터에서 수행된 작업	엔진은 어댑터에서 메시지를 수신하고, 수신 파이프라인, 맵, 구독 평가를 실행하고, DB에서 메시지를 유지합니다.	오케스트레이션 또는 Solicit-Response 포트가 실행되고 응답 메시지를 생성합니다.	응답 메시지는 메시징 엔진에서 큐에서 해제되고, 송신 파이프라인을 실행하고, 맵을 실행합니다.	메시징 엔진은 어댑터에 응답 메시지를 제공합니다.	어댑터는 엔진 메시지가 모두 완료된 것을 알 수 있습니다.
	I
	RR	RR	RR
			O	O	O
				OA	OA

I = 인바운드 대기 시간

RR = 요청 응답 대기 시간

O = 아웃바운드 대기 시간

OA = 아웃바운드 어댑터 대기 시간

대기 시간이 짧은 환경을 가정하면 이 분석은 문서가 인바운드 어댑터에서 5초 이상 소요되었는지 여부를 확인합니다. 이는 이 호스트 instance 인바운드 어댑터를 통해 메시지 전송이 지연되는 것을 나타낼 수 있습니다. 이 호스트 instance 인바운드 어댑터가 여러 개 있는 경우 해당 어댑터를 자체 호스트로 분리하여 대기 시간이 긴 인바운드 어댑터를 확인하는 것이 좋습니다.

참조

BizTalk 메시지 배달 제한 상태 분석

BizTalk 메시지 배달 제한 상태는 제한의 기본 지표 중 하나입니다. 시스템이 메시지 배달을 제한하고 있는지 여부를 나타내는 플래그입니다(XLANG 메시지 처리 및 아웃바운드 전송에 영향을 줍니다). 제한 조건은 카운터의 숫자 값으로 표시됩니다. 값과 해당 의미의 목록은 다음과 같습니다.

제한 조건	설명
0	조정 안 함
1	불균형 메시지 배달 속도(입력 속도가 출력 속도를 초과함)로 인해 조정합니다.
3	처리 중인 많은 메시지로 인해 조정합니다.
4	프로세스 메모리 부족으로 인해 조정합니다.
5	시스템 메모리 부족으로 인해 조정합니다.
9	많은 수의 스레드로 인해 조정합니다.
10	배달할 때 사용자 재정의로 인해 조정합니다.

이 분석은 이러한 각 값을 확인하고 각 값에 대한 특정 경고를 줍니다.

참조

BizTalk MessageBox 데이터베이스 연결 실패 분석

이 성능 카운터는 호스트 instance 시작된 이후 실패한 데이터베이스 연결 횟수입니다. 어떤 이유로든 BizTalk 데이터베이스를 호스팅하는 SQL Server 서비스를 사용할 수 없게 되면 데이터베이스 클러스터는 활성 컴퓨터에서 수동 컴퓨터로 리소스를 전송합니다. 이러한 장애 조치(Failover) 프로세스 중에는 BizTalk Server 서비스 인스턴스에서 데이터베이스에 연결할 수 없으므로 자동으로 다시 시작되어 데이터베이스에 다시 연결됩니다. 그러면 장애 조치 동안 리소스를 넘겨 받은 작동 데이터베이스(이전의 수동 컴퓨터) 컴퓨터에서 데이터베이스 연결 처리를 시작합니다.

DBNetLib(데이터베이스 네트워크 라이브러리) 오류는 BizTalk Server 런타임이 MessageBox 또는 관리 데이터베이스와 통신할 수 없을 때 발생합니다. 이 경우 예외를 catch하는 BizTalk Server 런타임 instance 종료된 다음 1분마다 순환하여 검사 데이터베이스를 사용할 수 있는지 확인합니다. 이 항목에 대한 자세한 내용은 참조 섹션을 참조하세요.

클라이언트에서 서버에 대한 TCP/IP 소켓 연결을 시작할 때 클라이언트에서는 일반적으로 서버의 특정 포트에 연결하며 서버가 임시 또는 단기 TCP 포트 또는 UDP 포트를 통해 클라이언트에 응답할 것을 요청합니다. Windows Server 2003 및 Windows XP에서 클라이언트 애플리케이션에서 사용하는 임시 포트의 기본 범위는 1025에서 5000까지입니다. 특정 조건에서는 기본 범위의 사용 가능한 포트가 소진될 수 있습니다. 이 항목에 대한 자세한 내용은 참조 섹션을 참조하세요.

이 분석은 데이터베이스 연결 실패 발생을 확인합니다. BizTalk가 데이터베이스 없이는 작동할 수 없으므로 데이터베이스 연결 실패가 중요합니다. 데이터베이스 연결 실패의 원인을 알 수 없는 경우 아래에 나열된 참조 및/또는 연결 실패의 특성을 확인하기 위해 Microsoft 지원 문의하세요.

참조

BizTalk 메시징 게시 제한 상태 분석

BizTalk 메시지 게시 제한 상태는 제한의 기본 지표 중 하나입니다. 시스템이 메시지 게시를 제한하고 있는지 여부를 나타내는 플래그입니다(XLANG 메시지 처리 및 인바운드 전송에 영향을 미치는). 제한 조건은 카운터의 숫자 값으로 표시됩니다. 값과 해당 의미의 목록은 다음과 같습니다.

제한 조건	설명
0	조정 안 함
2	불균형 메시지 게시 속도(입력 속도가 출력 속도를 초과함)로 인해 조정합니다.
4	프로세스 메모리 부족으로 인해 조정합니다.
5	시스템 메모리 부족으로 인해 조정합니다.
6	데이터베이스 증가로 인해 조정합니다.
8	많은 수의 세션으로 인해 조정합니다.
9	많은 수의 스레드로 인해 조정합니다.
11	게시할 때 사용자 재정의로 인해 조정합니다.

이 분석은 이러한 각 값을 확인하고 각 값에 대한 특정 경고를 줍니다.

참조

메모리에 상주하는 BizTalk 오케스트레이션

호스트 인스턴스에서 현재 호스팅 중인 오케스트레이션 인스턴스 수입니다. 메모리에 상주하는 오케스트레이션의 급증 또는 버스트는 정상으로 간주될 수 있지만, 증가하는 추세는 메모리에서 오케스트레이션의 "더미"를 나타낼 수 있습니다. BizTalk가 메시지/오케스트레이션 인스턴스를 탈수할 수 없는 경우 시간이 지남에 따라 증가하는 추세가 발생할 수 있습니다. 이 카운터를 "XLANG/s 오케스트레이션(?)과 상호 연결해 보세요. \탈수 가능한 오케스트레이션" 여기서 물음표(?)는 이 카운터와 동일한 카운터 instance.

많은 수의 오케스트레이션이 메모리에 상주하고 낮은 수의 오케스트레이션이 탈수 가능한 경우 오케스트레이션은 메모리에서 유휴 상태일 수 있으며 메모리 누수 상태가 발생할 수 있습니다. 있는 경우 "\XLANG/s 오케스트레이션(*)\유휴 오케스트레이션"과 상관관계에서 이 분석을 사용합니다. BizTalk 유휴 오케스트레이션의 증가 추세는 오케스트레이션 인스턴스를 탈수할 수 없기 때문에 메모리 누수를 더 잘 나타내는 지표입니다.

이 분석은 메모리에 상주하는 오케스트레이션의 증가 추세를 확인하고 메모리에 상주하는 오케스트레이션의 50% 이상이 탈수할 수 없는 경우를 확인합니다.

참조

BizTalk 프라이빗 바이트 분석

호스트 instance 할당된 프라이빗 메모리의 메가바이트이며 "\Process(*)\Private Bytes" 성능 카운터와 비슷합니다. 프라이빗 바이트는 프로세스가 다른 프로세스와 공유할 수 없는 할당된 메모리의 현재 크기(바이트)입니다. 이 분석은 호스트 인스턴스가 시스템 메모리의 큰 크기를 사용하는지 여부와 호스트 instance 시간이 지남에 따라 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 메모리의 상당 부분을 사용하는 호스트 instance 시스템에 메모리를 반환하는 한 괜찮습니다. 차트에서 증가하는 추세를 찾습니다. 오랜 기간 동안 증가하는 추세는 메모리 누수일 수 있습니다.

이 분석은 시간당 10MB 증가 추세를 확인합니다. 사용 가능한 메모리 분석 및 메모리 누수 분석과 상관 관계에 이 분석을 사용합니다. 또한 새로 시작된 호스트 인스턴스는 단순히 정상적인 시작 동작일 때 처음에 메모리 누수로 표시됩니다. 메모리 누수는 프로세스가 메모리를 계속 사용하고 오랜 기간 동안 메모리를 해제하지 않는 경우입니다. 메모리 누수 상태가 의심되는 경우 아래에 참조된 "BizTalk Messaging의 메모리 증가" 문서를 읽어보세요. 그렇지 않으면 디버그 Diag 도구를 설치하고 사용합니다. 디버그 Diag 도구에 대한 자세한 내용은 참조 섹션을 참조하세요.

참조

BizTalk 가상 바이트 분석

호스트 instance 가상 메모리용으로 예약된 메가바이트입니다. 이 분석은 호스트 인스턴스 중 어느 것이 시스템의 메모리를 많이 사용하는지 여부와 호스트 instance 시간이 지남에 따라 메모리 사용량이 증가하고 있는지 여부를 결정합니다. 메모리의 상당 부분을 사용하는 호스트 instance 시스템에 메모리를 반환하는 한 괜찮습니다. 차트에서 증가하는 추세를 찾습니다. 오랜 기간 동안 증가하는 추세는 메모리 누수일 수 있습니다.

이 분석은 시간당 10MB의 가상 바이트 증가 추세를 확인합니다. 사용 가능한 메모리 분석 및 메모리 누수 분석과 상관 관계에 이 분석을 사용합니다. 또한 새로 시작된 호스트 인스턴스는 단순히 정상적인 시작 동작일 때 처음에 메모리 누수로 표시됩니다. 메모리 누수는 프로세스가 메모리를 계속 사용하고 오랜 기간 동안 메모리를 해제하지 않는 경우입니다. 메모리 누수 상태가 의심되는 경우 아래의 "BizTalk Messaging의 메모리 증가" 문서를 읽어보세요. 그렇지 않으면 디버그 Diag 도구를 설치하고 사용합니다. 디버그 Diag 도구에 대한 자세한 내용은 참조 섹션을 참조하세요.

참조

BizTalk 메시지 에이전트 데이터베이스 세션 제한 분석

이는 각 BizTalk 제한 설정과 비교하여 MessageBox에 대한 열린 데이터베이스 연결 수입니다. "CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. 일반적인 호스트별 세션 풀의 유휴 데이터베이스 세션은 이 값에 추가되지 않으며 호스트 인스턴스에서 실제로 사용하는 세션 수에 대해서만 확인 작업이 수행됩니다. 이 옵션은 기본적으로 해제되어 있습니다. 일반적으로 이 설정은 BizTalk Server 시스템의 데이터베이스 서버에 병목 상태가 발생한 경우에만 설정해야 합니다. BizTalk:Message Agent 성능 개체 범주에서 데이터베이스 세션 성능 카운터를 사용하여 활성 데이터베이스 연결 수를 모니터링할 수 있습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. 데이터베이스 세션 수에 기반한 조정을 해제하려면 값 0을 입력합니다. 기본값은 0입니다.

MaxWorkerThreads 레지스트리 키는 BizTalk에서 사용할 수 있는 스레드 수에 영향을 미치며 대부분의 BizTalk 스레드가 데이터베이스 연결 사용 중인 경우에 도움이 될 수 있습니다. 이 분석은 MessageBox에 대한 열린 데이터베이스 연결 수가 데이터베이스 세션 제한 설정의 80%보다 큰지 확인하여 제한 조건이 발생할 가능성이 있음을 나타냅니다.

참조

BizTalk 메시지 에이전트 데이터베이스 세션 제한 임계값 분석

MessageBox에 대한 열린 데이터베이스 연결 수에 대한 현재 임계값입니다. "CPU당 데이터베이스 연결"은 제한이 시작되기 전에 허용되는 최대 동시 데이터베이스 세션 수(CPU당)입니다. 일반적인 호스트별 세션 풀의 유휴 데이터베이스 세션은 이 값에 추가되지 않으며 호스트 인스턴스에서 실제로 사용하는 세션 수에 대해서만 확인 작업이 수행됩니다. 이 옵션은 기본적으로 해제되어 있습니다. 일반적으로 이 설정은 BizTalk Server 시스템의 데이터베이스 서버에 병목 상태가 발생한 경우에만 설정해야 합니다. BizTalk:Message Agent 성능 개체 범주에서 데이터베이스 세션 성능 카운터를 사용하여 활성 데이터베이스 연결 수를 모니터링할 수 있습니다. 이 매개 변수는 아웃바운드 메시지 조정에만 영향을 미칩니다. 데이터베이스 세션 수에 기반한 조정을 해제하려면 값 0을 입력합니다. 기본값은 0입니다.

MaxWorkerThreads 레지스트리 키는 BizTalk에서 사용할 수 있는 스레드 수에 영향을 미치며 대부분의 BizTalk 스레드가 데이터베이스 연결 사용 중인 경우에 도움이 될 수 있습니다. 이 분석은 이 값을 확인하여 기본 설정에서 수정되었는지 확인합니다. 기본적으로 이 설정은 0입니다. 즉, 데이터베이스 세션에 대한 제한을 사용하지 않도록 설정됩니다.

참조

BizTalk 메시지 에이전트 In-process 메시지 수 제한 분석

서비스 클래스가 처리하는 동시 메시지의 수입니다. 호스트 제한 설정의 "CPU당 메시지 처리 중" 설정은 처리되지 않은 EPM(엔드포인트 관리자) 또는 XLANG에 전달되는 최대 메시지 수입니다. 여기에는 데이터베이스에서 검색된 메시지가 포함되지 않지만 여전히 메모리 내 큐에서 배달을 기다리고 있습니다. BizTalk:Message Agent 성능 개체 범주의 In-process 메시지 수 성능 카운터를 사용하여 In-Process 메시지 수를 모니터링할 수 있습니다. 이 매개 변수를 통해 조정 메커니즘에 조정 상태 고려 사항에 대한 정보를 제공할 수 있습니다. 실제 임계값은 자체 튜닝이 가능합니다. In-process message count 성능 카운터를 모니터링하여 실제 임계값을 확인할 수 있습니다.

대용량 메시지 시나리오(평균 메시지 크기가 높거나 메시지 처리에 많은 양의 메시지가 필요할 수 있음)의 경우 이 매개 변수를 더 작은 값으로 설정할 수 있습니다. 큰 메시지 시나리오는 메모리 기반 제한이 너무 자주 발생하는지와 메모리 임계값이 상당히 낮은 값으로 자동 조정되는지 여부를 나타냅니다. 이러한 동작은 과도한 메모리 사용을 방지하기 위해 아웃바운드 전송 시 보다 적은 수의 메시지를 동시에 처리해야 함을 나타냅니다. 또한 동시 연결을 제한하는 서버로 메시지를 보내는 경우처럼 어댑터가 한 번에 적은 수의 메시지를 처리할 때 보다 효율적인 시나리오의 경우 이 매개 변수를 기본값보다 작은 값으로 조정할 수 있습니다. 이 분석은 높은 In-Process 메시지 수 카운터를 확인하여 제한 조건이 가능성이 있음을 나타내는 동일한 이름 아래의 제한 설정의 80% 이상인지 확인합니다.

참조

BizTalk:Message Agent In-process 메시지 수 제한 임계값 분석

이는 서비스 클래스가 처리 중인 동시 메시지 수에 대한 현재 임계값입니다. 호스트 제한 설정의 "CPU당 메시지 처리 중" 설정은 처리되지 않은 EPM(엔드포인트 관리자) 또는 XLANG에 전달되는 최대 메시지 수입니다. 여기에는 데이터베이스에서 검색된 메시지가 포함되지 않지만 여전히 메모리 내 큐에서 배달을 기다리고 있습니다. BizTalk:Message Agent 성능 개체 범주의 In-process 메시지 수 성능 카운터를 사용하여 In-Process 메시지 수를 모니터링할 수 있습니다. 이 매개 변수를 통해 조정 메커니즘에 조정 상태 고려 사항에 대한 정보를 제공할 수 있습니다. 실제 임계값은 자체 튜닝이 가능합니다. In-process message count 성능 카운터를 모니터링하여 실제 임계값을 확인할 수 있습니다.

대용량 메시지 시나리오(평균 메시지 크기가 높거나 메시지 처리에 많은 양의 메시지가 필요할 수 있음)의 경우 이 매개 변수를 더 작은 값으로 설정할 수 있습니다. 큰 메시지 시나리오는 메모리 기반 제한이 너무 자주 발생하는지와 메모리 임계값이 상당히 낮은 값으로 자동 조정되는지 여부를 나타냅니다. 이러한 동작은 과도한 메모리 사용을 방지하기 위해 아웃바운드 전송 시 보다 적은 수의 메시지를 동시에 처리해야 함을 나타냅니다. 또한 동시 연결을 제한하는 서버로 메시지를 보내는 경우처럼 어댑터가 한 번에 적은 수의 메시지를 처리할 때 보다 효율적인 시나리오의 경우 이 매개 변수를 기본값보다 작은 값으로 조정할 수 있습니다. 이 분석은 기본값이 아닌 값에 대해 높은 In-Process 메시지 수 제한 임계값을 확인합니다.

참조

BizTalk 메시지 에이전트 프로세스 메모리 사용량(MB) 제한 분석

현재 프로세스(MB)의 메모리 사용량입니다. 게시할 일괄 처리에 가파른 메모리 요구 사항이 있거나 너무 많은 스레드가 메시지를 처리하는 경우 BizTalk 프로세스 메모리 제한이 발생할 수 있습니다. 시스템이 과도하게 제한되는 것처럼 보이는 경우 호스트의 프로세스 메모리 사용 임계값과 관련된 값을 늘리고 호스트 instance "메모리 부족" 오류를 생성하지 않는지 확인합니다. 프로세스 메모리 사용량 임계값을 늘려 "메모리 부족" 오류가 발생하는 경우 CPU 임계값당 내부 메시지 큐 크기 및 In-Process 메시지에 대한 값을 줄이는 것이 좋습니다. 이 전략은 대량 메시지 처리 시나리오에 특히 유용합니다.

BizTalk 서버가 정기적으로 가상 메모리가 부족하면 64비트 BizTalk Server 것이 좋습니다. 64비트 서버의 각 프로세스는 최대 4TB의 가상 메모리와 32비트의 2GB를 처리할 수 있습니다. 일반적으로 64비트 BizTalk 및 64비트 SQL Server 권장됩니다. 자세한 내용은 "BizTalk Server 64비트 지원" 참조를 참조하세요. 이 분석은 프로세스 메모리 사용량이 동일한 이름의 해당 제한 임계값의 80%보다 큰지 확인합니다. 기본적으로 BizTalk 프로세스 메모리 사용량 제한 설정은 프로세스에 사용할 수 있는 가상 메모리의 25%입니다. /3GB 스위치는 이 설정에 영향을 주지 않습니다.

참조

BizTalk:Message Agent Process Memory Usage (MB) Throttling Threshold Analysis

현재 프로세스(MB)의 메모리 사용량에 대한 현재 임계값입니다. 임계값은 이 프로세스에 사용할 수 있는 실제 메모리 양 및 해당 메모리 사용 패턴에 따라 동적으로 조정될 수 있습니다. 게시할 일괄 처리에 가파른 메모리 요구 사항이 있거나 너무 많은 스레드가 메시지를 처리하는 경우 BizTalk 프로세스 메모리 제한이 발생할 수 있습니다. 시스템이 과도하게 제한되는 것처럼 보이는 경우 호스트의 프로세스 메모리 사용 임계값과 관련된 값을 늘리고 호스트 instance "메모리 부족" 오류를 생성하지 않는지 확인합니다. 프로세스 메모리 사용량 임계값을 늘려 "메모리 부족" 오류가 발생하는 경우 CPU 임계값당 내부 메시지 큐 크기 및 In-Process 메시지에 대한 값을 줄이는 것이 좋습니다. 이 전략은 대량 메시지 처리 시나리오에 특히 유용합니다.

BizTalk 서버가 정기적으로 가상 메모리가 부족하면 64비트 BizTalk Server 것이 좋습니다. 64비트 서버의 각 프로세스는 최대 4TB의 가상 메모리와 32비트의 2GB를 처리할 수 있습니다. 일반적으로 64비트 BizTalk 및 64비트 SQL Server 권장됩니다. 자세한 내용은 "BizTalk Server 64비트 지원" 참조를 참조하세요. 이 분석은 프로세스 메모리 제한이 기본값이 아닌 값으로 설정되어 있는지 여부를 확인합니다.

다음을 통해 공유