성능 및 용량 모니터링(FAST Search Server 2010 for SharePoint)

아티클
01/25/2017

적용 대상: FAST Search Server 2010

마지막으로 수정된 항목: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint 배포의 성능 및 용량을 모니터링할 때는 두 가지 주요 분석 영역이 있습니다.

크롤링 및 인덱싱 성능 분석
쿼리 성능 분석

일반적으로 FAST Search Server 2010 for SharePoint 팜을 모니터링하는 방법에 대한 자세한 내용은 FAST Search Server 2010 for SharePoint 모니터링을 참조하십시오. 일반적으로 Microsoft SharePoint Server 2010 팜을 모니터링하는 방법에 대한 자세한 내용은 SharePoint Server 2010 모니터링 및 유지 관리을 참조하십시오.

FAST Search Server 2010 for SharePoint에 대한 관련된 성능 카운터 개요를 보려면 성능 카운터(FAST Search Server 2010 for SharePoint)를 참조하십시오.

참고

이 문서에서는 SharePoint Server 2010 크롤러, 인덱싱 커넥터 프레임워크 및 FAST Search Server 2010 for SharePoint Content SSA(Content Search Service 응용 프로그램)를 사용하여 콘텐츠를 크롤링하는 것으로 간주합니다.

크롤링 및 인덱싱 성능 분석

콘텐츠 처리 체인

FAST Search Server 2010 for SharePoint의 항목 처리 체인은 개별 서버에서 실행될 수 있는 다음과 같은 구성 요소로 구성됩니다.

크롤러FAST Search Server 2010 for SharePoint에 콘텐츠를 넣는 모든 구성 요소입니다.
콘텐츠 배포자콘텐츠를 배치로 수신하고 배치를 항목 처리 및 인덱싱에 배포합니다.
**문서 프로세서(항목 처리)**항목을 통합 내부 형식으로 변환합니다.
인덱싱 발송자처리된 항목 배치를 인덱스 열에 배포합니다.
기본 인덱서검색 가능한 인덱스를 생성합니다.
백업 인덱서기본 인덱서의 해당 정보에 대한 백업을 저장합니다.

콘텐츠는 항목 처리 체인 그림에서 1-5의 화살표 방향으로 이동합니다. 기본 인덱서에서 백업 인덱서로의 마지막 흐름은 선택적인 배포 항목입니다. 완료된 처리에 대한 비동기 콜백은 6-9 화살표 방향으로 표시된 대로 다른 방향으로 전파됩니다. 크롤러는 문서 배치(1)에 대해 수신하는 콜백(9)을 기준으로 크롤링 속도를 조절합니다. 이 체인에서 가장 속도가 느린 구성 요소에 따라 전체 크롤링 속도가 결정됩니다.

각 FAST Search Server 2010 for SharePoint 팜에는 하나 이상의 콘텐츠 배포자가 포함됩니다. 이러한 구성 요소는 모든 콘텐츠를 배치로 수신하여 항목 처리 구성 요소로 전달합니다. 다음 조건이 충족되는지 확인하여 성능 향상을 보장할 수 있습니다.

항목 처리 구성 요소가 효과적으로 사용되는지 여부
수신되는 콘텐츠 배치가 신속하게 처리되도록 배포되는지 여부

Content SSA에서 제출할 배치 큐가 일관적으로 제공되는 경우에만 최대 처리 능력을 얻을 수 있습니다. 각 항목 처리 구성 요소는 사용량이 많을 경우 CPU 코어를 100% 소비합니다. 항목 처리 구성 요소를 CPU 코어당 최대 한 개씩 확장할 수 있습니다.

인덱서는 FAST Search Server 2010 for SharePoint 설치에서 쓰기 작업이 가장 많은 구성 요소이며, 디스크 성능이 높은지 확인해야 합니다. 높은 인덱싱 작업은 동일한 행에서 실행될 때 쿼리 일치 작업에 영향을 줄 수도 있습니다. 인덱서는 항목을 여러 파티션으로 배포합니다. 파티션 0과 최대 3개의 다른 파티션은 동시에 진행되는 작업을 수행할 수 있습니다. 파티션 간에 항목을 재배포하는 동안 하나 이상의 파티션은 다른 파티션이 특정 체크포인트에 도달할 때까지 기다릴 수 있습니다.

팁

크롤링 및 인덱싱 성능은 Windows Server 2008 [R2]의 "성능 모니터"와 같은 여러 도구를 통해 또는 SCOM(Systems Center Operations Manager)에서 분석할 수 있습니다. 또한 indexerinfo 명령을 사용하여 인덱서 상태를 검색할 수 있습니다(예: indexerinfo -a status).

크롤링 성능 카운터

다음 표에서는 Content SSA에서 가장 중요한 성능 카운터를 보여 줍니다. 이러한 성능 카운터는 FAST Search Server 2010 for SharePoint 팜이 아니라 Content SSA 크롤링 구성 요소를 호스트하는 서버의 "OSS Search FAST Content Plugin"에서 찾아 볼 수 있습니다.

성능 카운터	설명
Batches ready	Content SSA가 콘텐츠 원본으로부터 검색하여 콘텐츠 배포자에 전달할 준비가 된 배치 수입니다. 값이 0이면 FAST Search Server 2010 for SharePoint 팜 백 엔드가 Content SSA의 크롤링 속도보다 빠르게 콘텐츠를 처리하는 중입니다.
Batches submitted	Content SSA가 FAST Search Server 2010 for SharePoint에 전송했고 아직 콜백을 보류 중인 배치 수입니다. 값이 0이면 FAST Search Server 2010 for SharePoint 팜 백 엔드에 처리하도록 전송한 항목이 없습니다.
Batches open	일부 처리 단계에 있는 총 배치 수입니다.
Items Total	서비스를 마지막으로 다시 시작한 이후 Content SSA에서 크롤링된 총 항목 수입니다.
Available Mbytes	컴퓨터에서 사용 가능한 총 메모리 양입니다. 기본적으로 Content SSA는 시스템 메모리의 80%가 사용되면 배치 집계를 중지합니다.
Processor time	컴퓨터의 전체 CPU 사용량입니다. CPU 부하가 높으면 Content SSA의 처리량이 제한될 수 있습니다.
Bytes Total/sec	컴퓨터의 전체 네트워크 사용량입니다. 네트워크 부하가 높으면 Content SSA가 크롤링하고 FAST Search Server 2010 for SharePoint 팜에 넣을 수 있는 데이터 속도에 대한 병목 현상이 발생할 수 있습니다.

콘텐츠 배포자 및 항목 처리 성능 카운터

다음 표에서는 콘텐츠 배포자 및 항목 처리를 위한 성능 카운터를 보여 줍니다. 시스템 전체 개요를 보려면 모든 콘텐츠 배포자에서 이러한 성능 카운터를 모두 합해야 합니다.

성능 카운터	설명
Document processors	각 콘텐츠 배포자에 등록된 항목 처리 구성 요소의 수입니다. 여러 콘텐츠 배포자가 있으면 항목 처리 구성 요소가 콘텐츠 배포자 간에 고르게 배포됩니다.
Document processors busy	콘텐츠 배치에서 현재 작업 중인 항목 처리 구성 요소의 수입니다. 이 값은 최대 부하에서의 총 항목 처리 구성 요소 수와 비슷해야 합니다.
Average dispatch time	콘텐츠 배포자가 항목 처리 구성 요소에 배치를 전송하는 데 걸리는 시간입니다. 이 값은 10밀리초 미만이어야 합니다. 값이 높으면 네트워크가 정체되었음을 나타냅니다.
Average processing time	항목 처리 구성 요소가 배치를 처리하는 데 걸리는 시간입니다. 이 시간은 콘텐츠 유형 및 배치 크기에 따라 크게 다를 수 있지만 일반적으로 60초 이내여야 합니다.
Available Mbytes	컴퓨터에서 사용 가능한 총 메모리 양입니다. 각 항목 처리 구성 요소에는 최대 2GB 메모리가 필요할 수 있습니다. 메모리 기아 상태는 처리 능력에 영향을 줍니다.
Processor time	컴퓨터의 전체 CPU 사용량입니다. 항목 처리 구성 요소는 CPU 소비율이 높습니다. 일반적으로 CPU 사용률은 크롤링 중에 높게 나타나지만 항목 처리의 우선 순위가 낮아져서 필요한 다른 구성 요소에 CPU 리소스를 양도합니다.
Bytes Total/sec	컴퓨터의 전체 네트워크 사용량입니다. 네트워크 부하가 높으면 FAST Search Server 2010 for SharePoint 서버에서 처리할 수 있는 데이터 속도에 대한 병목 현상이 발생할 수 있습니다.

인덱싱 발송자 및 인덱서 성능 카운터

다음 표에서는 인덱싱 발송자 및 인덱서에서 가장 중요한 성능 카운터를 보여 줍니다.

성능 카운터	설명
Current queue size	인덱서는 높은 부하에서 수신되는 작업을 큐에 넣습니다. 이러한 큐 처리는 특히 부분 업데이트의 경우에 일반적으로 수행됩니다. API 큐가 한 번도 0이 되지 않으면 인덱서가 병목 지점입니다. 인덱서 중 하나에서 큐가 256MB에 도달하면 크롤러가 일시 중지됩니다. 저장소 하위 시스템의 성능이 충분히 높지 않으면 이러한 현상이 발생할 수 있습니다. 또한 파티션 간에 콘텐츠를 대량으로 다시 배포하는 경우에도 많은 콘텐츠가 인덱싱되지 않도록 차단하므로 이러한 현상이 발생합니다.
FiXML fill rate	FiXML 파일(인덱서의 내부 항목 저장소)은 기본적으로 매일 오전 3시에서 5시 사이에 정기적으로 압축됩니다. FiXML 입력 속도가 낮으면(70% 미만) 작업 효율이 낮아질 수 있습니다.
Active documents	파티션 0과 1에는 각각 항목 수가 1백만 개 미만이어야 하며, 인덱싱 대기 시간을 낮게 유지하기 위해서는 이보다 더 낮아야 합니다. 항목 처리량이 높은 기간에는 일반적인 처리량에 대해 보다 최적의 성능을 제공하기 위해 파티션 0 및 1이 더 커지므로 인덱싱 대기 시간이 높아집니다. 쿼리 일치 구성 요소는 부하가 낮은 기간 동안 항목을 높은 번호의 파티션으로 자동으로 다시 정렬합니다.
% Idle Time	디스크 유휴 시간이 낮으면 저장소 하위 시스템이 포화 상태임을 나타냅니다.
% Free space	인덱서에는 쿼리 일치 구성 요소에서 현재 사용되는 인덱스 생성과 처리 중인 새 인덱스 생성을 위한 공간이 모두 필요합니다. 부하가 꽉찬 시스템에서 디스크 사용량은 항목 수가 동일하더라도 인덱서 상태에 따라 40%에서 거의 100%까지 달라질 수 있습니다.

Query performance analysis

SharePoint Server 2010 관리 보고서는 포괄적인 관점에서 쿼리 성능에 대한 유용한 통계를 제공합니다. 이러한 보고서는 시간별 추세를 추적하고 성능이 만족스럽지 않을 때 조사해야 하는 영역을 식별하는 데 효과적으로 사용할 수 있습니다.

쿼리 대기 시간은 웹 서버 렌더링, Query SSA 처리 및 백 엔드 처리의 세 가지 영역에서 발생할 수 있습니다. 일반적으로 웹 서버 페이지 렌더링으로 인한 대기 시간과 Query SSA 대기 시간은 SharePoint Server 2010(Query SSA)을 실행하는 서버에서 발생합니다. 이러한 대기 시간은 또한 SharePoint Server 2010 설치를 지원하는 SQL Server의 성능으로도 영향을 받습니다. 백 엔드 대기 시간은 FAST Search Server 2010 for SharePoint 서버 내에서 발생합니다.

쿼리 처리
쿼리 일치

쿼리는 Query SSA에서 FAST Search Server 2010 for SharePoint 쿼리 처리 구성 요소(배포 파일의 "쿼리")로 전송됩니다. 보고서에서 쿼리 처리는 “QRproxy”, “QRserver” 및 “Fdispatch”로 표시됩니다. Query SSA 및 쿼리 처리 구성 요소는 병목 현상을 일으킬 가능성이 높습니다. 두 항목 간의 차이점은 통신 지연 또는 쿼리 처리로 인한 것입니다.

쿼리 발송자(보고서에서 "Fdispatch"로 표시됨)는 인덱스 열 간에 쿼리를 배포합니다. 각 쿼리 일치 서버에서 인덱스 파티션 간에 쿼리를 배포하는 쿼리 발송자도 있습니다. 쿼리 결과에 포함된 데이터 양이 많으면 이러한 두 쿼리 발송자 모두 병목 현상을 일으킬 수 있습니다. 이러한 병목 현상은 네트워크 포화로 이어집니다. 쿼리 처리와 쿼리 일치 구성 요소 간의 통신을 위해서는 별도의 네트워크 스위치를 사용하는 것이 좋습니다.

쿼리 일치 구성 요소(보고서에서 "Fsearch"로 표시됨)는 인덱스에 대한 실제 쿼리 일치 수행, 쿼리 관련성 계산 및 상세한 구체화 수행을 담당합니다. 각 쿼리에 대해 이 구성 요소는 인덱서로 생성된 인덱스에서 필요한 정보를 읽습니다. 다시 사용할 가능성이 있는 정보는 메모리 캐시에 저장됩니다. 쿼리 일치 성능은 CPU 성능과 작은 임의 디스크 읽기 크기(일반적으로 16-64KB)로 인한 낮은 대기 시간에 의존합니다.

쿼리 처리 성능 카운터

다음 표에서는 Query SSA 및 쿼리 처리 구성 요소에서 보고되는 백 엔드 대기 시간을 상호 관련시키는 데 유용할 수 있는 성능 카운터를 보여 줍니다.

성능 카운터	설명
# Queries/sec	현재 초당 쿼리 수입니다.
# Requests/sec	현재 초당 요청 수입니다. 쿼리 부하 외에도 QRserver가 활성 상태인지 확인하기 위해 초당 하나의 내부 요청이 수신됩니다.
Average queries per minute	평균 쿼리 부하입니다.
Average latency last - ms	평균 쿼리 대기 시간입니다.
Peak queries per sec	최대 쿼리 부하입니다.

쿼리 일치 성능 카운터

다음 표에서는 쿼리 일치 구성 요소를 실행하는 서버를 분석하는 데 유용할 수 있는 성능 카운터를 보여 줍니다.

성능 카운터	설명
% Idle Time	디스크 유휴 시간이 낮으면 저장소 하위 시스템이 포화 상태임을 나타냅니다.
Avg. Disk sec/Read	각 쿼리에는 일련의 디스크 읽기가 필요합니다. 평균 읽기 대기 시간은 10밀리초 미만이 적합합니다.
Avg. Disk Read Queue Length	포화된 디스크 하위 시스템에서는 읽기 큐가 증가합니다. 큐는 쿼리 대기 시간에 영향을 줍니다. 쿼리 구성 요소를 실행하는 모든 서버에는 평균 큐 길이가 1보다 작은 것이 좋습니다. 단일 행 배포에서는 인덱싱 중에 이 값을 초과하여 검색 성능에 부정적인 영향을 주는 경우가 많습니다.
Processor time	CPU 활용률은 높은 쿼리 처리량에 대한 병목 지점이 될 수 있습니다. 쿼리 일치에 사용되는 프로세서 시간이 높은 경우(거의 100%), 쿼리 처리량을 더 이상 늘릴 수 없습니다.