SharePoint Server 2010 Search의 성능 및 용량 요구 사항 예측
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
요약: 이 문서에서는 소규모, 중간 규모 및 대규모 SharePoint Server 2010 팜을 비롯하여 Microsoft SharePoint Server 2010 Search의 다양한 배포 환경에 대한 용량 계획 정보를 제공합니다.
이 문서에서는 SharePoint Server 2010 Search의 공동 작업 환경 배포에 대한 용량 계획 정보를 제공합니다. 여기에는 세 가지 예제 검색 팜 구성의 다음과 같은 정보가 포함됩니다.
하드웨어, 팜 토폴로지 및 구성 등의 테스트 환경 사양
사용자 수 및 클래스, 팜 사용 특성 등의 데이터 생성에 사용되는 작업량
데이터베이스 콘텐츠 및 크기를 포함한 테스트 팜 데이터 집합
테스트 대상 환경과 관련된 상태 및 성능 데이터
또한 이 문서에는 예제와 비슷한 환경을 배포하는 데 필요한 하드웨어, 토폴로지 및 구성을 결정하는 방법과, 적절한 용량 및 성능 특성을 유지하도록 환경을 최적화하는 방법을 결정하기 위한 공통 테스트 데이터 및 권장 사항도 포함되어 있습니다.
SharePoint Server 2010 Search에는 이전 버전에 비해 더 다양한 기능과 유연한 토폴로지 모델이 포함되어 있습니다. 이 아키텍처를 적용하여 사용자에게 보다 강력한 기능을 제공하려면 먼저 이러한 기능이 팜의 용량 및 성능에 미치는 영향을 주의 깊게 검토해야 합니다.
이 문서를 읽고 나면 다음을 실행하는 방법을 이해할 수 있습니다.
환경의 성능 및 용량 목표 정의
배포할 사용자 수/유형 및 기능을 지원하는 데 필요한 하드웨어 계획
안정성과 효율성을 최적으로 유지하기 위한 물리적/논리적 토폴로지 디자인
성능 및 용량 목표 달성을 위해 환경 테스트, 유효성 검사 및 확장
환경의 주요 지표 모니터링
이 문서를 읽기 전에 다음을 숙지해야 합니다.
가용성
중복성
데이터베이스별 콘텐츠
계획 개요
이 문서의 시나리오에서는 팜의 적절한 용량 계획을 지원한다는 가정하에 소규모, 중간 규모 및 대규모 테스트 팜에 대해 설명합니다. 이러한 팜 크기는 대략적으로 다음과 같은 가정을 바탕으로 합니다.
크롤링되는 저장소는 주로 SharePoint Server 콘텐츠입니다.
대부분의 사용자 쿼리는 인덱스의 동일한 33% 내에 포함됩니다. 즉, 대부분의 사용자가 동일한 용어를 쿼리합니다.
속성 데이터베이스가 매우 커지지 않도록 기본 메타데이터 설정이 사용됩니다.
중간 규모 및 대규모 팜에서는 해당 검색 팜의 크롤링 구성 요소에 콘텐츠를 제공할 수 있는 전용 크롤링 대상(프런트 엔드 웹 서버)이 있습니다.
이러한 팜의 측정값은 네트워크 및 환경의 상황에 따라 달라질 수 있으며, 오차는 최대 10%입니다.
시나리오 선택
적절한 시나리오를 선택하려면 다음 사항을 고려하십시오.
콘텐츠 모음 크기 검색할 수 있어야 하는 콘텐츠의 양. 총 항목 수에는 문서, 웹 페이지, 목록 항목 등 모든 개체가 포함되어야 합니다.
가용성 가용성 요구 사항. 고객이 특정 서버에 오류가 발생해도 사용 가능한 검색 솔루션을 필요로 하는지 여부를 파악합니다.
콘텐츠의 최신 상태 검색 결과의 최신 상태 정도. 사용자가 콘텐츠를 변경한 후 검색 결과에서 업데이트된 콘텐츠를 제공하도록 할 기간과, 콘텐츠의 예상 변경 빈도를 파악합니다.
처리량 콘텐츠를 동시에 검색하는 사용자 수. 여기에는 쿼리 상자에 입력하는 사용자의 쿼리와 데이터를 자동으로 검색하는 웹 파트와 같은 기타 숨겨진 쿼리 또는 검색 시스템에서 보안 조정이 필요한 URL이 포함된 작업 피드를 요청하는 Microsoft Outlook 2010 Social Connector가 포함됩니다.
이러한 사항에 대해 파악된 정보를 기반으로 다음 시나리오 중 하나를 선택합니다.
소규모 팜 단일 SharePoint Server 팜에서 일부 리소스를 공유하는 단일 Search Service 응용 프로그램을 포함합니다. 소규모 배포에 주로 사용되며, 검색을 제공할 콘텐츠의 양이 제한됩니다(항목 1천만 개 미만). 원하는 콘텐츠 최신 상태 목표에 따라 업무 시간 중에 증분 크롤링이 수행될 수 있습니다.
중간 규모 팜 전용 팜에 하나 이상의 Search Service 응용 프로그램을 포함합니다. 이 전용 팜에서 다른 팜에 검색 서비스를 제공합니다. 검색을 제공할 콘텐츠의 양이 중간 정도이며(최대 4천만 개 항목), 콘텐츠 최신 상태 목표를 달성하기 위해 업무 시간 중에 증분 크롤링이 수행될 가능성이 높습니다.
대규모 팜 전용 팜에 하나 이상의 Search Service 응용 프로그램을 포함합니다. 이 전용 팜에서 다른 팜에 검색 서비스를 제공합니다. 검색을 제공할 콘텐츠의 양이 매우 많으며(최대 1억 개 항목), 콘텐츠 최신 상태 목표를 달성하기 위해 업무 시간 중에 증분 크롤링이 수행될 가능성이 높습니다.
검색 수명 주기
이러한 세 시나리오를 통해 팜의 초기 단계에서 용량을 예측할 수 있습니다. 콘텐츠를 크롤링하면 팜에서 검색 수명 주기의 다음 단계가 번갈아 가며 수행됩니다.
인덱스 가져오기 데이터 채우기의 첫 단계로, 기간은 콘텐츠 원본 크기에 따라 달라집니다. 이 단계의 특징은 다음과 같습니다.
콘텐츠 전체 크롤링이 수행됩니다(여러 크롤링이 동시에 수행될 가능성이 있음).
크롤링 시스템을 면밀하게 모니터링하여 크롤링되고 있는 호스트로 인해 크롤링 병목 현상이 발생하지 않는지 확인합니다.
일정량의 인덱스가 변경되면 각 쿼리 구성 요소에 대해 마스터 병합이 빈번하게 트리거됩니다.
인덱스 유지 관리 팜에서 가장 일반적으로 수행되는 단계로, 특징은 다음과 같습니다.
모든 콘텐츠가 증분 크롤링됩니다.
SharePoint Server 콘텐츠 크롤링의 경우 크롤링 중에 수행되는 대부분의 변경 작업은 보안 관련 변경 작업입니다.
일정량의 인덱스가 변경되어도 각 쿼리 구성 요소에 대해 마스터 병합이 빈번하게 트리거되지 않습니다.
인덱스 정리 이 단계는 콘텐츠가 변경되어 팜이 인덱스 유지 관리 단계를 벗어나는 경우(예: 콘텐츠 데이터베이스 또는 사이트가 Search Service 응용 프로그램 간에 이동하는 경우)에 수행됩니다. 다음 두 가지 경우 중 하나가 발생하면 이 단계가 트리거됩니다.
검색 크롤러가 오랜 시간 동안 콘텐츠를 제공하는 호스트를 찾지 못하는 경우
콘텐츠 원본 또는 시작 주소가 Search Service 응용 프로그램에서 삭제되는 경우
시나리오
이 시나리오에서는 소규모, 중간 규모 및 대규모 팜 시나리오에 사용된 구성에 대해 설명합니다. 또한 각 환경의 작업량, 데이터 집합, 성능 데이터 및 테스트 데이터도 제공합니다.
소규모 팜
팜이 소규모이면 일부 서버에서 여러 역할을 수행해야 합니다. 크롤링 구성 요소와 쿼리 구성 요소가 같은 서버에 배치되지 않도록 쿼리 구성 요소를 프런트 엔드 웹 서버와 결합하는 것이 좋습니다. 이 구성에서는 응용 프로그램 서버 3대와 데이터베이스 서버 1대를 다음과 같이 사용합니다.
엔터프라이즈 검색에서는 중복 쿼리 서버를 사용하는 경우가 많으므로, 다음과 같은 구성이 지정된 응용 프로그램 서버 2대를 쿼리 구성 요소에 사용합니다.
한 응용 프로그램 서버에서는 검색 센터도 호스팅합니다. 서비스 팜으로 소규모 팜을 사용하는 경우에는 이 구성을 생략할 수 있으며, 그러면 검색 센터는 이 상위 서비스 팜에서 Search Service 응용 프로그램을 사용하는 하위 콘텐츠 팜에 만들어집니다.
항목 1천만 개 미만에 기본적으로 사용되는 쿼리 구성은 인덱스 파티션 1개입니다. 각 서버에서는 인덱스 파티션의 기본 쿼리 구성 요소 하나가 사용됩니다. 이와 같은 액티브/액티브 쿼리 구성 요소 설정을 사용하면 쿼리 구성 요소 중 하나에 오류가 발생해도 나머지 쿼리 구성 요소에서 쿼리를 계속 제공할 수 있습니다. 한 쿼리 구성 요소에 오류가 발생하면 검색에서는 사용 가능한 다음 쿼리 구성 요소로 쿼리를 보냅니다(라운드 로빈).
한 응용 프로그램 서버가 크롤링 및 관리에 사용됩니다(중앙 관리, 검색 관리 구성 요소 및 크롤링 구성 요소가 이 서버에 만들어짐).
단일 데이터베이스 서버가 팜을 지원합니다. 이 데이터베이스 서버에서는 크롤링, 속성 및 관리 데이터베이스에 대해 초당 특정 수의 입/출력 작업(IOPS)이 수행되어야 합니다(예: 서로 다른 저장소 배열 사용).
사양
이 섹션에서는 테스트 환경의 하드웨어, 소프트웨어, 토폴로지 및 구성에 대한 자세한 정보를 제공합니다.
토폴로지
.gif "검색 소규모 팜 토폴로지")
하드웨어
참고
테스트 팜에서는 시험판 SharePoint Server 2010 버전을 실행했으며 팀에서는 잠재적 문제를 방지하기 위해 일반적으로 필요한 것보다 용량이 많은 하드웨어를 서버에 사용했습니다.
웹 서버
| 웹 서버 | 프런트 엔드 웹 서버/쿼리(1) |
|---|---|
프로세서 |
1px4c@3GHz |
RAM |
16GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID1: DATA1 2x450GB 15K SAS: RAID1: DATA2 |
NIC(네트워크 인터페이스 카드) 수 |
2 |
NIC 속도 |
1기가비트 |
인증 |
NTLM |
부하 분산 유형 |
없음 |
소프트웨어 버전 |
SharePoint Server 2010(시험판) |
로컬로 실행되는 서비스 |
모든 서비스(검색 쿼리 및 사이트 설정 서비스 포함) |
응용 프로그램 서버
| 서버 | 쿼리(1) | 크롤링/관리(1) |
|---|---|---|
프로세서 |
1px4c@3GHz |
1px4c@3GHz |
RAM |
16GB |
16GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID1: DATA1 2x450GB 15K SAS: RAID1: DATA2 |
2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID1: TEMP 2x450GB 15K SAS: RAID0: DATA |
NIC 수 |
1 |
1 |
NIC 속도 |
1기가비트 |
1기가비트 |
인증 |
NTLM |
NTLM |
부하 분산 유형 |
없음 |
없음 |
소프트웨어 버전 |
SharePoint Server 2010(시험판) |
SharePoint Server 2010(시험판) |
로컬로 실행되는 서비스 |
SharePoint Server Search(검색 쿼리 및 사이트 설정 서비스) |
SharePoint Server Search |
데이터베이스 서버
| 데이터베이스 | 공유(1) |
|---|---|
프로세서 |
2px4c@3GHz |
RAM |
16GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID0: DATA 2x450GB 15K SAS: RAID0: LOGS 참고 드라이브 수가 감소하여 서로 다른 IO 채널에 데이터베이스를 분리하는 모범 사례는 적용할 수 없었습니다. |
NIC 수 |
2 |
NIC 속도 |
1기가비트 |
인증 |
NTLM |
소프트웨어 버전 |
Microsoft SQL Server 2008 Enterprise |
작업량
이 섹션에서는 사용자 수, 팜 사용 특성 등의 데이터 생성에 사용된 작업량에 대해 설명합니다.
| 작업량 특성 | 값 |
|---|---|
작업량 상세 설명 |
검색 팜 |
분당 평균 쿼리 |
6 |
평균 동시 사용자 수 |
1 |
일별 총 쿼리 수 |
8,640 |
데이터 집합
이 섹션에서는 데이터베이스 콘텐츠와 크기, 검색 인덱스 및 외부 데이터 원본 등의 테스트 팜 데이터 집합에 대해 설명합니다.
| 개체 | 값 |
|---|---|
검색 인덱스 크기(항목 수) |
900만 |
크롤링 데이터베이스 크기 |
52GB |
크롤링 데이터베이스 로그 파일 크기 |
11GB |
속성 데이터베이스 크기 |
68GB |
속성 데이터베이스 로그 파일 크기 |
1GB |
검색 관리 데이터베이스 크기 |
2GB |
활성 인덱스 파티션 크기 |
38.4GB(인덱스가 미러링되므로 총 76.8GB) |
총 검색 데이터베이스 수 |
3 |
기타 데이터베이스 |
SharePoint_Config, SharePoint_AdminContent, State_Service, Bdc_Service_db, WSS_UsageApplication, WSS_Content |
상태 및 성능 데이터
이 섹션에서는 테스트 환경과 관련된 상태 및 성능 데이터를 제공합니다.
쿼리 성능 데이터
아래 수치는 인덱스에 포함된 9백만 개의 항목에서 측정한 것입니다. 각 열에는 특정 테스트 중에 측정된 값이 나와 있으며, 결과는 다음 표의 맨 아래에 나와 있습니다. 측정값은 다음과 같이 설명됩니다.
쿼리 대기 시간 이러한 값은 쿼리 대기 시간 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 표준 쿼리 집합을 단일 사용자로 제출한 다음 결과 대기 시간을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
쿼리 처리량 이러한 값은 쿼리 처리량 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 팜에 대해 표준 쿼리 집합을 점점 증가하는 동시 사용자 수(최대 80명)로 제출한 다음 결과 대기 시간 및 처리량을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
| 성과 기록표 메트릭 | 쿼리 대기 시간 | 쿼리 처리량 | |
|---|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU |
3.4% |
12% |
평균 프런트 엔드 웹 서버 CPU |
8% |
51% |
|
평균 쿼리 서버 CPU |
13.3% |
95% |
|
안정성 |
오류율 |
0 |
0 |
프런트 엔드 웹 서버 작동 중단 |
0 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
0 |
|
SQL Server |
캐시 적중률(SQL Server) |
99.97% |
100% |
SQL Server 잠금: 평균 대기 시간(밀리초) |
0.071 |
0.038 |
|
SQL Server 잠금: 잠금 대기 시간(밀리초) |
0.035 |
0.019 |
|
SQL Server 잠금: 초당 교착 상태 |
0 |
0 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
31 |
0.017 |
|
초당 SQL Server 컴파일 |
14.9 |
10.2 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일 |
0.087 |
0.05 |
|
평균 디스크 큐 길이(SQL Server) |
0.011 |
0.01 |
|
디스크 큐 길이: 쓰기(SQL Server) |
0.01 |
0.008 |
|
|
초당 디스크 읽기(SQL Server) |
0.894 |
0.05 |
초당 디스크 쓰기(SQL Server) |
45 |
106 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(쿼리 서버) |
0.013 |
0.001 |
디스크 큐 길이: 쓰기(쿼리 서버) |
0 |
0.001 |
|
초당 디스크 읽기(쿼리 서버) |
11.75 |
0.06 |
|
초당 디스크 쓰기(쿼리 서버) |
4 |
5.714 |
|
평균 메모리 사용량(쿼리 서버) |
8.73% |
9% |
|
최대 메모리 사용량(쿼리 서버) |
8.75% |
9% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
0 |
0 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
9.67% |
95% |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
9.74% |
100% |
|
테스트 결과 |
성공 횟수 |
1,757 |
13,608 |
오류 횟수 |
0 |
0 |
|
쿼리 UI 대기 시간(75번째 백분위수) |
0.331초 |
3.68초 |
|
쿼리 UI 대기 시간(95번째 백분위수) |
0.424초 |
3.93초 |
|
쿼리 처리량 |
초당 3.29개 요청 |
초당 22.4개 요청 |
크롤링 성능 데이터
다음 값은 지정된 콘텐츠 원본에 대한 초기 순차 전체 크롤링 중에 측정한 것입니다. 콘텐츠 원본 크기는 항목 1백만 개 단위로 지정됩니다. 각 열에는 특정 크롤링 중에 측정된 값이 나와 있으며, 결과는 표의 맨 아래에 나와 있습니다.
| 성과 기록표 메트릭 | SharePoint 콘텐츠(4M) | 파일 공유(1M) | HTTP(비 SharePoint, 1M) | |
|---|---|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU |
5.4% |
11.7% |
23% |
평균 인덱서 CPU |
41.6% |
69% |
71% |
|
안정성 |
오류율 |
0 |
0 |
0 |
프런트 엔드 웹 서버 작동 중단 |
0 |
0 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
0 |
0 |
|
SQL Server |
캐시 적중률(SQL Server) |
해당 없음 |
해당 없음 |
해당 없음 |
SQL Server 잠금: 평균 대기 시간(밀리초) |
436 |
51.76 |
84.73 |
|
SQL Server 잠금: 잠금 대기 시간(밀리초) |
해당 없음 |
해당 없음 |
해당 없음 |
|
SQL Server 잠금: 초당 교착 상태 |
해당 없음 |
해당 없음 |
해당 없음 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
1.05 |
1.64 |
3.53 |
|
초당 SQL Server 컴파일 |
해당 없음 |
해당 없음 |
해당 없음 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일 |
해당 없음 |
해당 없음 |
해당 없음 |
|
평균 디스크 큐 길이(SQL Server) |
27.124 |
6.85 |
45 |
|
디스크 큐 길이: 쓰기(SQL Server) |
17.6 |
6.7 |
21.57 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(크롤링 서버) |
0.008 |
0.032 |
0.02 |
디스크 큐 길이: 쓰기(크롤링 서버) |
0.006 |
0.025 |
0.012 |
|
평균 메모리 사용량(크롤링 서버) |
14.16% |
10.4% |
11.5% |
|
최대 메모리 사용량(크롤링 서버) |
19.2% |
11.13% |
12.78% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
0 |
0 |
0 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
해당 없음 |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
해당 없음 |
|
테스트 결과 |
성공 횟수 |
3,934,881 |
1,247,838 |
996,982 |
오류 횟수 |
9,645 |
302 |
2 |
|
포털 크롤링 속도(초당 항목) |
46.32 |
120.436 |
138.316 |
|
앵커 크롤링 속도 |
5,197 |
3,466.219 |
2,192.982 |
|
총 크롤링 속도(초당 항목) |
45.91 |
116.392 |
130.086 |
테스트 데이터
이 섹션에서는 팜의 성능을 보여 주는 테스트 데이터를 제공합니다. 팜 성능을 개선하는 방법을 파악하려면 이 문서 뒷부분의 최적화 섹션을 참조하십시오.
쿼리 대기 시간
아래 그래프에는 사용자 부하의 증가에 따른 이 팜의 쿼리 대기 시간 백분위수가 표시되어 있습니다(쿼리 처리량 테스트 중에 수집됨). 95% 쿼리 백분위수는 측정된 쿼리 대기 시간의 95%가 해당 값보다 낮았음을 의미합니다.
.gif "쿼리 대기 시간에 대한 사용자 부하 영향 백분위수")
이 그래프에서는 팜에서 동시에 쿼리를 수행하는 사용자가 더 많아도(20명), 인덱스 크기가 작을수록 이 팜이 초 단위 미만의 쿼리 대기 시간을 유지할 수 있음을 확인할 수 있습니다.
쿼리 처리량
다음 그래프에는 사용자 부하의 증가에 따른 이 팜의 쿼리 처리량이 표시되어 있습니다(쿼리 처리량 테스트 중에 수집됨).
.gif "쿼리 처리량에 대한 사용자 부하 영향")
위의 두 그래프를 참고할 때, 사용자 부하를 동시 사용자 20명보다 더 추가하는 경우 이 팜의 쿼리 처리량은 더 추가되지 않으며 대기 시간은 길어집니다.
크롤링 속도
다음 그래프에는 검색 수명 주기의 인덱스 가져오기 단계 중 이 팜의 크롤링 속도가 표시되어 있습니다. 그래프의 값은 전체 크롤링(초당 크롤링된 항목 수)을 나타냅니다.
.gif "콘텐츠 유형별 전체 크롤링 속도")
SharePoint 사이트 콘텐츠 원본에서 전체 크롤링을 효율적으로 수행하는 데 필요한 추가 오버헤드로 인해 이 팜의 전체적인 크롤링 속도가 낮아졌습니다.
전체 사용량
이 팜에서는 쿼리 서버의 RAM 용량을 거의 모두 사용합니다. 역시 RAM을 사용하는 프런트 엔드 웹 서버 프로세스도 쿼리 서버 중 하나에서 수행되므로, 해당 서버에서 실행되는 쿼리의 대기 시간에 영향을 줍니다.
이 팜의 성능을 개선하려면 다음과 같은 단계를 수행할 수 있습니다.
프런트 엔드 웹 서버를 자체 프런트 엔드 웹 서버로 이동합니다(중복성을 위해 다른 프런트 엔드 웹 서버 추가).
두 쿼리 서버에 모두 RAM을 더 추가합니다. 쿼리 서버의 RAM은 액티브 쿼리 구성 요소의 인덱스 파티션 33%에 운영 체제와 기타 프로세스용으로 3GB를 더한 값만큼 충분히 확보하는 것이 좋습니다.
데이터베이스 서버에서 데이터베이스를 분리할 수 있도록 저장소 배열을 추가합니다.
중간 규모 팜
중간 규모 팜에서는 웹 서버 1대, 응용 프로그램 서버 6대, 그리고 데이터베이스 서버 2대를 다음과 같이 사용합니다.
이 테스트 구성에서는 검색 센터 호스팅용으로 웹 서버 1대를 사용했습니다. 하위 팜에 설치된 Search Service 응용 프로그램 프록시를 사용하여 하위 팜에서 검색을 항상 수행하는 경우에는 이 웹 서버를 생략해도 됩니다. 그렇지 않으면 중복성을 위해 이 팜에 다른 웹 서버를 추가합니다.
크롤링 및 관리용으로 두 응용 프로그램 서버를 사용합니다. 이는 다음을 의미합니다.
응용 프로그램 서버 중 하나에 중앙 관리 및 검색 관리 구성 요소를 만듭니다.
각 서버에는 크롤링 구성 요소가 2개 있으며, 각 크롤링 구성 요소는 중복성을 위해 서로 다른 크롤링 데이터베이스에 연결됩니다.
나머지 네 응용 프로그램 서버는 쿼리에 사용됩니다. 항목이 최대 4천만 개인 경우에는 표준 구성에 인덱스 파티션이 4개 있습니다. 각 서버가 인덱스 파티션 중 하나에서 액티브 쿼리 구성 요소 1개를, 그리고 다른 인덱스 파티션에서 장애 조치(failover) 쿼리 구성 요소를 사용하도록 쿼리 구성 요소를 정렬하면 중복 쿼리 기능을 사용할 수 있습니다. 그러나 이 예제 팜에서는 항목을 4천만 개보다 많이 사용하도록 계획하는 경우에 수행해야 하는 작업을 보여 줍니다. 먼저 인덱스 다시 분할을 최소화하기 위해 4개의 응용 프로그램 서버에 8개의 인덱스 파티션을 만듭니다(각 파티션에는 자체 액티브 및 장애 조치 쿼리 구성 요소가 있음). 동일한 응용 프로그램 서버에 4개의 구성 요소를 배치할 수 있도록, 각 서버는 다음과 같은 지침을 충족한다고 가정합니다.
충분한 RAM 및 IOPS를 사용할 수 있습니다.
각 서버에는 다음과 같이 처리를 지원하기 위해 7개 이상의 CPU 코어가 있습니다.
액티브 쿼리 구성 요소 2개용 CPU 코어 4개
장애 조치(failover) 쿼리 구성 요소 2개용 CPU 코어 2개
데이터베이스 서버 2대에서 팜을 지원합니다. 그 중 한 데이터베이스 서버는 크롤링 데이터베이스 2개에 사용되고, 나머지 서버는 기타 SharePoint 데이터베이스에도 사용되고 속성 및 검색 관리 데이터베이스에도 사용됩니다. 이들 데이터베이스 서버에서는 각 크롤링, 속성 및 검색 관리 데이터베이스에 대해 특정 수의 IOPS가 수행되어야 합니다(예: 서로 다른 저장소 배열 사용).
사양
이 섹션에서는 테스트 환경의 하드웨어, 소프트웨어, 토폴로지 및 구성에 대한 자세한 정보를 제공합니다.
토폴로지
.gif "검색 중간 규모 토폴로지")
하드웨어
참고
테스트 팜에서는 시험판 SharePoint Server 2010 버전을 실행했으며 팀에서는 잠재적 문제를 방지하기 위해 일반적으로 필요한 것보다 용량이 많은 하드웨어를 서버에 사용했습니다.
웹 서버
| 웹 서버 | 프런트 엔드 웹 서버(1) |
|---|---|
프로세서 |
2px4c@2.33GHz |
RAM |
8GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS |
NIC 수 |
2 |
NIC 속도 |
1기가비트 |
인증 |
NTLM |
부하 분산 유형 |
없음 |
소프트웨어 버전 |
Microsoft SharePoint Server(시험판) |
로컬로 실행되는 서비스 |
모든 서비스 |
응용 프로그램 서버
팜에는 응용 프로그램 서버가 6대 있습니다. 그 중 4대는 쿼리를 처리하는 데 사용되고 2대는 크롤링에 사용됩니다.
| 서버(개수) | 쿼리(4) | 크롤링(1), 크롤링/관리(1) |
|---|---|---|
프로세서 |
2px4c@2.33GHz |
2px4c@2.33GHz |
RAM |
32GB |
8GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS 4x300GB 15K SAS: RAID10: Data |
2x148GB 15K SAS: RAID1: OS/Data |
NIC 수 |
2 |
2 |
NIC 속도 |
1기가비트 |
1기가비트 |
인증 |
NTLM |
NTLM |
부하 분산 유형 |
없음 |
없음 |
소프트웨어 버전 |
SharePoint Server 2010(시험판) |
SharePoint Server 2010(시험판) |
로컬로 실행되는 서비스 |
SharePoint Server Search(검색 쿼리 및 사이트 설정 서비스) |
SharePoint Server Search |
데이터베이스 서버
데이터베이스 서버는 2대이며, 그 중 첫 번째 서버에는 검색 관리, 속성 및 기타 SharePoint Server 데이터베이스가 포함되어 있고 두 번째 서버에는 2개의 크롤링 데이터베이스가 포함되어 있습니다. 저장소 볼륨은 테스트에 사용할 수 있는 기존 하드웨어를 최적화하도록 작성되었습니다.
| 데이터베이스 서버 | 검색 관리, 속성, SharePoint 데이터베이스 | 크롤링 데이터베이스 |
|---|---|---|
프로세서 |
2px4c@3.2GHz |
4px2c@2.19GHz |
RAM |
32GB |
16GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS 2x148GB 15K SAS: RAID1: TEMP Log 2x450GB 15K SAS: RAID1: TEMP DB 6x450GB 15K SAS: RAID10: Property DB 2x450GB 15K SAS: RAID1: Search Admin, SharePoint DBs 2x450GB 15K SAS:RAID1:Logs |
2x148GB 15K SAS: RAID1: OS 2x148GB 15K SAS: RAID1: TEMP Log 2x300GB 15K SAS: RAID1: TEMP DB 6x146GB 15K SAS: RAID10: Crawl DB1 6x146GB 15K SAS: RAID10: Crawl DB2 2x300GB 15K SAS: RAID1:Crawl DB Log1 2x300GB 15K SAS: RAID1: Crawl DB Log2 |
NIC 수 |
2 |
2 |
NIC 속도 |
1기가비트 |
1기가비트 |
인증 |
NTLM |
NTLM |
소프트웨어 버전 |
SQL Server 2008 Enterprise |
SQL Server 2008 Enterprise |
작업량
이 섹션에서는 사용자 수, 팜 사용 특성 등의 데이터 생성에 사용된 작업량에 대해 설명합니다.
| 작업량 특성 | 값 |
|---|---|
작업량 상세 설명 |
검색 팜 |
분당 평균 쿼리 |
12 |
평균 동시 사용자 수 |
1 |
일별 총 쿼리 수 |
17,280 |
타이머 작업 |
검색 상태 모니터링 - 추적 이벤트, 크롤링 로그 보고서, 상태 분석 작업, 검색 및 프로세스 |
데이터 집합
이 섹션에서는 데이터베이스 콘텐츠와 크기, 검색 인덱스 및 외부 데이터 원본 등의 테스트 팜 데이터 집합에 대해 설명합니다.
| 개체 | 값 |
|---|---|
검색 인덱스 크기(항목 수) |
4,600만 |
크롤링 데이터베이스 크기 |
356GB |
크롤링 데이터베이스 로그 파일 크기 |
85GB |
속성 데이터베이스 크기 |
304GB |
속성 데이터베이스 로그 파일 크기 |
9GB |
검색 관리 데이터베이스 크기 |
5GB |
활성 인덱스 파티션 크기 |
316GB(액티브 구성 요소당 79GB) |
총 데이터베이스 수 |
4 |
기타 데이터베이스 |
SharePoint_Config, SharePoint_AdminContent, State_Service, Bdc_Service_db, WSS_UsageApplication, WSS_Content |
상태 및 성능 데이터
이 섹션에서는 테스트 환경과 관련된 상태 및 성능 데이터를 제공합니다.
쿼리 성능 데이터
아래 수치는 검색 인덱스에 포함된 4,600만 개의 항목에서 측정한 것입니다. 각 열에는 특정 테스트 중에 측정된 값이 나와 있으며, 결과는 표의 맨 아래에 나와 있습니다. 측정값은 다음과 같이 설명됩니다.
쿼리 대기 시간 이러한 값은 쿼리 대기 시간 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 표준 쿼리 집합을 단일 사용자로 제출한 다음 결과 대기 시간을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
쿼리 처리량 이러한 값은 쿼리 처리량 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 팜에 대해 표준 쿼리 집합을 점점 증가하는 동시 사용자 수(최대 80명)로 제출한 다음 결과 대기 시간 및 처리량을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
| 성과 기록표 메트릭 | 쿼리 대기 시간 | 쿼리 처리량 | |
|---|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU(속성 데이터베이스 서버) |
5% |
98% |
평균 프런트 엔드 웹 서버 CPU |
3% |
33% |
|
평균 쿼리 서버 CPU |
3% |
47% |
|
안정성 |
오류율 |
0.07% |
0% |
프런트 엔드 웹 서버 작동 중단 |
0 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
0 |
|
SQL Server (속성 데이터베이스 서버) |
캐시 적중률(SQL Server) |
100% |
99.9% |
SQL Server 잠금: 평균 대기 시간(밀리초) |
0.000 |
0.159 |
|
SQL Server 잠금: 잠금 대기 시간(밀리초) |
0.000 |
0.080 |
|
SQL Server 잠금: 초당 교착 상태 |
0 |
0 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
0.041 |
1.626 |
|
초당 SQL Server 컴파일 |
9.776 |
93.361 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일 |
0.059 |
0.071 |
|
읽기/쓰기 속도(데이터베이스당 IO) |
0.01 |
0.81 |
|
평균 디스크 큐 길이(SQL Server) |
0.001 |
0.037 |
|
디스크 큐 길이: 쓰기(SQL Server) |
0.000 |
0.003 |
|
|
초당 디스크 읽기(SQL Server) |
0.057 |
14.139 |
초당 디스크 쓰기(SQL Server) |
4.554 |
17.515 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(쿼리 서버) |
0.000 |
0.001 |
디스크 큐 길이: 쓰기(쿼리 서버) |
0.000 |
0.001 |
|
초당 디스크 읽기(쿼리 서버) |
0.043 |
0.266 |
|
초당 디스크 쓰기(쿼리 서버) |
4.132 |
5.564 |
|
평균 메모리 사용량(쿼리 서버) |
9% |
10% |
|
최대 메모리 사용량(쿼리 서버) |
9% |
10% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
0 |
0 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
47% |
48% |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
47% |
49% |
|
테스트 결과 |
성공 횟수 |
1,398 |
14,406 |
오류 횟수 |
1 |
0 |
|
쿼리 UI 대기 시간(75번째 백분위수) |
0.47초 |
2.57초 |
|
쿼리 UI 대기 시간(95번째 백분위수) |
0.65초 |
3.85초 |
|
쿼리 처리량 |
초당 2.38개 요청 |
초당 27.05개 요청 |
크롤링 성능 데이터
다음 값은 지정된 콘텐츠 원본에 대한 초기 전체 크롤링 중에 측정한 것입니다. 콘텐츠 원본 크기는 항목 1백만 개 단위로 지정됩니다. 각 열에는 특정 크롤링 중에 측정된 값이 나와 있으며, 결과는 표의 맨 아래에 나와 있습니다.
| 성과 기록표 메트릭 | SharePoint 콘텐츠(3,500만 개) | 파일 공유(1백만 개) | HTTP(비 SharePoint, 1백만 개) | |
|---|---|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU(크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
11%, 19% |
22%, 7% |
23%, 5% |
최대 SQL Server CPU(크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
96%, 100% |
86%, 45% |
79%, 28% |
|
평균 인덱서 CPU |
41.6% |
69% |
71% |
|
안정성 |
오류율 |
0.2% |
0.02% |
0% |
프런트 엔드 웹 서버 작동 중단 |
0 |
0 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
0 |
0 |
|
SQL Server (크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
캐시 적중률(SQL Server) |
99.5%, 99.8% |
수집되지 않음 |
99.9%, 99.3% |
SQL Server 잠금: 평균 대기 시간(밀리초) |
1,881.749, 1,106.314 |
1,617.980, 2.882 |
983.137, 0.904 |
|
SQL Server 잠금: 최대 대기 시간(밀리초) |
69,919.500, 1,081,703 |
55,412.000, 304.500 |
24,000.500, 47 |
|
SQL Server 잠금: 평균 잠금 대기 시간(밀리초) |
339.658, 10,147.012 |
수집되지 않음 |
739.232, 0.136 |
|
SQL Server 잠금: 최대 잠금 대기 시간(밀리초) |
598,106.544, 234,708,784 |
수집되지 않음 |
52,711.592, 23.511 |
|
SQL Server 잠금: 초당 교착 상태 |
0.001, 0 |
수집되지 않음 |
0.008, 0 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
2.288, 13.684 |
3.042, 13.516 |
2.469, 20.093 |
|
SQL Server 래치: 최대 대기 시간(밀리초) |
2,636, 1,809 |
928, 858.5 |
242.929, 938.706 |
|
초당 SQL Server 컴파일: 평균 |
20.384, 5.449 |
수집되지 않음 |
76.157, 6.510 |
|
초당 SQL Server 컴파일: 최대 |
332.975, 88.992 |
수집되지 않음 |
295.076, 42.999 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일: 평균 |
0.560, 0.081 |
수집되지 않음 |
0.229, 0.125 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일: 최대 |
22.999, 88.492 |
수집되지 않음 |
17.999, 15.5 |
|
읽기/쓰기 속도(데이터베이스당 IO): 최대 |
2.15, 1.25 |
수집되지 않음 |
1.45, 0.364 |
|
평균 디스크 큐 길이(SQL Server) |
66.765, 27.314 |
129.032, 20.665 |
182.110, 11.816 |
|
최대 디스크 큐 길이(SQL Server) |
4,201.185, 5,497.980 |
3,050.015, 762.542 |
1,833.765, 775.7 |
|
디스크 큐 길이: 쓰기(SQL Server): 평균 |
58.023, 13.532 |
114.197, 19.9 |
175.621, 10.417 |
|
디스크 큐 길이: 쓰기(SQL Server): 최대 |
1,005.691, 881.892 |
1,551.437, 761.891 |
1,018.642, 768.289 |
|
|
초당 디스크 읽기(SQL Server): 평균 |
245.945, 94.131 |
수집되지 않음 |
137.435, 154.103 |
초당 디스크 읽기(SQL Server): 최대 |
6,420.412, 6,450.870 |
수집되지 않음 |
3,863.283, 1,494.805 |
|
초당 디스크 쓰기(SQL Server): 평균 |
458.144, 286.884 |
수집되지 않음 |
984.668, 278.175 |
|
초당 디스크 쓰기(SQL Server): 최대 |
2,990.779, 5,164.949 |
수집되지 않음 |
2,666.285, 4,105.897 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(크롤링 서버) |
0.052 |
0.043 |
0.030 |
디스크 큐 길이: 쓰기(크롤링 서버) |
0.029 |
0.031 |
0.026 |
|
초당 디스크 읽기(크롤링 서버) |
5.405 |
수집되지 않음 |
0.798 |
|
초당 디스크 쓰기(크롤링 서버) |
48.052 |
수집되지 않음 |
102.235 |
|
평균 메모리 사용량(크롤링 서버) |
68% |
45% |
52% |
|
최대 메모리 사용량(크롤링 서버) |
76% |
47% |
59% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
0 |
0 |
0 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
해당 없음 |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
해당 없음 |
|
테스트 결과 |
성공 횟수 |
3,631,080 |
1,247,838 |
200,000 |
오류 횟수 |
7,930 |
304 |
0 |
|
포털 크롤링 속도(초당 항목) |
82 |
148 |
81 |
|
앵커 크롤링 속도 |
1,573 |
1,580 |
1,149 |
|
총 크롤링 속도(초당 항목) |
79 |
136 |
76 |
테스트 데이터
이 섹션에서는 부하 시 팜의 성능을 보여 주는 테스트 데이터를 제공합니다.
쿼리 대기 시간
아래 그래프에는 사용자 부하의 증가에 따른 이 팜의 쿼리 대기 시간 백분위수가 표시되어 있습니다(쿼리 처리량 테스트 중에 수집됨). 95% 쿼리 백분위수는 측정된 쿼리 대기 시간의 95%가 해당 값보다 낮았음을 의미합니다.
.gif "쿼리 대기 시간에 대한 사용자 부하 영향 백분위수")
이 그래프에서는 팜에서 동시에 쿼리를 수행하는 사용자가 더 많아도(22명), 95번째 백분위수에서 인덱스 크기가 작을수록 이 팜이 초 단위 미만의 쿼리 대기 시간을 유지할 수 있음을 확인할 수 있습니다.
쿼리 처리량
다음 그래프에는 사용자 부하의 증가에 따른 이 팜의 쿼리 처리량이 표시되어 있습니다(쿼리 처리량 테스트 중에 수집됨).
.gif "쿼리 처리량에 대한 사용자 부하 영향")
이 그래프와 이전 그래프를 모두 고려할 때, 인덱스의 항목 수가 3,300만 개일 때 팜에서는 동시 사용자가 약 30명인 경우 75번째 백분위수에서 초 단위 미만의 대기 시간을 유지할 수 있음을 확인할 수 있습니다. 동시 사용자의 부하를 더 추가할 수도 있지만, 이 경우에는 쿼리 대기 시간이 초 단위 이상으로 길어집니다.
그러나 인덱스의 항목 수가 4,600만 개일 때는 동시 사용자 부하를 더 추가할 수 없으며 쿼리 대기 시간이 길어집니다.
크롤링 속도
다음 그래프에는 검색 수명 주기의 인덱스 가져오기 단계 중 이 팜의 크롤링 속도가 표시되어 있습니다. 그래프의 값은 전체 크롤링(초당 크롤링된 항목 수)을 나타냅니다.
.gif "콘텐츠 유형별 전체 크롤링 속도")
SharePoint 사이트 콘텐츠 원본을 효율적으로 크롤링하는 데 필요한 추가 오버헤드로 인해 이 팜의 전체적인 크롤링 속도가 낮아졌습니다.
전체 사용량
이 팜에서는 쿼리 서버의 RAM 용량을 거의 모두 사용합니다.
이 팜의 성능을 개선하려면 다음과 같은 단계를 수행할 수 있습니다.
두 쿼리 서버에 모두 RAM을 더 추가합니다. 쿼리 서버의 RAM은 액티브 쿼리 구성 요소의 인덱스 파티션 33%에 운영 체제와 기타 프로세스용으로 3GB를 더한 값만큼 충분히 확보하는 것이 좋습니다.
속성 데이터베이스를 호스팅하는 데이터베이스 서버에 RAM을 더 추가합니다. 이 구성에서 키 테이블의 크기는 인덱스를 포함해 약 92GB였으며, 권장 RAM 요구 사항은 30GB입니다. 그러나 데이터베이스 서버에는 속성 데이터베이스, 검색 관리 데이터베이스 및 기타 SharePoint Server 데이터베이스에 사용 가능한 RAM이 32GB뿐입니다.
데이터베이스 서버에서 데이터베이스를 분리할 수 있도록 저장소 배열을 추가합니다.
수평 확장을 통해 처리량을 늘리거나, 쿼리 대기 시간을 줄이거나 두 작업을 모두 수행합니다.
크롤링 데이터베이스가 2개이고 크롤링 구성 요소가 4개인 이 팜에서는 크롤링 속도가 높지만, 팜에서는 인덱스의 일정 부분이 보다 최신 상태여야 합니다. 즉, 특정 콘텐츠의 경우 매우 자주 크롤링해야 합니다. 호스트 배포 규칙을 사용하여 원하는 콘텐츠 원본의 호스트 전용으로 크롤링 데이터베이스를 더 추가하고, 데이터베이스에 두 개의 크롤링 구성 요소를 추가로 연결하면 인덱스의 콘텐츠 최신 상태 목표를 지원할 수 있습니다.
대규모 팜
대규모 팜의 예상 구성에서는 웹 서버 1대, 응용 프로그램 서버 13대, 그리고 데이터베이스 서버 3대를 다음과 같이 사용합니다.
한 웹 서버는 검색 센터를 호스팅하는 데 사용됩니다. 콘텐츠 팜에 설치된 Search Service 응용 프로그램 프록시를 사용하여 콘텐츠 팜에서 검색을 항상 수행하는 경우에는 이 웹 서버를 생략해도 됩니다.
크롤링 및 관리용으로 세 응용 프로그램 서버를 사용합니다. 이는 다음을 의미합니다.
응용 프로그램 서버 중 하나에 중앙 관리 및 검색 관리 구성 요소를 만듭니다.
각 서버에는 크롤링 구성 요소가 2개 있으며, 각 크롤링 구성 요소는 별도의 크롤링 데이터베이스에 연결됩니다.
나머지 응용 프로그램 서버 10대는 쿼리에 사용됩니다. 기본 구성에는 인덱스 파티션이 10개 있습니다. 따라서 각 서버에는 인덱스 파티션 중 하나의 기본 쿼리 구성 요소 하나가 있으며, 다른 인덱스 파티션의 장애 조치(failover) 쿼리 구성 요소도 있습니다.
데이터베이스 서버 4대에서 팜을 지원합니다. 그 중 한 서버는 속성 및 검색 관리 데이터베이스에 사용되고, 두 번째 서버는 속성 데이터베이스에 사용됩니다. 세 번째 서버는 크롤링 데이터베이스 2개에 사용되고, 네 번째 서버는 크롤링 데이터베이스 하나와 다른 SharePoint 데이터베이스에 사용됩니다. 이들 데이터베이스 서버에서는 각 크롤링, 속성 및 검색 관리 데이터베이스에 대해 특정 수의 IOPS가 수행되어야 합니다(예: 서로 다른 저장소 배열 사용).
사양
이 섹션에서는 테스트 환경의 하드웨어, 소프트웨어, 토폴로지 및 구성에 대한 자세한 정보를 제공합니다.
토폴로지
이 섹션에서는 테스트 환경의 토폴로지에 대해 설명합니다.
.gif "검색 대규모 팜 토폴로지")
하드웨어
이 섹션에서는 테스트에 사용된 하드웨어에 대해 설명합니다.
참고
테스트 팜에서는 시험판 SharePoint Server 2010 버전을 실행했으며 팀에서는 잠재적 문제를 방지하기 위해 일반적으로 필요한 것보다 용량이 많은 하드웨어를 서버에 사용했습니다.
웹 서버
| 웹 서버 | 프런트 엔드 웹 서버(1) |
|---|---|
프로세서 |
2px4c@2.33GHz |
RAM |
8GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS |
NIC 수 |
2 |
NIC 속도 |
1기가비트 |
인증 |
NTLM |
부하 분산 유형 |
없음 |
소프트웨어 버전 |
SharePoint Server 2010(시험판) |
로컬로 실행되는 서비스 |
모든 서비스 |
응용 프로그램 서버
팜에는 응용 프로그램 서버가 13대 있습니다. 그 중 10대는 쿼리를 처리하는 데 사용되고 3대는 크롤링에 사용됩니다.
| 서버(개수) | 쿼리(10) | 크롤링(2), 크롤링/관리(1) |
|---|---|---|
프로세서 |
2px4c@2.5GHz |
2px4c@2.5GHz |
RAM |
32GB |
32GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS 4x300GB 15K SAS: RAID10: Data |
2x148GB 15K SAS:RAID1: OS/Data |
NIC 수 |
2 |
2 |
NIC 속도 |
1기가비트 |
1기가비트 |
인증 |
NTLM |
NTLM |
부하 분산 유형 |
없음 |
없음 |
소프트웨어 버전 |
SharePoint Server 2010(시험판) |
SharePoint Server 2010(시험판) |
로컬로 실행되는 서비스 |
SharePoint Server Search(검색 쿼리 및 사이트 설정 서비스) |
SharePoint Server Search |
데이터베이스 서버
데이터베이스 서버는 4대입니다. 첫 번째 서버에는 검색 관리 및 속성 데이터베이스가, 두 번째 서버에는 속성 데이터베이스가 포함됩니다. 세 번째 서버에는 크롤링 데이터베이스 2개가, 네 번째 서버에는 크롤링 데이터베이스 하나와 SharePoint 데이터베이스가 포함되어 있습니다. 저장소 볼륨은 테스트에 사용할 수 있는 기존 하드웨어를 최적화하도록 작성되었습니다.
| 데이터베이스 서버 | 검색 관리, 속성 및 SharePoint 데이터베이스 | 크롤링 데이터베이스 |
|---|---|---|
프로세서 |
2px4c@3.2GHz |
4px2c@2.19GHz |
RAM |
32GB |
16GB |
운영 체제 |
Windows Server 2008 R2, 64비트 |
Windows Server 2008 R2, 64비트 |
저장소 |
2x148GB 15K SAS: RAID1: OS 2x148GB 15K SAS: RAID1: TEMP Log 2x450GB 15K SAS: RAID1: TEMP DB 6x450GB 15K SAS: RAID10: Property DB 2x450GB 15K SAS: RAID1:Search Admin, SharePoint DBs 2x450GB 15K SAS: RAID1:Logs |
2x148GB 15K SAS: RAID1: OS 2x148GB 15K SAS: RAID1: TEMP Log 2x300GB 15K SAS: RAID1: TEMP DB 6x146GB 15K SAS: RAID10: Crawl DB1 6x146GB 15K SAS: RAID10: Crawl DB2 2x300GB 15K SAS: RAID1: Crawl DB Log1 2x300GB 15K SAS: RAID1: Crawl DB Log2 |
NIC 수 |
2 |
2 |
NIC 속도 |
1기가비트 |
1기가비트 |
인증 |
NTLM |
NTLM |
소프트웨어 버전 |
SQL Server 2008 Enterprise |
SQL Server 2008 Enterprise |
쿼리 성능 데이터
아래 수치는 인덱스에 포함된 1억 3백만 개의 항목에서 측정한 것입니다. 각 열에는 특정 테스트 중에 측정된 값이 나와 있으며, 결과는 표의 맨 아래에 나와 있습니다. 측정값은 다음과 같이 설명됩니다.
쿼리 대기 시간 이러한 값은 쿼리 대기 시간 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 표준 쿼리 집합을 단일 사용자로 제출한 다음 결과 대기 시간을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
쿼리 처리량 이러한 값은 쿼리 처리량 테스트 중에 측정된 것입니다. 이 테스트에서는 테스트 도구가 팜에 대해 표준 쿼리 집합을 점점 증가하는 동시 사용자 수(최대 120명)로 제출한 다음 결과 대기 시간 및 처리량을 측정했습니다. 테스트 중에 크롤링은 수행되지 않았습니다.
| 성과 기록표 메트릭 | 쿼리 처리량 | |
|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU(속성 데이터베이스 서버) |
34% |
평균 프런트 엔드 웹 서버 CPU |
45% |
|
평균 쿼리 서버 CPU |
20% |
|
안정성 |
오류율 |
0% |
프런트 엔드 웹 서버 작동 중단 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
|
SQL Server (속성 데이터베이스 서버) |
캐시 적중률(SQL Server) |
100% |
SQL Server 잠금: 평균 대기 시간(밀리초) |
0 |
|
SQL Server 잠금: 잠금 대기 시간(밀리초) |
0 |
|
SQL Server 잠금: 초당 교착 상태 |
0 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
1.401 |
|
초당 SQL Server 컴파일 |
73.349 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일 |
0.006 |
|
읽기/쓰기 속도(데이터베이스당 IO) |
0.81 |
|
평균 디스크 큐 길이(SQL Server) |
0.037 |
|
디스크 큐 길이: 쓰기(SQL Server) |
0.003 |
|
|
초당 디스크 읽기(SQL Server) |
9.88 |
초당 디스크 쓰기(SQL Server) |
354.1 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(쿼리 서버) |
0.002 |
디스크 큐 길이: 쓰기(쿼리 서버) |
0.002 |
|
초당 디스크 읽기(쿼리 서버) |
0.035 |
|
초당 디스크 쓰기(쿼리 서버) |
6.575 |
|
평균 메모리 사용량(쿼리 서버) |
6.548% |
|
최대 메모리 사용량(쿼리 서버) |
6.601% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
0 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
18.081% |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
19.983% |
|
테스트 결과 |
성공 횟수 |
10,925 |
오류 횟수 |
0 |
|
쿼리 UI 대기 시간(75번째 백분위수) |
3.431초 |
|
쿼리 UI 대기 시간(95번째 백분위수) |
3.512초 |
|
쿼리 처리량 |
초당 36.42개 요청 |
크롤링 성능 데이터
다음 값은 지정된 콘텐츠 원본에 대한 초기 순차 전체 크롤링 중에 측정한 것입니다. 콘텐츠 크기는 항목 1백만 개 단위로 지정됩니다. 각 열에는 특정 크롤링 중에 측정된 값이 나와 있으며, 결과는 표의 맨 아래에 나와 있습니다.
| 성과 기록표 메트릭 | SharePoint 콘텐츠(3,500만 개) | 파일 공유(1백만 개) | |
|---|---|---|---|
CPU 메트릭 |
평균 SQL Server CPU(크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
15.74%, 해당 없음 |
24%, 6.6% |
최대 SQL Server CPU(크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
100%, 해당 없음 |
100%, 45% |
|
평균 인덱서 CPU |
44% |
49% |
|
안정성 |
오류율 |
0.0% |
0.00% |
프런트 엔드 웹 서버 작동 중단 |
0 |
0 |
|
응용 프로그램 서버 작동 중단 |
0 |
0 |
|
SQL Server (크롤링 데이터베이스 서버, 속성 데이터베이스 서버) |
캐시 적중률(SQL Server) |
99.8%, 해당 없음 |
99.797%, 99.49% |
SQL Server 잠금: 평균 대기 시간(밀리초) |
734.916, 해당 없음 |
1,165, 5.866 |
|
SQL Server 잠금: 최대 대기 시간(밀리초) |
15,335, 해당 없음 |
28,683, 210.5 |
|
SQL Server 잠금: 평균 잠금 대기 시간(밀리초) |
108.98, 해당 없음 |
847.72, 5.325 |
|
SQL Server 잠금: 최대 잠금 대기 시간(밀리초) |
17,236.96, 해당 없음 |
124,353, 12,920 |
|
SQL Server 잠금: 초당 교착 상태 |
0, 해당 없음 |
.012, 0 |
|
SQL Server 래치: 평균 대기 시간(밀리초) |
1.4, 해당 없음 |
2.233, 40.6 |
|
SQL Server 래치: 최대 대기 시간(밀리초) |
1,606, 해당 없음 |
917.8, 1,895 |
|
초당 SQL Server 컴파일: 평균 |
24.28, 해당 없음 |
72.7, 11.39 |
|
초당 SQL Server 컴파일: 최대 |
416, 해당 없음 |
460, 76.62 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일: 평균 |
0.560, 해당 없음 |
0.295, .099 |
|
SQL Server 통계: 초당 SQL Server 다시 컴파일: 최대 |
0.24, 해당 없음 |
17.50, 17.393 |
|
읽기/쓰기 속도(데이터베이스당 IO): 최대 |
20.3, 해당 없음 |
1.18/.214 |
|
평균 디스크 큐 길이(SQL Server) |
90.113, 해당 없음 |
138.64, 27.478 |
|
최대 디스크 큐 길이(SQL Server) |
3,179, 해당 없음 |
2,783.543, 847.574 |
|
디스크 큐 길이: 쓰기(SQL Server): 평균 |
86.93, 해당 없음 |
130,853, 26.086 |
|
디스크 큐 길이: 쓰기(SQL Server): 최대 |
1,882, 해당 없음 |
2,781.197, 884.801 |
|
|
초당 디스크 읽기(SQL Server): 평균 |
99, 해당 없음 |
147.462, 159.159 |
초당 디스크 읽기(SQL Server): 최대 |
3,772, 해당 없음 |
2,403.336, 896.462 |
|
초당 디스크 쓰기(SQL Server): 평균 |
373, 해당 없음 |
475.886, 539.497 |
|
초당 디스크 쓰기(SQL Server): 최대 |
18,522, 해당 없음 |
2,031.888, 4,174.271 |
|
응용 프로그램 서버 |
평균 디스크 큐 길이(크롤링 서버) |
0.075 |
.063 |
디스크 큐 길이: 쓰기(크롤링 서버) |
0.046 |
0.053 |
|
초당 디스크 읽기(크롤링 서버) |
1.958 |
1.693 |
|
초당 디스크 쓰기(크롤링 서버) |
62.33 |
101.093 |
|
평균 메모리 사용량(크롤링 서버) |
59% |
56.38% |
|
최대 메모리 사용량(크롤링 서버) |
70% |
58.93% |
|
프런트 엔드 웹 서버 |
대기된 ASP.NET 요청(모든 프런트 엔드 웹 서버의 평균) |
해당 없음 |
해당 없음 |
평균 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
|
최대 메모리 사용량(프런트 엔드 웹 서버) |
해당 없음 |
해당 없음 |
|
테스트 결과 |
성공 횟수 |
1,909,739 |
1,247,838 |
오류 횟수 |
9,361 |
331 |
|
포털 크롤링 속도(초당 항목) |
70.3 |
131.44 |
|
앵커 크롤링 속도 |
764 |
525.84 |
|
총 크롤링 속도(초당 항목) |
64 |
105 |
권장 사항 및 문제 해결
다음 섹션에서는 이러한 시나리오와 비슷한 환경을 배포하는 데 필요한 하드웨어, 토폴로지 및 구성을 결정하는 방법과, 적절한 용량 및 성능 특성을 유지하도록 환경을 최적화하는 방법을 결정하기 위한 권장 사항을 제공합니다.
권장 사항
이 섹션에서는 적절한 용량 및 성능 특성에 대해 환경을 최적화하기 위해 수행할 수 있는 특정 작업에 대해 설명합니다.
하드웨어 권장 사항
전체 최소 및 권장 시스템 요구 사항에 대한 구체적인 정보는 하드웨어 및 소프트웨어 요구 사항(SharePoint Server 2010)을 참조하십시오. 검색에 사용된 서버의 요구 사항이 전체 시스템 요구 사항보다 우선적으로 적용됩니다. 성능 목표를 달성하려면 아래에 나와 있는 RAM, 프로세스 및 IOPS 권장 지침을 따르십시오.
검색 크기
이 섹션에서는 구성 요소별 검색 시스템 및 크기 요구 사항/지침에 대해 설명합니다.
SharePoint Server 2010은 다양한 방식으로 배포 및 구성할 수 있으므로, 지정된 서버가 지원할 수 있는 사용자 또는 항목 수를 간단하게 측정할 수 있는 방법은 없습니다. 따라서 프로덕션 환경에서 SharePoint Server 2010을 배포하기 전에 작업 환경에서 테스트를 직접 수행해 보십시오.
검색 쿼리 시스템
이 섹션에서는 지정된 Search Service 응용 프로그램의 검색 쿼리 시스템 구성 요소를 보여 줍니다. 각 구성 요소의 크기 요구 사항은 아래 다이어그램 다음의 확장 세부 정보 표에 나와 있습니다.
.gif "검색 쿼리 시스템")
개체 설명
다음 목록에는 위 다이어그램의 검색 쿼리 시스템 개체 정의가 나와 있습니다.
검색 프록시 이 Search Service 응용 프로그램의 검색 기능을 사용하는 팜에 설치된 Search Service 응용 프로그램 프록시로, Search Service 응용 프로그램 프록시와 연결된 웹 응용 프로그램의 컨텍스트에서 실행됩니다.
검색 쿼리 및 사이트 설정 서비스 쿼리 프로세서라고도 합니다. 쿼리 프로세서는 Search Service 응용 프로그램 프록시 연결에서 쿼리를 받아 다음을 수행합니다.
각 인덱스 파티션의 액티브 쿼리 구성 요소 하나로 쿼리를 보냅니다. 속성 데이터베이스로 쿼리를 보내거나 쿼리에 따라서는 둘 다로 보내기도 합니다.
최상의 선택을 검색하고 중복 항목을 제거하여 결과 집합을 가져옵니다.
검색 관리 데이터베이스의 보안 설명자를 기반으로 결과를 보안 조정합니다.
속성 데이터베이스에서 최종 결과 집합의 메타데이터를 검색합니다.
쿼리 결과를 다시 프록시로 보냅니다.
인덱스 파티션 전체 텍스트 인덱스의 하위 집합을 나타내는 쿼리 구성 요소의 논리적 그룹입니다. 인덱스 파티션을 합하면 전체 텍스트 인덱스가 됩니다. 그러나 쿼리 구성 요소는 실제 인덱스 하위 집합을 포함합니다. 인덱스 파티션은 속성 데이터베이스 하나와 연결됩니다.
검색 쿼리 구성 요소 쿼리 구성 요소는 전체 텍스트 인덱스를 전체 또는 일부분 포함합니다. 쿼리 프로세서에서 쿼리하는 경우 쿼리 구성 요소는 해당 인덱스에서 최상의 결과를 결정하여 해당 항목을 보냅니다. 쿼리 구성 요소는 다음 중 하나로 만들 수 있습니다.
액티브 쿼리 구성 요소: 기본적으로 쿼리에 응답합니다. 동일한 인덱스 파티션에 대해 여러 액티브 쿼리 구성 요소를 여러 개 추가하면 처리량이 증가합니다.
장애 조치(failover) 쿼리 구성 요소: 동일한 인덱스 파티션의 모든 액티브 구성 요소에 오류가 발생한 경우에만 쿼리에 응답합니다.
검색 관리 데이터베이스 Search Service 응용 프로그램과 동시에 작성되는 검색 관리 데이터베이스는 관리에 사용되는 응용 프로그램 설정을 비롯하여, 최상의 결과와 같은 쿼리에 사용되는 Search Service 응용 프로그램 차원 데이터와 보안 설명자를 포함합니다.
속성 데이터베이스 인덱스의 항목에 대한 메타데이터(제목, 작성자, 관련 필드)를 포함합니다. 속성 데이터베이스는 최종 결과를 표시하는 데 필요한 메타데이터를 검색하는 것 외에, 속성 기반 쿼리에도 사용됩니다. 여러 인덱스 파티션이 있는 경우에는 인덱스 파티션을 서로 다른 여러 속성 데이터베이스에 매핑할 수 있습니다.
확장 세부 정보
| 개체 | 확장 고려 사항 | RAM | IOPS(읽기/쓰기) |
|---|---|---|---|
검색 프록시 |
연결된 프런트 엔드 웹 서버와 함께 확장됩니다. |
해당 없음 |
해당 없음 |
검색 쿼리 및 사이트 설정 서비스 |
이 서비스는 중앙 관리의 서버 제공 서비스 페이지에서 설치하며, 쿼리 구성 요소가 있는 각 서버에서 시작해야 합니다. 쿼리 구성 요소가 포함된 서버의 RAM을 사용하지 않도록 이 서비스를 별도의 서버로 이동할 수 있습니다(가용성을 높이려면 쌍으로 이동). 또한 사용자 지정 보안 트리머(영문일 수 있음)를 사용하는 경우에는 CPU 및 RAM 리소스에 영향을 줄 수 있습니다. |
인덱스의 보안 설명자를 캐시하기 위해 RAM(프로세스 캐시)을 사용합니다. |
해당 없음 |
인덱스 파티션 |
인덱스 파티션 수를 늘리면 인덱스 파티션의 항목 수가 감소하고, 그러면 인덱스 파티션에 할당된 쿼리 구성 요소를 호스팅하는 쿼리 서버에 필요한 RAM 및 디스크 공간이 줄어듭니다. |
해당 없음 |
해당 없음 |
쿼리 구성 요소 |
서버의 각 액티브 쿼리 구성 요소는 쿼리를 처리할 때 메모리를 사용하며, Search Service 응용 프로그램 토폴로지의 일부분으로 작성 또는 수정됩니다. 액티브 구성 요소와 장애 조치(failover) 구성 요소는 모두 크롤링 수행 시 IO를 사용합니다. RAM 및 IO 요구 사항이 충족되었다는 가정하에 서버를 쿼리 구성 요소 전용으로 지정할 수 있습니다(예: 같은 서버에 액티브 구성 요소와 장애 조치 구성 요소를 각각 두 개씩 배치). 가능한 경우 서버당 액티브 구성 요소별로 전용 CPU 코어를 2개 이상, 그리고 서버당 장애 조치(failover) 구성 요소별로 CPU 코어를 하나 이상 지정하십시오. |
응용 프로그램 서버에 있는 각 액티브 쿼리 구성 요소의 경우 해당 인덱스의 33%는 RAM(운영 체제 캐시)에 있어야 합니다. |
지정된 서버의 쿼리 구성 요소 쌍당 2K가 필요합니다. 쿼리 구성 요소가 다음 작업을 수행하려면 IO가 필요합니다. 쿼리용으로 RAM에 인덱스 로드 각 크롤링 구성 요소에서 받은 인덱스 조각 쓰기 인덱스 조각을 해당 인덱스로 병합(예: 마스터 병합 중에) |
검색 관리 데이터베이스 |
각 쿼리에 대해 최상의 선택 및 보안 설명자가 검색 관리 데이터베이스에서 로드됩니다. 캐시에서 이러한 항목을 제공할 수 있도록 데이터베이스 서버에 RAM이 충분한지 확인하십시오. 크롤링 데이터베이스는 해당 데이터베이스 서버의 캐시를 다시 설정하는 경향이 있으므로, 가능한 경우 검색 관리 데이터베이스를 크롤링 데이터베이스가 있는 서버에 배치하지 마십시오. |
RAM에 중요 테이블(MSSSecurityDescriptors)을 저장할 수 있도록 데이터베이스 서버에 RAM이 충분한지 확인합니다. |
700 |
속성 데이터베이스 |
각 쿼리에 대해 문서 결과를 가져오기 위해 속성 데이터베이스에서 메타데이터를 검색하므로, 성능을 개선하기 위해 데이터베이스 서버에 RAM을 추가할 수 있습니다. 인덱스 파티션이 여러 개인 경우에는 속성 데이터베이스를 분할하여 다른 데이터베이스 서버로 이동하면 RAM 및 IO 요구 사항을 낮출 수 있습니다. |
중요 테이블(MSSDocSDIDs + MSSDocProps + MSSDocresults)의 33%를 캐시에 저장할 수 있도록 데이터베이스 서버에 RAM이 충분한지 확인합니다. |
2 K 30% 읽기, 70% 쓰기 |
검색 크롤링 시스템
이 섹션에서는 검색 크롤링 시스템의 구성 요소를 보여 줍니다. 각 구성 요소의 크기 요구 사항은 다이어그램 아래의 표에 나와 있습니다.
.gif "검색 크롤링 시스템")
개체 설명
이 섹션에는 위 다이어그램의 검색 크롤링 시스템 개체 정의가 나와 있습니다.
관리 구성 요소 크롤링을 시작할 때와 크롤링 시스템에서 관리 작업을 수행할 때 관리 구성 요소를 사용합니다.
크롤링 구성 요소 크롤링을 처리하고, 결과로 생성된 인덱스 조각 파일을 쿼리 구성 요소로 전파하고, 위치에 대한 정보를 추가하여 콘텐츠 원본의 일정을 연결된 해당 크롤링 데이터베이스에 대해 크롤링합니다.
검색 관리 데이터베이스 검색 관리 데이터베이스는 Search Service 응용 프로그램과 동시에 작성되며, 크롤링 중에 검색된 보안 설명자와 관리에 사용되는 응용 프로그램 설정을 저장합니다.
크롤링 데이터베이스 콘텐츠 원본의 위치와 관련된 데이터, 크롤링 일정 그리고 크롤링 작업에 대한 그 밖의 정보를 포함합니다. 호스트 배포 규칙을 만들어 크롤링 데이터베이스를 특정 호스트 전용으로 지정할 수 있습니다. 이 데이터베이스에는 데이터만 저장되며, 지정된 크롤링 데이터베이스와 연결된 크롤링 구성 요소가 크롤링을 수행합니다.
검색 쿼리 시스템
확장 세부 정보
| 개체 | 확장 고려 사항 | RAM | IOPS(선택적으로 읽기/쓰기 비율) |
|---|---|---|---|
관리 구성 요소 |
단일 관리 구성 요소는 확장할 수 없습니다. 기본적으로 관리 구성 요소는 크롤링 구성 요소를 호스팅하는 서버 및 중앙 관리(소규모 팜)에 있습니다. |
최소 |
최소 |
크롤링 구성 요소 |
크롤링 구성 요소는 CPU 대역폭을 많이 사용합니다. 지정된 크롤링 구성 요소가 CPU 코어 4개를 사용하는 것이 최적이며, RAM은 CPU만큼 중요하지는 않습니다. 대규모 팜에서는 크롤링 구성 요소 호스팅 전용 서버를 지정하면 다른 구성 요소에 대한 크롤러의 영향을 최소화할 수 있습니다(특히 중복성이 요구되는 경우 다른 크롤링 데이터베이스에 연결된 크롤링 구성 요소를 사용할 때). |
중간. 동아시아어로 된 문서를 크롤링할 때는 단어 분리기 때문에 RAM 요구 사항이 높아집니다. |
300-400 |
검색 관리 데이터베이스 |
위의 검색 쿼리 시스템 부분을 참조하십시오. 크롤링 데이터베이스는 해당 데이터베이스 서버의 캐시를 다시 설정하는 경향이 있으므로, 가능한 경우 검색 관리 데이터베이스를 크롤링 데이터베이스가 있는 서버에 배치하지 마십시오. |
위의 검색 쿼리 시스템 부분을 참조하십시오. |
700 |
크롤링 데이터베이스 |
크롤링 데이터베이스는 IO 대역폭을 많이 사용합니다(RAM은 IO만큼 중요하지는 않음). 크롤링 데이터베이스에서 크롤링 작업을 수행하려면 3.5K IOPS가 필요하며, 사용 가능한 대역폭에 따라서는 6K IOPS까지 사용할 수 있습니다. |
보통 |
3.5-7K 73% 읽기, 27% 쓰기 |
저장소 크기 계산
다음 요인을 계산하면 저장소 요구 사항을 예측할 수 있습니다. 크기 요인은 기본적으로 SharePoint 콘텐츠를 포함하는 인덱스가 있는 내부 사전 배포 시스템을 기반으로 합니다(콘텐츠 데이터베이스의 크기는 13.3TB). 전체적으로 볼 때 SharePoint 검색에는 콘텐츠 데이터베이스 디스크 공간의 약 20%가 필요했습니다. 앞서 설명한 것처럼, 프로덕션 환경에 SharePoint Server 2010을 배포하기 전에 작업 환경에서 테스트를 직접 수행해 봐야 합니다.
경고:
이러한 수치를 계산하는 데 사용된 콘텐츠 모음은 기본적으로 영어로 된 SharePoint 콘텐츠이므로, 실제로 사용하는 콘텐츠가 이와 다른 경우(예: 대부분 파일 공유 또는 SharePoint가 아닌 HTTP 사이트로 구성된 경우) 수치가 좀 더 달라질 수 있습니다.
콘텐츠는 주로 SharePoint 콘텐츠이지만 다음과 같은 상황에서는 계수를 조정할 수 있습니다.
문서 저장소가 여러 개인 경우 계수는 훨씬 커집니다.
콘텐츠가 주로 이미지인 경우에는 계수를 줄일 수 있습니다.
콘텐츠가 다른 언어로 되어 있는 경우 계수에 영향을 줄 수 있습니다.
1. 콘텐츠 데이터베이스 크기 요인 계산(ContentDBSum)
크롤링할 SharePoint 콘텐츠 데이터베이스의 합을 계산합니다. 이 값은 다음 저장소 계산에서 상관 관계로 사용할 ContentDBSum 값입니다.
2. 인덱스 관련 크기 계산(TotalIndexSize 및 QueryComponentIndexSize)
쿼리 구성 요소에 있으며 전체 텍스트 쿼리에 사용되는 총 인덱스의 크기를 계산합니다.
ContentDBSum에 .035를 곱합니다. 이 계산의 결과가 분할 후 병합 및 다시 분할용 공간을 예약하기 전의 TotalIndexSize입니다.
다음으로 시나리오의 기준으로 사용할 인덱스 파티션의 수를 결정합니다. 일반적으로 인덱스 파티션 하나에는 항목이 5백만~1천만 개가 포함됩니다. 인덱스 파티션의 수를 결정한 후에는 쿼리 구성 요소 저장소의 크기를 계산할 수 있습니다.
TotalIndexSize를 (인덱스 파티션 수)로 나눕니다. 이 계산의 결과가 다음 크기를 계산하는 데 사용되는 QueryComponentIndexSize입니다.
RAM의 경우 QueryComponentIndexSize에 0.33을 곱합니다. 이 계산의 결과가 이 쿼리 구성 요소(액티브 구성 요소인 경우)에 필요한 최소 RAM입니다.
장애 조치(failover) 구성 요소의 경우에는 액티브 구성 요소가 될 때까지 RAM이 필요하지 않습니다.
지정된 서버에 대해 같은 서버에 액티브 쿼리 구성 요소가 여러 개 있는 경우, 해당 서버의 RAM 요구 사항을 계산하려면 각 액티브 쿼리 구성 요소의 RAM을 모두 더해야 합니다.
디스크 저장소의 경우 인덱스를 분할할지 여부에 따라 QueryComponentIndexSize를 다음과 같은 방식으로 사용하여 디스크 요구 사항을 예상합니다. 즉, 파티션 경계당 항목이 1천만 개가 넘도록 인덱스가 확장될 수 있습니다.
인덱스 병합용 공간을 확보하려면 QueryComponentIndexSize에 3을 곱하여 단일 쿼리 구성 요소의 디스크 저장소 크기를 계산합니다.
인덱스 다시 분할용 공간을 확보하려면 QueryComponentIndexSize에 4를 곱하여 단일 쿼리 구성 요소의 디스크 저장소 크기를 계산합니다.
지정된 서버에 대해 동일한 서버에 쿼리 구성 요소가 여러 개 있으면 이 문서 앞부분의 "검색 쿼리 시스템" 섹션에서 "확장 세부 정보" 섹션에 지정되어 있는 IOPS 요구 사항에 따라 각 쿼리 구성 요소용으로 저장소를 마련해야 합니다.
3. 속성 데이터베이스 크기 계산
다음과 같은 방식으로 속성 데이터베이스의 크기를 계산합니다.
ContentDBSum에 .015를 곱합니다. 이 계산의 값이 분할 전의 TotalPropertyDBSize입니다.
ContentDBSum에 .0031을 곱합니다. 이 계산의 값이 분할 전의 TotalPropertyDBLogSize입니다. 이 계산에서는 SQL Server 데이터베이스에 대해 단순 복구 모델을 사용한다고 가정합니다.
ContentDBSum에 .00034를 곱합니다. 이 계산의 값이 속성 데이터베이스 TempDBSize입니다. 속성 데이터베이스의 키 테이블 중 33%는 RAM에 저장하는 것이 좋으므로, 임시 데이터베이스는 많이 사용되지 않습니다.
다음으로, 시나리오에 따라 사용할 속성 데이터베이스의 수를 결정합니다. 일반적으로는 쿼리 성능 문제가 없으며 관리되는 속성 수가 제한된다고 가정할 때(표준 구성) 속성 데이터베이스당 항목을 5천만 개까지 포함할 수 있습니다.
TotalPropertyDBSize를 (속성 데이터베이스의 수)로 나눕니다. 이 계산의 결과가 PropertyDatabaseSize입니다.
TotalPropertyDBLogSize를 (속성 데이터베이스의 수)로 나눕니다. 이 계산의 결과가 PropertyDatabaseLogSize입니다.
RAM의 경우 PropertyDatabaseSize에 0.33을 곱합니다. 이 계산의 결과가 이 속성 데이터베이스의 권장 최소 RAM입니다.
지정된 데이터베이스 서버에 대해 동일한 서버에 속성 데이터베이스가 여러 개 있으면 이 문서 앞부분의 "검색 쿼리 시스템" 섹션에서 "확장 세부 정보" 섹션에 지정되어 있는 IOPS 요구 사항에 따라 각 속성 데이터베이스용으로 저장소 및 RAM을 마련해야 합니다.
4. 크롤링 데이터베이스 크기 계산
다음으로는 크롤링 데이터베이스에 필요한 크기를 다음과 같은 방식으로 계산합니다.
ContentDBSum에 0.046을 곱합니다. 이 계산의 값이 분할 전의 TotalCrawlDBSize입니다.
ContentDBSum에 0.011을 곱합니다. 이 계산의 값이 분할 전의 TotalCrawlDBLogSize입니다. 이 계산에서는 SQL Server 데이터베이스에 대해 단순 복구 모델을 사용한다고 가정합니다.
ContentDBSum에 0.0011을 곱합니다. 이 계산의 결과가 크롤링 데이터베이스 TempDBSize입니다. 검색 크롤링 시스템은 임시 데이터베이스의 성능에 영향을 주므로, 크롤링 데이터베이스 또는 이러한 사용 방식으로 인해 영향을 받는 데이터베이스를 호스팅하는 서버에는 다른 데이터베이스를 배치하지 않는 것이 좋습니다.
다음으로, 시나리오에 따라 사용할 크롤링 데이터베이스의 수를 결정합니다. 일반적으로는 크롤링 성능 문제가 없다고 가정할 때 크롤링 데이터베이스당 항목을 2천 5백만 개까지 포함할 수 있습니다.
TotalCrawlDBSize를 (크롤링 데이터베이스의 수)로 나눕니다. 이 계산의 결과가 CrawlDatabaseSize입니다.
TotalCrawlDBLogSize를 (크롤링 데이터베이스의 수)로 나눕니다. 이 계산의 결과가 CrawlDatabaseLogSize입니다.
지정된 데이터베이스 서버에 대해 동일한 서버에 크롤링 데이터베이스가 여러 개 있으면 이 문서 앞부분의 "검색 크롤링 시스템" 섹션에서 "확장 세부 정보" 섹션에 지정되어 있는 IOPS 요구 사항에 따라 각 크롤링 데이터베이스용으로 저장소를 마련해야 합니다. RAM의 경우 데이터베이스 크롤링 전용 데이터베이스 서버의 RAM이 16GB 이상인 것이 좋습니다.
5. 검색 관리 데이터베이스 크기 계산
검색 관리 데이터베이스의 크기를 다음과 같은 방식으로 계산합니다(Windows 인증을 사용한다고 가정함).
인덱스의 항목 수(1백만 개 단위)에 0.3을 곱합니다. 이 계산의 결과가 SearchAdminDBSize입니다.
RAM의 경우 SearchAdminDBSize에 0.33을 곱합니다. 이 계산의 결과가 이 검색 관리 데이터베이스의 권장 최소 RAM입니다.
지정된 데이터베이스 서버에 대해 동일한 서버에 데이터베이스가 여러 개 있으면 이 문서 앞부분의 "검색 쿼리 시스템" 섹션에서 "확장 세부 정보" 섹션에 지정되어 있는 IOPS 요구 사항에 따라 각 데이터베이스용으로 저장소 및 RAM을 마련해야 합니다.
선택 사항: 백업 크기 계산
단일 Search Service 응용 프로그램을 백업하는 데 필요한 디스크 공간을 결정하려면 다음 계산을 수행합니다.
- TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = 기본 백업 크기
이 기본 백업 크기를 기준으로 사용하면 됩니다. 다음 항목도 이 크기에 영향을 줍니다.
마지막 마스터 병합 이후 수행된 크롤링에 대해 TotalIndexSize에 포함된 추가 인덱스 크기
추가 항목, 쿼리 및 보안 설명자로 인한 시간에 따른 증가
또한 다음 백업용으로 공간을 예약해 두는 것 외에 서로 다른 시점의 여러 백업을 보관할 수도 있습니다.
크기 지정 연습
아래에는 주로 SharePoint 콘텐츠에 대한 쿼리를 처리하는 팜(항목 1억 개)에 대해 앞서 설명한 크기 요인을 사용하여 크기를 지정하는 연습이 나와 있습니다. 대규모 팜 시나리오를 사용하는 경우 다음을 가정할 수 있습니다.
1억 개의 항목을 포함하기 위해 논리 인덱스 파티션 10개가 필요합니다.
쿼리를 저장하려면 액티브 쿼리 구성 요소 10개(인덱스 파티션당 하나)가 필요합니다.
쿼리 중복성이 반드시 필요하므로 장애 조치(failover) 쿼리 구성 요소도 인덱스 파티션당 하나씩 총 10개가 필요합니다(액티브 구성 요소와 다른 서버에 배치됨).
저장소 및 RAM 요구 사항을 확인하려면 다음 단계를 수행합니다.
콘텐츠 데이터베이스가 여러 개인 SharePoint 콘텐츠 팜에서 크롤링할 콘텐츠 데이터베이스를 추가하여 20TB를 만듭니다.
위의 인덱스 계수를 사용하여 20TB에 0.035(인덱스 계수)를 곱해 716.8GB를 만듭니다. 이 값이 TotalIndexSize입니다. 파티션이 하나뿐인 경우에는 이 값이 인덱스의 크기가 됩니다.
TotalIndexSize를 파티션 수로 나눕니다(716.8GB/71.68GB). 이 계산의 결과가 인덱스 파티션이 하나인 경우 쿼리 구성 요소당 필요한 인덱스 크기(QueryComponentIndexSize)입니다. 액티브 쿼리 구성 요소나 장애 조치(failover) 쿼리 구성 요소에 대해 크기는 동일합니다.
다시 분할을 수행하려는 경우 TotalIndexSize에 4를 곱하고, 그렇지 않으면 3을 곱하여 마스터 병합을 지원합니다(71.68GB * 4 = 286.72GB). 즉, 쿼리 구성 요소 하나를 지원하려면 쿼리 서버 디스크에 286.72GB의 사용 가능한 공간이 필요합니다. 대규모 팜 시나리오에서 권장했던 액티브/장애 조치(failover) 토폴로지에서와 같이 동일한 응용 프로그램 서버에 쿼리 구성 요소가 두 개 있는 경우의 디스크 드라이브 레이아웃은 다음과 같습니다.
운영 체제 드라이브(표준 크기)
추가 저장 시스템 1: 인덱스 파티션 1의 액티브 쿼리 구성 요소에 사용되는 Query Component1_Share(크기 = 300GB 이상)
추가 저장 시스템 2: 인덱스 파티션 2의 장애 조치(failover)(미러링) 쿼리 구성 요소에 사용되는 Query Component2_Share(크기 = 300GB 이상)
참고
액티브 쿼리 구성 요소가 하나 있는 이 응용 프로그램 서버에서 대부분의 쿼리를 캐시하려면 최소 71.68GB * 0.33 = 23.65GB RAM + 3GB RAM(운영 체제용)이 필요합니다. 여기서는 32GB를 사용합니다.
소프트웨어 제한
아래 표에는 적절한 검색 환경을 지원하기 위해 적용되는 소프트웨어 경계가 나와 있습니다.
| 개체 | 제한 | 추가 참고 사항 |
|---|---|---|
SharePoint Search Service 응용 프로그램 |
팜당 권장 개수는 최대 20개입니다. 총 서비스 응용 프로그램의 절대 최대값은 256개입니다. |
검색 구성 요소 및 데이터베이스는 각각 별도의 서버에 할당할 수 있으므로, 동일한 팜에 여러 Search Service 응용 프로그램을 배포할 수 있습니다. |
인덱싱된 문서 |
전체 권장 항목 수는 인덱스 파티션당 최대 1천만 개, Search Service 응용 프로그램당 1억 개입니다. |
SharePoint Search에서 지원하는 각 인덱스 파티션에는 전체 검색 인덱스의 하위 집합이 포함됩니다. 권장되는 최대 제한은 지정된 파티션에서 1천만 개의 항목입니다. 권장되는 전체 최대 항목 수(사용자, 목록 항목, 문서, 웹 페이지 포함)는 1억 개입니다. |
인덱스 파티션 |
권장 개수는 Search Service 응용 프로그램당 최대 20개입니다. |
이 인덱스 파티션은 Search Service 응용 프로그램 인덱스의 논리적 하위 집합으로, 권장 제한은 20개입니다. 인덱스 파티션 수를 늘리면 인덱스 파티션의 항목 수가 줄어들며, 인덱스 파티션에 할당된 쿼리 구성 요소를 호스팅하는 쿼리 서버에 필요한 RAM 및 디스크 공간이 감소합니다. 그러나 이렇게 하면 인덱스 파티션의 항목 수가 적어지므로 관련성에 영향을 줄 수 있습니다. 인덱스 파티션의 하드 제한은 128개입니다. |
속성 데이터베이스 |
권장 제한은 Search Service 응용 프로그램당 10개입니다. |
속성 데이터베이스에는 해당 데이터베이스와 연결된 각 인덱스 파티션의 항목에 대한 메타데이터가 저장됩니다. 인덱스 파티션은 하나의 속성 저장소와만 연결할 수 있습니다. 권장되는 제한은 Search Service 응용 프로그램당 10개이고, 하드 제한은 255개(인덱스 파티션과 동일)입니다. |
크롤링 데이터베이스 |
제한은 응용 프로그램당 32개의 크롤링 데이터베이스입니다. |
크롤링 데이터베이스에는 크롤링된 모든 항목에 대한 크롤링 데이터(시간 및 상태 포함)가 저장됩니다. 권장 제한은 크롤링 데이터베이스당 2천 5백만 개 항목 또는 Search Service 응용 프로그램당 총 4개의 데이터베이스입니다. |
크롤링 구성 요소 |
응용 프로그램당 권장되는 제한은 총 16개의 크롤링 구성 요소이며, 크롤링 데이터베이스당 2개와 서버당 2개(서버에 프로세서(코어)가 8개 이상이라고 가정할 경우)가 할당됩니다. |
전파 I/O 성능 저하를 최소화하려면 서버당 총 크롤링 구성 요소 개수가 128/(총 쿼리 구성 요소 수)개 미만이어야 합니다. 권장되는 제한을 초과하더라도 크롤링 성능은 증가하지 않을 수 있으며, 실제로 크롤링 성능은 크롤링 서버, 데이터베이스 및 콘텐츠 호스트에서 사용 가능한 리소스에 따라 저하될 수 있습니다. |
쿼리 구성 요소 |
응용 프로그램당 권장 제한은 128개이며, 서버당 64/(총 크롤링 구성 요소)개입니다. |
쿼리 구성 요소의 총 개수는 크롤링 구성 요소에서 파일을 복사할 수 있는 기능에 따라 제한됩니다. 서버당 쿼리 구성 요소의 최대 개수는 쿼리 구성 요소가 크롤링 구성 요소로부터 전파되는 파일을 받아들일 수 있는 기능에 따라 제한됩니다. |
동시 크롤링 |
권장 제한은 Search Service 응용 프로그램당 20개 크롤링입니다. |
이 값은 동시에 수행되는 크롤링 수입니다. 크롤링은 매우 많은 비용이 드는 검색 작업으로 데이터베이스 부하뿐 아니라 기타 응용 프로그램 부하에도 영향을 줍니다. 동시 크롤링 수가 20개를 초과하면 전체 크롤링 속도가 떨어집니다. |
콘텐츠 원본 |
권장 제한은 Search Service 응용 프로그램당 50개 콘텐츠 원본입니다. |
Search Service 응용 프로그램당 하드 제한인 500개에 도달할 때까지 권장되는 제한을 초과할 수 있습니다. 그러나 이 경우 시작 주소는 이보다 적은 수를 사용해야 하며 동시 크롤링 제한을 따라야 합니다. |
시작 주소 |
권장 제한은 콘텐츠 원본당 100개의 시작 주소입니다. |
콘텐츠 원본당 하드 제한인 500개에 도달할 때까지 이 권장 제한을 초과할 수 있습니다. 그러나 콘텐츠 원본은 가능하면 적게 사용해야 합니다. 시작 주소가 많을 때는 주소를 HTML 페이지에 링크로 포함한 다음 HTTP 크롤러가 링크를 따라 페이지를 크롤링하도록 하는 것이 바람직합니다. |
크롤링 규칙 |
권장 제한은 Search Service 응용 프로그램당 최대 100개입니다. |
권장 값은 초과할 수 있지만 이 경우 검색 관리의 크롤링 규칙 표시 성능이 저하됩니다. |
크롤링 로그 |
권장 제한은 응용 프로그램당 최대 1억 개입니다. |
크롤링 로그의 개별 로그 항목 수로, 인덱싱된 문서 제한을 따릅니다. |
항목당 인식된 메타데이터 속성 |
하드 제한은 1만 개입니다. |
항목이 크롤링될 때 확인할 수 있으며, 잠재적으로 쿼리에 매핑하고 사용할 수 있는 메타데이터 속성의 수입니다. |
크롤링 속성 |
Search Service 응용 프로그램당 20만 개 |
크롤링 중에 검색되는 속성입니다. |
관리 속성 |
Search Service 응용 프로그램당 10만 개 |
검색 시스템이 쿼리에 사용하는 속성입니다. 크롤링 속성은 관리 속성에 매핑됩니다. 관리되는 속성당 최대 100개의 매핑을 사용하는 것이 좋습니다. 이 제한을 초과하면 크롤링 속도 및 쿼리 성능이 떨어질 수 있습니다. |
범위 |
권장되는 제한은 사이트당 200개입니다. |
사이트당 권장되는 제한입니다. 이 제한을 초과하면 크롤링의 효율성이 떨어질 수 있으며 표시 그룹에 범위가 추가되는 경우에는 최종 사용자의 브라우저 대기 시간에도 영향을 줍니다. 또한 범위 수가 권장되는 제한을 초과하여 증가하면 검색 관리의 범위 표시 성능이 저하됩니다. |
표시 그룹 |
사이트당 25개 |
사용자 인터페이스를 통해 그룹화된 범위를 표시하는 데 사용됩니다. 이 제한을 초과하면 검색 관리 범위 환경의 성능이 저하되기 시작합니다. |
범위 규칙 |
권장 제한은 범위당 범위 규칙 100개, Search Service 응용 프로그램당 총 600개입니다. |
이 제한을 초과하면 최신성이 떨어지며 범위가 지정된 쿼리로 인해 지연이 발생할 수 있습니다. |
키워드 |
권장 제한은 사이트 모음당 200개입니다. |
키워드당 최상의 선택이 5개인 경우의 사이트 모음당 최대 제한(ASP.NET)인 5,000개에 도달할 때까지 권장 제한을 초과할 수 있습니다. 이 제한을 초과하면 사이트 관리 인터페이스의 키워드 표시 성능이 저하됩니다. ASP.NET의 제한을 수정하려면 Web.config 및 Client.config 파일(MaxItemsInObjectGraph)을 사용하면 됩니다. |
신뢰할 수 있는 페이지 |
권장 제한은 신뢰할 수 있는 최상위 페이지 1개와 원하는 관련성을 달성하면서 사용 가능한 최소한의 두 번째 및 세 번째 수준 페이지입니다. |
하드 제한은 Search Service 응용 프로그램 하나를 기준으로 관련성 수준당 200개이지만, 페이지를 추가하면 원하는 관련성을 얻지 못할 수 있습니다. 핵심 사이트는 첫 번째 관련성 수준에 추가합니다. 후속 핵심 사이트는 두 번째 또는 세 번째 관련성 수준으로 한 번에 하나씩 추가하고, 추가할 때마다 관련성을 평가하여 원하는 관련성 효과를 달성했는지 확인합니다. |
알림 |
권장 제한은 Search Service 응용 프로그램당 최대 1백만 개입니다. |
테스트된 제한입니다. |
결과 제거 |
한 작업에서 URL 100개를 사용할 수 있습니다. |
단일 작업으로 시스템에서 제거해야 하는 최대 권장 URL 수입니다. |
최적화
다음 섹션에서는 팜 성능 개선을 위한 방법에 대해 설명합니다.
사용자 수, 사용자 작업의 유형/복잡도/빈도, 작업의 포스트백 수, 데이터 연결 성능 등 여러 요인이 성능에 영향을 줄 수 있습니다. 팜 처리량은 이러한 각 요인에 의해 크게 영향을 받을 수 있습니다. 따라서 배포를 계획할 때는 이러한 요인을 주의 깊게 고려해야 합니다.
검색 시스템의 성능 및 용량은 해당 토폴로지에 따라 크게 달라집니다. 기존 서버 컴퓨터의 용량을 눌려 수직 확장하거나, 토폴로지에 서버를 추가하여 수평 확장할 수 있습니다.
검색 쿼리 시스템 최적화
일반적으로 검색 쿼리 최적화는 다음 시나리오 중 하나를 따릅니다.
사용자가 쿼리 대기 시간에 대한 불만을 제기하여 쿼리 대기 시간을 줄여야 합니다.
검색 요청이 계획한 것보다 훨씬 많아 성능이 저하되기 시작하여 쿼리 처리량을 늘려야 합니다.
쿼리 하위 시스템을 수평 또는 수직 확장할 때는 항상 쿼리 구성 요소를 더 만들어야 합니다. 기존 쿼리 서버의 용량(RAM, IO, CPU)이 충분한 경우에는 해당 서버에 쿼리 구성 요소를 더 만들어 RAM, CPU 또는 IO를 늘려서 수직 확장할 수 있습니다. 그렇지 않은 경우에는 새 서버에 쿼리 구성 요소를 더 만들거나 기존 구성 요소를 이동하여 수평 확장할 수 있습니다.
다음 섹션에는 쿼리 리소스를 검색 쿼리 시스템에 추가하는 여러 가지 방법이 나와 있습니다.
쿼리 대기 시간을 줄이는 방법
쿼리 구성 요소를 추가하여 대기 시간 줄이기
아래 그래프에서는 인덱스 크기를 변경하지 않고 여러 서버에 액티브 쿼리 구성 요소를 추가하는 경우의 영향을 보여 줍니다.
.gif "쿼리 대기 시간에 대한 사용자 부하 영향(75백분위수)")
시스템에 대한 사용자 부하(동시 사용자 쿼리에서 측정됨)가 늘어날 때 초 단위 미만의 쿼리 대기 시간을 유지하려면 액티브 쿼리 구성 요소를 더 추가합니다.
쿼리 프로세서(쿼리 및 사이트 설정 서비스)를 추가하여 대기 시간 줄이기
아래 그래프에서는 쿼리 시스템의 다른 부분은 변경하지 않고 여러 서버에 액티브 쿼리 프로세서 서비스를 추가하는 경우의 영향을 보여 줍니다.
.gif "쿼리 대기 시간에 대한 사용자 부하 영향(75백분위수)")
시스템에 대한 사용자 부하(동시 사용자 쿼리에서 측정됨)가 늘어날 때 초 단위 미만의 쿼리 대기 시간을 유지하려면 다른 서버에서 쿼리 및 사이트 설정 서비스의 다른 활성 인스턴스를 시작합니다.
수평 확장을 통해 쿼리 처리량 늘리기
쿼리 구성 요소를 추가하여 쿼리 처리량 늘리기
아래 그래프에서는 인덱스 크기를 변경하지 않고 여러 서버에 액티브 쿼리 구성 요소를 추가하는 경우의 영향을 보여 줍니다.
.gif "쿼리 처리량에 대한 사용자 부하 영향(차이 포함)")
시스템에 대한 사용자 부하(동시 사용자 쿼리에서 측정됨)가 늘어날 때 쿼리 처리량을 늘리려면 액티브 쿼리 구성 요소를 더 추가합니다.
쿼리 프로세서(쿼리 및 사이트 설정 서비스)를 추가하여 쿼리 처리량 늘리기
아래 그래프에서는 쿼리 시스템의 다른 부분은 변경하지 않고 여러 서버에 액티브 쿼리 프로세서 서비스를 추가하는 경우의 영향을 보여 줍니다.
.gif "쿼리 처리량에 대한 사용자 부하 영향(추가분 포함)")
팁: 시스템에 대한 사용자 부하(동시 사용자 쿼리에서 측정됨)가 늘어날 때 처리량을 늘리려면 다른 서버에서 쿼리 및 사이트 설정 서비스의 다른 활성 인스턴스를 시작합니다.
검색 크롤링 시스템 최적화
일반적으로는 사용자가 원하는 검색 결과를 찾지 못하거나 검색 결과가 오래되었다는 불만을 제기하는 경우 검색 크롤링 최적화를 수행합니다.
최신성 목표 내에서 콘텐츠 원본 시작 주소를 크롤링하려는 경우 다음과 같은 크롤링 성능 문제가 발생할 수 있습니다.
검색 크롤링 하위 시스템의 IOPS 병목 현상으로 인해 크롤링 속도가 느립니다.
검색 크롤링 하위 시스템의 CPU 스레드 부족으로 인해 크롤링 속도가 느립니다.
저장소 응답이 느려 크롤링 속도가 느립니다.
이러한 각 문제에서는 크롤링 속도가 느리다고 가정합니다. 시간에 따른 시스템의 일반 크롤링 속도 기준을 설정하려면 검색 관리 보고서 사용(SharePoint Server 2010)(소프트웨어 수명 주기 단계가 지정됨)을 참조하십시오. 이 기준을 벗어나는 경우에 대비해 아래의 하위 섹션에서는 위의 크롤링 성능 문제를 해결할 수 있는 다양한 방식을 설명합니다.
크롤링 IOPS 병목 현상
크롤링 데이터베이스 또는 속성 데이터베이스로 인해 병목 현상이 발생함을 파악한 후에는 적절한 해결 방법을 통해 그러한 현상을 해결할 수 있도록 크롤링 시스템을 수직 또는 수평으로 확장해야 합니다. 아래 표에는 IOPS를 추가함에 따라 크롤링 속도가 어느 정도 빨라지는지를 보여 줍니다(구성 요소가 많아져서 다시 병목 현상이 발생할 때까지).
팁: 크롤링 데이터베이스에서 병목 현상이 발생하지 않는지 항상 확인하십시오. 크롤링 데이터베이스 IOPS에서 이미 병목 현상이 발생한 경우에는 크롤링 구성 요소를 추가하거나 스레드 수를 늘려도 도움이 되지 않습니다.
| 토폴로지 (크롤링 구성 요소/ 크롤링 데이터베이스) | CPU 비율 | RAM: 버퍼 캐시 적중률 | 읽기 대기 시간 | 쓰기 대기 시간 | 크롤링 속도(초당 문서) |
|---|---|---|---|---|---|
2/1 데이터베이스 |
19.5 |
99.6 |
142ms |
73ms |
50 |
4/2 데이터베이스 |
8.502 |
99.55 |
45ms |
75ms |
~75 |
6/2 데이터베이스 |
22 |
99.92 |
55ms |
1050ms |
~75 |
크롤링 CPU 스레드 병목 현상
호스트 수가 많고 다른 크롤링 병목 현상은 발생하지 않는 경우에는 적절한 해결 방법을 통해 크롤링 시스템을 수직 또는 수평 확장해야 합니다. 크롤러는 Search Service 응용 프로그램당 최대 256개의 스레드를 포함할 수 있습니다. 최대 스레드 수를 사용하는 경우의 이점을 완전하게 실현하려면 쿼드 코어 프로세서를 사용하는 것이 좋습니다. 저장소에서 데이터를 충분히 빠르게 제공한다는 것이 최종적으로 확인되면(이 문서 뒷부분의 "저장소의 크롤링 병목 현상" 섹션 참조), 크롤러 스레드 수를 늘려 저장소에서 데이터를 더 빠르게 요청함으로써 크롤링 처리량을 늘릴 수 있습니다. 이렇게 하려면 다음의 세 가지 방법을 사용합니다.
다음의 Windows PowerShell cmdlet을 사용하여 인덱서 성능 수준을 부분적 축소 또는 최대로 변경합니다.
Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”
코어가 3개 이하인 프로세서를 사용하는 경우 최대 값을 사용합니다.
크롤러 영향 규칙을 사용하여 호스트당 스레드 수를 늘립니다. 이때 최대 256개의 스레드가 지원되며, 몇 개의 호스트에 많은 스레드를 할당하면 다른 저장소에서 데이터를 검색하는 속도가 느려질 수 있음을 고려해야 합니다.
호스트 수가 많은 경우에는 별도의 인덱스에 다른 크롤링 구성 요소를 추가하여 더 빠르게 인덱싱해야 하는 호스트를 크롤링하도록 하는 것이 가장 좋습니다.
IOPS에서 검색 하위 시스템에 병목 현상이 없으며 저장소에서 콘텐츠를 빠르게 제공하는 경우 크롤링 처리량을 원활하게 늘리는 이상적인 방법은 다른 인덱서를 추가하는 것입니다.
저장소의 크롤링 병목 현상
중첩된 사이트 모음 또는 원격 파일 공유가 많은 SharePoint 웹 응용 프로그램을 크롤링할 때 저장소에서 검색 크롤러에 병목 현상이 발생하는 경우가 있습니다. 다음의 두 조건에 해당하는 경우 저장소에서 병목 현상이 발생한 것으로 간주할 수 있습니다.
크롤링 서버의 CPU 사용량이 낮은 경우(20% 미만)
네트워크에서 대기 중인 스레드의 수가 많은 경우(최악의 경우에는 거의 모든 스레드가 대기 중임)
OSS Search Gatherer/Threads Accessing Network 성능 카운터를 통해 병목 현상을 파악할 수 있습니다.
이러한 상황은 저장소에서 데이터를 기다리는 중에 스레드가 차단되었음을 나타냅니다. 콘텐츠 원본이 여러 개인 환경에서는 다른 모든 크롤링을 일시 중지한 후에, 문제의 원인으로 의심되는 호스트를 시작 주소 중 하나로 포함한 콘텐츠 원본을 사용하여 크롤링을 수행함으로써 응답이 느린 호스트를 식별하면 유용할 수 있습니다.
문제가 있는 호스트가 식별되면 응답 시간이 느린 원인을 조사해야 합니다. 특히 SharePoint 콘텐츠의 경우에는 SharePoint Server 2010의 용량 관리 및 크기 조정 문서를 참조하십시오.
크롤링되는 데이터 저장소의 성능 조정을 통해 크롤링 처리량을 크게 개선할 수 있습니다.
성능 및 확장 문제 해결
성능 문제를 해결하려면 반드시 팜의 부하를 파악해야 합니다. 다음 섹션에서는 6천만 개의 항목이 포함된 라이브 팜의 데이터를 사용하여 검색 수명 주기의 다양한 단계에서 확인할 수 있는 여러 시스템 메트릭을 보여 줍니다.
검색 수명 주기 중의 성능 예제
| 메트릭 | 인덱스 가져오기 | 인덱스 유지 관리 | 인덱스 정리 |
|---|---|---|---|
SQL Server CPU(%) 속성 데이터베이스/크롤링 데이터베이스 |
14.8/19.13 |
35/55 |
11/63 |
SQL Server 페이지 예상 수명 속성 데이터베이스/크롤링 데이터베이스 |
60,548/5,913 |
83,366/5,373 |
33,927/2,806 |
SQL Server 평균 디스크 쓰기 속도(초) 속성 데이터베이스/크롤링 데이터베이스 |
9ms/48ms 최대값: 466ms/1,277ms |
12ms/28ms |
20ms/49ms 최대값: 253ms/1156ms |
SQL Server 평균 디스크 읽기 속도(초) 속성 데이터베이스/크롤링 데이터베이스 |
8ms/43ms 최대값: 1,362ms/2,688ms |
11ms/24ms |
24ms/29ms 최대값: 2,039ms/2,142ms |
크롤러 CPU(%) 인덱스 서버 1(크롤링 구성 요소 2개)/인덱스 서버 2(크롤링 구성 요소 2개) |
18/11 |
25.76/21.62 |
8.34/7.49 최고값 99% |
초당 디스크 쓰기 인덱스 서버 1(크롤링 구성 요소 2개)/인덱스 서버 2(크롤링 구성 요소 2개) |
64.32/42.35 |
93.31/92.45 |
99.81/110.98 |
초당 디스크 읽기 인덱스 서버 1(크롤링 구성 요소 2개)/인덱스 서버 2(크롤링 구성 요소 2개) |
0.23/0.20 |
4.92/2.03 |
1.38/1.97 |
평균 디스크 쓰기 속도(초) 인덱스 서버 1(크롤링 구성 요소 2개)/인덱스 서버 2(크롤링 구성 요소 2개) |
11ms/11ms |
1ms/2ms |
5ms/4ms 최대값: 1,962ms/3,235ms |
평균 디스크 읽기 속도(초) 인덱스 서버 1(크롤링 구성 요소 2개)/인덱스 서버 2(크롤링 구성 요소 2개) |
1ms/2ms |
12ms/11ms |
10ms/16ms 최대값: 2,366ms/5,206ms |
쿼리 성능 문제 해결
SharePoint 검색에 포함된 계측 쿼리 파이프라인과 관련 관리 보고서를 사용하면 서버 기반 쿼리 성능 문제를 해결할 수 있습니다. 자세한 내용은 검색 관리 보고서 사용(SharePoint Server 2010)을 참조하십시오. 이 섹션에서는 보고서에 대해 설명한 다음, 이러한 보고서를 사용하여 서버의 문제를 해결하는 방법을 설명합니다. 또한 클라이언트 기반(브라우저) 성능 문제를 해결하는 데 사용할 수 있는 도구와 지침도 소개합니다.
서버 기반 쿼리 문제
서버 기반 쿼리 성능 문제는 다음의 두 수준으로 구분할 수 있습니다.
검색 프런트 엔드 성능 문제
검색 백 엔드 성능 문제
아래의 두 하위 섹션에서는 각 문제를 해결하는 방법에 대해 자세히 설명하며 상세한 지침을 제공합니다.
프런트 엔드 성능 문제
프런트 엔드 성능 문제를 해결할 때는 먼저 전체 쿼리 대기 시간 검색 관리 보고서를 검토해야 합니다. 다음은 예제 보고서입니다.
.gif "검색 쿼리 대기 시간 예제 보고서")
이 보고서에서 프런트 엔드 성능은 다음 데이터 계열로 표시됩니다.
서버 렌더링: 이 값은 지정된 시간(분) 중 프런트 엔드 웹 서버의 여러 검색 웹 파트에 포함된 쿼리당 소요된 평균 시간을 나타냅니다.
개체 모델: 이 값은 지정된 시간(분) 중 프런트 엔드 웹 서버와 검색 백 엔드 간의 통신에 소요된 평균 시간을 나타냅니다.
서버 렌더링 문제 해결
서버 렌더링 문제는 검색 결과 페이지를 제공하는 프런트 엔드 웹 서버에서 수행되는 모든 작업의 영향을 받을 수 있습니다. 일반적으로는 여러 웹 파트를 검색하는 데 소요되는 시간을 파악하여 대기 시간이 더 추가되는 위치를 찾습니다. 대기 시간이 보다 자세하게 보고되도록 하려면 검색 결과 페이지에서 개발자 대시보드(영문일 수 있음)를 사용하도록 설정하십시오. 서버의 과도한 렌더링 대기 시간을 나타내는 일반적인 문제는 다음과 같습니다.
다음과 같은 플랫폼 문제
Active Directory 조회 속도가 느림
SQL Server 실행 속도가 느림
SharePoint Server 2010의 사용자 쿼리 또는 FAST Search Server 2010 for SharePoint의 모든 쿼리에서 사용자 프로필 응용 프로그램에 대한 요청 속도가 느림
사용자 기본 설정을 가져오기 위한 요청 속도가 느림
보안 토큰 서비스에서 사용자 토큰을 가져오기 위한 호출 속도가 느림
체크 인되었지만 게시되지는 않은 수정된 검색 결과 페이지(예: results.aspx 및 peopleresults.aspx)와 같은 코드 숨김 문제
개체 모델 문제 해결
개체 모델 문제는 다음 항목의 영향을 받을 수 있습니다.
다음과 같은 WCF(Windows Communication Foundation) 레이어의 문제
배포에서 WCF 호출의 시간이 초과되고 스레드 중단 예외가 발생함
프런트 엔드 웹 서버와 응용 프로그램 서버 간의 통신 속도가 느림. IPsec 문제 또는 느린 네트워크 속도 때문일 수 있습니다.
콘텐츠와 서비스 팜 간의 통신 문제(구성된 경우)
백 엔드 성능 문제
백 엔드 쿼리 성능 문제를 해결할 때는 먼저 SharePoint 백 엔드 쿼리 대기 시간 검색 관리 보고서를 검토해야 합니다. 다음은 예제 보고서입니다.
.gif "검색 백 엔드 쿼리 대기 시간 예제 보고서")
이 보고서에서 백 엔드 성능은 다음의 데이터 계열(기능 구성 요소별로 그룹화됨)로 표시됩니다. 각 항목은 지정된 시간(분) 중 쿼리당 소요된 평균 시간입니다.
쿼리 구성 요소:
- 전체 텍스트 쿼리: 전체 텍스트 인덱스에서 결과를 쿼리하는 데 소요된 평균 시간입니다.
속성 데이터베이스:
여러 결과 검색: 쿼리 결과에 표시할 제목, 작성자 등의 문서 메타데이터를 검색하는 데 소요된 평균 시간입니다.
속성 저장소 쿼리: 속성 기반 쿼리에 대해 속성 데이터베이스를 쿼리하는 데 소요된 평균 시간입니다.
검색 관리 데이터베이스:
최상의 선택: 쿼리 용어에 사용 가능한 최상의 선택이 있는지를 확인하는 데 소요된 평균 시간입니다.
높은 정확도 결과: 쿼리에 대한 높은 정확도 결과를 검색하는 데 소요된 평균 시간입니다.
쿼리 프로세서:
보안 조정: 사용자에게 액세스 권한이 없는 항목을 제거하는 데 소요된 평균 시간입니다.
중복 제거: 중복 항목을 제거하는 데 소요된 평균 시간입니다.
결과 채우기: 개체 모델로 다시 전달할 메모리 내 테이블을 만드는 데 소요된 평균 시간입니다.
쿼리 구성 요소 성능 문제 해결
구성 요소(특히 쿼리 요청에 응답하는 액티브 구성 요소)는 리소스를 많이 사용합니다. 쿼리 구성 요소의 성능 문제를 해결하는 것은 보다 복잡한 검색 영역 중 하나입니다. 일반적으로 고려할 영역은 다음과 같습니다.
가장 리소스를 많이 사용하는 쿼리 구성 요소 이벤트는 쉐도우 인덱스가 마스터 인덱스와 병합되는 마스터 병합입니다. 이 이벤트는 각 쿼리 구성 요소에 대해 독립적으로 수행됩니다. 이 문서의 앞부분에서 언급한 SharePoint 백 엔드 쿼리 대기 시간 보고서에서 이 이벤트의 영향을 확인할 수 있습니다(오후 1시 30분 이전 시간). 이 이벤트가 쿼리 대기 시간에 영향을 주는 경우 블랙아웃 기간을 정의할 수 있습니다. 변경 비율이 정의된 제한을 초과하지 않으면 이 기간 동안에는 마스터 병합 이벤트가 발생하지 않습니다.
환경의 값이 계속해서 높으면 다음을 수행해야 할 수 있습니다.
서버에 있는 각 구성 요소의 인덱스 크기를 파악하고, 인덱스 크기 합의 약 33%를 캐시할 수 있는 충분한 RAM이 서버에 있는지 확인합니다.
서버의 쿼리 구성 요소 IO 채널을 파악하고, IO 병목 현상이 발생하지 않는지 확인합니다.
IO 및 RAM이 성능 문제의 원인이 아닌 경우에는 쿼리 구성 요소를 다시 분할(인덱스 파티션을 추가)하여 추가 쿼리 구성 요소를 새 서버로 수평 확장해야 합니다.
속성 데이터베이스 문제 해결
저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)의 개념을 참고하여 SQL Server 상태를 파악합니다. 사용자 지정 쿼리를 실행하는 경우에는 힌트를 참고하여 쿼리 계획을 수정해야 할 수 있습니다.
검색 관리 데이터베이스 문제 해결
저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)의 개념을 참고하여 SQL Server 상태를 파악합니다.
쿼리 프로세서 문제 해결
쿼리 프로세서의 문제를 해결하는 작업은 다음의 쿼리 프로세서 영역 중 쿼리 대기 시간에 영향을 주는 항목에 따라 달라집니다.
보안 조정:
Windows 클레임의 경우 쿼리 프로세서를 호스팅하는 서버의 Active Directory 연결을 확인합니다.
어떤 경우라도 SQL Server 프로파일러에서 결정하는 많은 수의 SQL Server 왕복 간에 상관 관계가 있으면 쿼리 프로세서에서 사용하는 캐시 크기를 늘릴 수 있습니다. 쿼리의 25% 이상은 검색 관리 데이터베이스에서 보안 설명자를 검색하는 데 SQL Server 호출을 필요로 하지 않습니다. 이러한 호출이 필요한 경우 쿼리 프로세서 캐시 크기를 조정하십시오.
중복 제거:
- 여러 위치에서 동일한 콘텐츠가 크롤링되는지 확인하고, 검색 센터에서 중복 검색을 사용하지 않도록 설정합니다.
중복 결과 검색:
- 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)의 개념을 참고하여 SQL Server 상태를 파악합니다.
브라우저 기반 쿼리 문제
검색 결과가 반환되는 속도가 빠르면 사용자의 작업이 원활해지지만, 해당 속도가 느리면 사용자가 큰 불편을 겪을 수 있습니다. 페이지 로드 시간은 사용자의 검색 환경 만족도를 결정하는 중요한 요인 중 하나입니다. 페이지 로드 시간을 고려할 때는 대부분 서버 쪽, 특히 서버에서 결과를 반환하는 시간에 주목하는 경우가 많은데, 클라이언트 쪽 렌더링 역시 페이지 로드 시간의 중요한 구성 요소이므로 반드시 고려해야 합니다.
검색 사용자 환경은 총 페이지 로드 시간에 대해 초 단위 미만의 시간 내에 응답하도록 설계되어 있습니다. 이 시간을 제외하면 클라이언트 렌더링에 소요되는 시간은 브라우저 및 렌더링 측정값에 따라 보통 280밀리초 미만입니다. 이러한 환경에서는 사용자가 검색 결과를 매우 빠르게 확인할 수 있습니다.
결과 환경을 사용자 지정하면 렌더링 성능이 저하되기 쉽습니다. 검색 관리자 및 개발자는 각 수정 작업 후에 렌더링 시간을 면밀하게 측정하여 성능이 크게 저하되지 않았는지 확인해야 합니다. 페이지에 새 웹 파트, 새 CSS 스타일시트 등의 항목을 추가할 때마다 브라우저의 렌더링 시간이 길어져 사용자에게 결과가 표시되는 시간이 지연됩니다. 그러나 이 지연 시간의 길이는 페이지 사용자 지정 시에 모범 사례를 따르는지에 따라 크게 달라질 수 있습니다.
다음은 몇 가지 일반적인 지침입니다.
페이지에서 기본적인 브랜딩 및 스타일 사용자 지정을 수행하는 경우 늘어나는 페이지 로드 시간은 약 25밀리초 이하입니다. 사용자 지정을 구현하기 전과 후에 페이지 로드 시간을 측정하여 변경 내용을 관찰하십시오.
사용자는 속도가 20% 정도 증감하면 변화를 인식하게 되므로, 변경을 할 때는 이 점을 유념하십시오. 표준 렌더링 시간의 20%는 50밀리초에 불과합니다(출처: 디자인 및 엔지니어링 시간(영문일 수 있음)).
CSS 스타일시트 및 JScript는 렌더링 성능 저하의 가장 일반적이자 큰 원인입니다. CSS 스타일시트와 JScript를 사용자 지정해야 하는 경우에는 각각 한 파일씩만 포함하십시오.
사용자에게 결과를 보다 빠르게 표시하기 위해 JScript는 페이지가 렌더링된 후 요청 시에 로드할 수 있습니다. 이렇게 하는 방법에 대한 자세한 내용은 성능 고려 사항 문서에서 설명합니다.
페이지에 사용자 지정 내용을 많이 추가할수록 페이지 로드 속도는 느려집니다. 추가된 기능과 스타일이 사용자의 검색 결과를 지연시킬 가치가 있을 정도로 중요한 것인지를 고려하십시오.
이러한 지침 외에도 페이지 로드 시간을 줄이는 방법과 속도가 느린 페이지가 사용자 환경에 주는 영향에 대한 다양한 정보를 인터넷에서 확인할 수 있습니다.
크롤링 성능 문제 해결
크롤링 하위 시스템이 인덱스 가져오기, 유지 관리 및 삭제 단계를 수행하면 해당 시스템에서 SharePoint 검색에 병목 현상이 발생할 수 있습니다. 크롤링 성능 문제를 효율적으로 해결하려면 이 문서 뒷부분의 "일반적인 병목 현상 및 해당 원인" 섹션에 나오는 정보와 검색 상태 모니터링 보고서를 함께 활용하여 크롤링 문제를 파악해야 합니다.
인덱스 가져오기 단계 중의 문제 해결
크롤링 문제를 처음으로 파악해야 하는 위치는 콘텐츠 원본당 크롤링 비율 상태 보고서입니다. 이 문서 뒷부분에 나와 있는 것처럼, 이 보고서에서는 시스템에 있는 각 콘텐츠 원본의 크롤링 비율에 대한 개요를 확인할 수 있습니다. 일반적으로 크롤링 비율은 사용자 콘텐츠 원본의 경우 초당 문서 16개 이상, 그리고 기타 모든 콘텐츠 원본 유형의 경우 초당 문서 35개 이상이어야 합니다.
.gif "검색 크롤링 속도 예제 보고서")
크롤링 비율이 최적 상태가 아닌 콘텐츠 원본이 식별되는 경우 다음 단계를 수행하는 것이 좋습니다.
조사 중인 콘텐츠 원본을 제외한 기타 모든 크롤링을 일시 중지하고, 크롤링 비율이 지정된 목표(초당 문서 15-35개)를 초과하도록 개선되었는지 확인합니다.
위 단계를 수행해도 변화가 없는 경우 크롤링 중인 저장소가 정상적으로 응답하며 느린 크롤링 속도의 원인이 아닌지 확인합니다. 이 문서 앞부분에 나오는 "저장소의 크롤링 병목 현상" 섹션을 참조하십시오.
저장소에서 병목 현상이 발생하지 않는 경우에는 크롤링 서버 또는 데이터베이스 서버의 병목 현상을 파악하고 이들 서버를 최적화합니다. 지침은 이 문서 앞부분의 "크롤링 IOPS 병목 현상" 및 "크롤링 CPU 스레드 병목 현상" 섹션에서 확인할 수 있습니다.
인덱스 유지 관리 단계 중의 문제 해결
인덱스 유지 관리 단계의 기본 목표는 인덱스를 최대한 최신 상태로 유지하는 것입니다. 이 단계의 두 가지 주요 지표는 다음과 같습니다.
인덱스 최신성: 크롤링이 예정된 시간에 완료되며 인덱스 최신성에 대한 IT 지침을 따르는지 여부
증분 크롤링 속도: 인덱스 최신성 목표가 충족되지 않는 경우 증분 크롤링 속도가 사용자 콘텐츠 원본의 경우 초당 문서 10개, 기타 모든 콘텐츠 원본의 경우 초당 문서 35개인지 확인합니다. 증분 크롤링 속도가 이보다 낮은 경우에는 위에서 설명한 대로 크롤링되는 저장소 및 크롤링 하위 시스템에서 병목 현상 분석을 수행해야 합니다.
일반적인 병목 현상 및 원인
성능 테스트를 수행하는 동안 여러 가지 일반적인 병목 현상이 발견되었습니다. 병목 현상은 팜의 특정 구성 요소가 용량 한도에 도달한 상황을 의미합니다. 이로 인해 팜 처리량이 더 이상 늘어나지 않거나 줄어들게 됩니다.
아래 표에는 몇 가지 일반적인 병목 현상과 그 원인 및 가능한 해결 방법에 대한 설명 나와 있습니다.
| 병목 현상 | 증상(성능 카운터) | 해결 방법 |
|---|---|---|
데이터베이스 RAM |
속성 데이터베이스 검색 관리 데이터베이스에서 다음과 같은 현상이 발생합니다. SQL Server 버퍼 관리자/페이지 수명 예상 시간이 300초보다 작음(정상의 경우 1,000초보다 커야 함) SQL Server 버퍼 관리자/버퍼 캐시 적중률이 96%보다 낮음(정상의 경우 98%보다 높아야 함) |
데이터베이스 서버에 메모리를 추가합니다. 주간 조각 모음 규칙을 사용하지 않도록 설정한 경우 속성 데이터베이스를 조각 모음합니다. 페이지 압축을 사용하도록 설정하려면 SQL Server 2008 Enterprise Edition을 사용 중인지 확인합니다. 데이터베이스를 별도의 서버로 이동하고 필요한 경우 여러 속성 데이터베이스를 추가합니다. |
데이터베이스 서버 IOPS |
속성 데이터베이스 또는 크롤링 데이터베이스에서 다음과 같은 현상이 발생합니다. 평균 디스크 읽기 시간(초) 및 평균 디스크 쓰기 시간(초)이 50밀리초보다 작거나 큽니다. |
중요 테이블(MSSDocSDIDs + MSSDocProps + MSSDocresults)의 33%를 캐시에 저장할 수 있도록 데이터베이스 서버에 RAM이 충분한지 확인합니다. 다음을 실행하여 데이터베이스의 전용 IOPS 수를 늘립니다. 다른 저장소 배열 사용 저장소 배열에 스핀들(디스크 드라이브)을 추가하는 등의 작업을 통해 저장소 구성 최적화 사용하지 않도록 설정된 경우 SharePoint 상태 분석기 검색 실행 - 하나 이상의 속성 데이터베이스에 조각화된 인덱스 규칙이 있습니다. SharePoint 상태 분석기 검색 실행 - 하나 이상의 크롤링 데이터베이스에 조각화된 인덱스 규칙이 있습니다. 페이지 압축을 사용하도록 설정하려면 SQL Server 2008 Enterprise Edition을 사용 중인지 확인합니다. 데이터베이스를 별도의 서버로 이동하고 필요한 경우 여러 속성 데이터베이스 또는 크롤링 데이터베이스 중 하나를 추가하거나 두 데이터베이스를 모두 추가합니다. |
쿼리 구성 요소 IOPS |
쿼리 구성 요소의 인덱스에 사용되는 논리 디스크에서 다음과 같은 현상이 발생합니다. 오랜 시간(인덱스 병합 중만이 아니라 하루 중 대부분의 시간) 동안 평균 디스크 읽기 속도(초) 및 평균 디스크 쓰기 속도(초)가 30밀리초보다 작거나 큽니다. |
각 응용 프로그램 서버에서 각 액티브 쿼리 구성 요소의 인덱스 중 33%를 캐시(운영 체제 캐시)에 저장할 수 있도록 해당 서버에 RAM이 충분한지 확인합니다. 다음을 실행하여 쿼리 구성 요소의 인덱스에 사용되는 드라이브에 대해 전용 IOPS 수를 늘립니다. 다른 구성 요소에 다른 저장소 배열 사용 저장소 배열에 스핀들(디스크 드라이브)을 추가하는 등의 작업을 통해 저장소 구성 최적화 |
작성자 정보
Brion Stone은 Microsoft의 SharePoint Server 검색 선임 프로그램 관리자입니다.