검색 성능을 위한 최상의 방법(Office SharePoint Server 2007)

아티클
06/16/2015

업데이트 날짜: 2009년 7월

적용 대상: Office SharePoint Server 2007

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

이 문서에서는 Microsoft Office SharePoint Server 2007에서 효과적이고 올바른 검색을 유지하는 데 사용할 수 있는 몇 가지 최상의 방법에 대해 설명합니다.

이 문서의 내용

전체 크롤링을 실행하는 이유
웹 서버 모니터링
데이터베이스 서버 모니터링
인덱스 서버 모니터링
SharePoint Diagnostics를 사용하여 Office SharePoint Server 모니터링
통합 로깅 서비스 로그를 사용하여 쿼리 병목 현상 진단
Office SharePoint Server 2007의 검색 성능 향상을 위한 SQL Server 최적화
검색을 위해 SQL Server 데이터베이스 유지 관리
크롤러 기아 상태 방지
액세스 제어 목록으로 인한 병목 현상 방지
누락된 검색 상자 웹 파트 문제 해결

전체 크롤링을 실행하는 이유

용량이 큰 정보, 문서 및 웹 페이지를 크롤링하고 인덱싱하려면 컴퓨터 처리량이 늘어납니다. 또한 크롤링 프로세스는 네트워크 및 기타 리소스도 사용합니다. 따라서 크롤링 및 인덱스 프로세스가 사용자가 사용하는 서비스에 부정적인 영향을 주지 않도록 Office SharePoint Server 2007 팜을 신중하게 구성해야 합니다. 예를 들어 콘텐츠는 보통 사용자가 가장 많이 몰리는 시간 대에 서비스를 원활하게 유지하기 위해 서버 사용량이 적은 시간에 크롤링하고 인덱싱합니다.

크롤링이 미치는 영향을 줄이는 한 가지 방법은 전체 크롤링 대신 증분 크롤링을 예약하는 것입니다. 증분 크롤링은 변경된 항목만 인덱싱하므로 프로세스를 처리하는 데 더 적은 컴퓨터 자원이 필요합니다. 각 콘텐츠 원본에 대해 전체 크롤링 및 증분 크롤링을 선택하여 예약할 수 있습니다. 평일 자정에는 증분 크롤링을 실행하고 토요일 자정에는 전체 크롤링을 실행하는 방법을 고려할 수도 있습니다.

참고

크롤링 일정을 계획하는 방법에 대한 자세한 내용은 콘텐츠 크롤링 계획(Office SharePoint Server)을 참조하십시오.

인덱스를 완전하게 구성하려면 다음 조건에서 전체 크롤링을 수동으로 시작해야 합니다.

관리자 팜에 있는 서버에 업데이트 또는 서비스 팩을 적용한 경우
관리자가 검색 구성에 새 관리 속성을 추가한 경우
관리자가 크롤링 규칙을 추가 또는 수정한 경우
Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 또는 Search Server 2008 사이트에서 ASP.NET 페이지를 다시 인덱싱하려는 경우. 이러한 웹 페이지가 변경되면 크롤러는 이러한 변경 사항을 인식할 수 없습니다. 따라서 전체 크롤링으로 다시 인덱스해야 합니다.
증분 크롤링이 연속적으로 실패한 경우. 저장소의 한 수준에서 100번 연속해서 증분 크롤링에 실패한 경우 인덱스 서버는 해당 콘텐츠를 인덱스에서 제거합니다.
관리자가 손상된 인덱스를 복구한 경우
관리자가 서버 이름 매핑을 만든 경우
일부 콘텐츠에 대한 사용 권한이 변경되었지만 콘텐츠 자체는 변경되지 않고 서비스 팩 1 이후 핫픽스 패키지(KB941442) 이상의 서비스 팩이 서버에 적용된 경우. 이 핫픽스 패키지가 없으면 증분 크롤링은 ACL(액세스 제어 목록)을 확인하지 않습니다. ACL이 확인되지 않으면 관리자가 마지막 증분 크롤링 이후 사용자에 대한 사용 권한을 제거해도 검색 결과에서 항목을 볼 수 있습니다.

다음 조건에서 Office SharePoint Server 2007은 증분 크롤링이 예약되었거나 수동으로 시작되면 전체 크롤링을 수행합니다.

관리자가 수동으로 이전 크롤링을 중지한 경우
관리자가 백업에서 콘텐츠 데이터베이스를 복원한 경우

참고

Microsoft Office Servers 인프라 업데이트를 설치한 경우 Stsadm 명령줄 도구에서 옵션을 사용하여 복원 작업에서 전체 크롤링을 수행할지를 지정할 수 있습니다.
관리자가 콘텐츠 데이터베이스를 분리한 다음 다시 연결한 경우
Office SharePoint Server가 콘텐츠에서 전체 크롤링을 수행한 적이 없는 경우
변경 로그에 크롤링에 대한 주소 정보가 없는 경우. 변경 로그는 마지막 크롤링 이후 항목이 변경되었는지를 확인하는 데 사용됩니다. 변경 로그 정보가 없으면 증분 크롤링은 수행되지 않습니다.
콘텐츠에 액세스하는 데 사용되는 계정이 변경된 경우. 이 계정은 기본 액세스 계정이거나 크롤링 규칙에 지정된 계정일 수 있습니다.
인덱스가 손상된 경우

이 조건에서는 사용자 작업을 신중하게 고려해야 합니다. 크롤링을 예약하거나 수동으로 크롤링을 시작하는 경우 전체 크롤링에는 증분 크롤링보다 많은 리소스가 필요하게 되고 이로 인해 사용자에게 제공하는 서비스에 영향을 줄 수 있습니다.

웹 서버 모니터링

Office SharePoint Server 2007 검색 성능을 최대화하려면 시스템을 자세히 분석해야 합니다. 그리고 서버를 면밀하게 검사하여 기준선을 만들고 정기적으로 성능 테스트를 다시 실행하여 변경 사항을 확인하고 문제를 조기에 진단해야 합니다. 최적화하는 경우 이러한 기준선을 사용하여 향상된 내용을 분석할 수 있습니다. 다음 섹션에서는 Office SharePoint Server 2007 성능과 관련된 다른 도구에서 사용 가능한 성능 모니터 카운터 및 데이터에 대해 살펴봅니다.

참고

일반 시스템 모니터링에 대한 자세한 내용은 성능 모니터링(https://go.microsoft.com/fwlink/?linkid=105584&clcid=0x412)을 참조하십시오.

Office SharePoint Server 2007에서 웹 서버는 모든 사이트 및 사이트 모음을 호스트합니다. 웹 서버는 데이터베이스 서버에 저장된 콘텐츠를 가져와 사용자 요청에 응답합니다. 웹 서버는 사용자 검색 쿼리에 응답을 보내므로 검색 성능에 직접적인 영향을 줍니다. 또한 크롤러가 웹 서버에 요청을 보내 Office SharePoint Server 콘텐츠를 인덱싱하므로 인덱스에도 영향을 줍니다.

웹 서버의 상태를 모니터링하려면 다음 성능 모니터 카운터를 사용합니다.

Processor/% Processor Time/_Total

이 카운터는 프로세서 작업의 기본 표시기입니다. 이 카운터는 프로세서가 유휴 상태가 아닌 스레드를 실행하는 데 걸리는 시간의 비율을 측정합니다. 이 카운터가 오랫동안 평균적으로 80%를 초과하면 프로세스에 병목 현상이 발생했을 수 있으며 업그레이드를 고려해야 합니다.
Memory/Available Mbytes

이 카운터는 시스템 또는 프로세스에서 즉시 사용 가능한 실제 메모리를 측정합니다. 이 카운터가 너무 많이 떨어지면 추가 페이징을 사용하므로 시스템 속도가 느려집니다. 이 경우 서버에 메모리 추가를 고려해야 합니다.
Web Service/Current Connections

이 카운터는 World Wide Web 서비스에 대한 연결 수를 측정합니다. Office SharePoint Server 2007 웹 서버에서 이 카운터는 모든 동시 사용자 수 및 인덱싱하는 경우 크롤러를 포함합니다. 이 카운터는 사용 패턴을 프로필로 만들고 최대 사용 시간을 확인하는 데 사용됩니다. 카운터에 대한 한계는 없습니다. 값이 높을 수록 성능이 뛰어남을 의미합니다.

참고

웹 서버가 여러 개인 Office SharePoint Server 팜에서 이 카운터는 한 서버에 대한 연결 수만 측정합니다. 전체 팜에서 사용자 작업을 모니터링하는 방법에 대한 자세한 내용은 SharePoint Diagnostics에서 Office SharePoint Server 모니터링을 참조하십시오.

데이터베이스 서버 모니터링

Office SharePoint Server 2007에서는 Microsoft SQL Server 2005 또는 Microsoft SQL Server 2008을 사용하여 콘텐츠 데이터베이스를 저장합니다. 인덱스 서버는 데이터베이스가 아닌 파일 시스템에 콘텐츠 인덱스를 저장하지만 문서 메타데이터 및 권한은 검색 데이터베이스에 저장합니다. 대부분의 검색에서 메타데이터를 확인하고 모든 검색이 보안 조정과 관련되어 있으므로 데이터베이스 서버의 성능은 검색 성능에 직접적인 영향을 줍니다.

데이터베이스 상태를 모니터링하려면 다음 성능 모니터 카운터를 사용합니다.

Processor/% Processor Time/_Total

이 카운터는 프로세서 작업의 기본 표시기로, 웹 서버인 경우 데이터베이스 서버에서 중요한 역할을 합니다.
LogicalDisk/% Disk Time/ 디스크 이름

이 카운터는 디스크가 읽기 또는 쓰기 요청을 처리하면서 경과한 시간의 백분율을 표시합니다. 검색에 대해 검색 데이터베이스를 보유하는 디스크에서 이 카운터를 모니터링합니다. 이 카운터가 평균적으로 90%를 초과하는 경우가 많으면 디스크에서 검색 병목 현상이 발생한 것입니다.
System: Processor Queue Length

이 카운터는 평균적으로 서버에 있는 CPU 코어 수의 2배보다 작아야 합니다.
Memory: Available Mbytes

이 카운터는 평균적으로 총 실제 RAM의 20% 이상이어야 합니다.
Memory: Pages/sec

이 카운터는 평균적으로 100 미만이어야 합니다.
Logical Disk: Disk Transfers/sec

이 카운터는 파티션의 전체 처리량을 측정합니다.
Logical Disk: Disk Read Bytes/sec & Disk Write Bytes/sec

이 카운터는 특정 디스크의 총 대역폭을 측정합니다.
Logical Disk: Average Disk sec/Read

읽기 대기 시간이라고도 하는 이 카운터는 디스크가 데이터를 검색하는 데 걸리는 시간을 나타냅니다. 사용자 쿼리에 효과적으로 응답하려면 읽기 대기 시간이 짧아야 합니다.
Logical Disk: Average Disk sec/Write

쓰기 대기 시간이라고도 하는 이 카운터는 디스크가 데이터를 쓰는 데 걸리는 시간을 나타냅니다. 쓰기 대기 시간이 짧을 수록 인덱스 성능이 향상됩니다.
LogicalDisk/% Disk Read Time/ 디스크 이름

이 카운터는 디스크에서 읽기 요청을 처리하면서 경과한 시간의 백분율을 측정합니다. 검색 데이터베이스 디스크에서 읽기 요청 비율이 높으면 사용자가 많은 수의 검색을 실행함을 나타냅니다.
LogicalDisk/% Disk Write Time/ 디스크 이름

이 카운터는 디스크에서 쓰기 요청을 처리하면서 경과한 시간의 백분율을 측정합니다. 검색 데이터베이스 디스크에서 쓰기 요청 비율은 인덱스 프로세스 중에 높아집니다.

참고

가능한 경우 검색 데이터베이스를 다른 데이터베이스와 다른 디스크에 배치하여 검색 성능을 최적화합니다. 검색 데이터베이스가 이와 같이 분리되면 디스크가 검색 전용으로 사용되므로 이 논리 디스크 카운터에서 진단한 검색 성능이 높게 나타납니다.
SQLServer:Buffer Manager/Page life expectancy

이 카운터는 데이터베이스 페이지가 참조되지 않고 버퍼 풀에 남아 있는 시간(초)을 측정합니다. 300초 이상을 남아 있어야 합니다. 값이 300초 미만이면 메모리 병목 현상이 발생하는 것으로 진단하고 서버에 메모리를 추가해야 할지 여부를 고려해야 합니다.

참고

이 Office SharePoint Server 문서에서는 일반적인 SQL Server 최적화에 대해 모두 설명하지 않습니다. 자세한 내용은 다음 리소스를 참조하십시오.

저장소 최상의 방법 상위 10개(영문)(https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x412)
SQL Server 사전 배포 I/O 최상의 방법(영문)(https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x412)
RAID 수준 및 SQL Server(https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x412)
Microsoft SQL Server 성능 모니터 카운터와 SharePoint 제품 및 기술에 대한 자세한 내용은 Office SharePoint Server의 SQL Server 저장소 계획 및 모니터링: 성능 권장 사항 및 최상의 방법(백서)(https://go.microsoft.com/fwlink/?linkid=119398&clcid=0x412)을 참조하십시오.

인덱스 서버 모니터링

Office SharePoint Server 2007에서 인덱스 서버는 콘텐츠를 크롤링하고 인덱스 파일을 만듭니다. 크롤링 프로세스가 완료되면 사용자의 검색 요청에 응답하는 쿼리 서버에 인덱스가 전달됩니다.

인덱스 서버의 성능이 낮아도 사용자에게는 직접적인 영향이 없습니다. 그러나 이 경우 사용량이 적은 시간에만 크롤링을 실행할 수 없을 정도로 크롤링 프로세스에 걸리는 시간이 길어져 백업과 같이 사용량이 적은 시간에 수행해야 하는 작업과 크롤링이 동시에 실행되는 결과를 낳게 됩니다.

참고

인덱스 서버는 사용 가능한 서버 수에 따라 별도의 서버에 배치하지 못하는 경우도 발생할 수 있습니다.

인덱스 서버 상태를 모니터링하려면 크롤링 중에 다음 성능 모니터 카운터를 사용합니다.

Office Server Search Archival Plugin/Total Docs in first queue/Portal_Content

이 카운터는 보관 플러그 인의 첫 번째 큐에 있는 문서 수를 측정합니다. 크롤링 중에 500 미만이어야 하며 다른 시간에는 더 낮아야 합니다. 카운터가 500 이상이면 데이터베이스 서버의 검색 데이터베이스 드라이브에 병목 현상이 발생한 것일 수 있습니다.
Office Server Search Archival Plugin/Total Docs in second queue/Portal_Content

이 카운터는 보관 플러그 인의 두 번째 큐에 있는 문서 수를 측정합니다. 앞의 카운터와 마찬가지로 크롤링 중에 500 미만이어야 합니다.
Office Server Search Gatherer/Idle Threads

이 카운터는 문서를 대기하는 수집기 프로세스의 스레드 수를 측정합니다. 이 카운터가 0이면 수집기에 리소스가 부족한 것이므로 동시 크롤링 수를 줄이는 것이 좋습니다.
Office Server Search Gatherer/Threads Accessing Network

이 카운터는 원격 데이터 저장소로 요청을 보내고 응답을 대기하거나 처리 중인 스레드 수를 측정합니다. 이 카운터가 계속 높으면 네트워크 대역폭에 병목 현상이 있거나 인덱스 서버가 인덱스 콘텐츠에 대한 하나 이상의 느린 호스트에 연결되었을 수 있습니다.
Office Server Search Gatherer/Filtering Threads

이 카운터는 콘텐츠를 검색하고 필터링한 스레드 수를 측정합니다. 이 수가 높으면 인덱스 서버의 리소스가 병목 현상의 원인일 수 있습니다.
Office Server Search Gatherer/Threads In Plug-Ins

이 카운터는 IFilters와 같이 플러그 인을 통해 콘텐츠를 검색하고 처리하는 스레드 수를 측정합니다. 크롤링 프로세스에서 인덱스 및 검색 데이터베이스를 채우는 단계에 해당합니다.
Office Server Search Gatherer Projects/Crawls in progress

이 카운터는 진행 중인 크롤링 수를 측정합니다. 이 값은 관리자가 크롤링을 수동으로 시작하지 않는 한 크롤링이 예약된 콘텐츠 원본 수와 일치해야 합니다.

SharePoint Diagnostics를 사용하여 Office SharePoint Server 모니터링

SharePoint Diagnostics 도구 v1.0(SPDiag라고도 함)은 SharePoint 제품 및 기술을 실행하는 서버 또는 팜에 대한 다양한 정보를 나타내는 고급 진단 및 분석 도구입니다. SPDiag를 사용하면 서버 및 팜 구성의 자세한 스냅숏을 볼 수 있습니다. 또한 IIS(인터넷 정보 서비스), ULS(통합 로깅 서비스) 로그 및 이벤트 로그에서 정보를 병합하고 볼 수 있으며 느린 요청과 같은 성능 문제를 조사할 수 있습니다.

참고

SPDiag는 Microsoft SharePoint Administration Toolkit v3.0(영문)(https://go.microsoft.com/fwlink/?linkid=141504&clcid=0x412)에 포함된 기능입니다.

SPDiag는 팜에 있는 서버의 성능 카운터 그래프를 제공할 수 있습니다. 하지만 IIS 로그에 기반하여 팜 전체 데이터를 측정하는 여러 카운터를 포함할 수도 있습니다. 이러한 팜 전체 분석은 성능 모니터만 단독으로 사용해서는 수행할 수 없습니다.

참고

SPDiag를 효과적으로 사용하려면 SharePoint Diagnostics Tool(SPDiag) 사용자 가이드(영문)(https://go.microsoft.com/fwlink/?linkid=141204&clcid=0x412)를 먼저 읽어 보는 것이 좋습니다.

다음 팜 전체 카운터를 사용하여 Office SharePoint Server 2007 팜의 응답 성능을 조사합니다.

SharePointRequests/Number of unique client IP

이 카운터는 지정된 기간에 요청을 전달하는 고유한 클라이언트 수를 측정합니다. 프록시 서버를 통해 팜에 액세스하는 클라이언트는 단일 IP 주소로 나타납니다.
SharePointRequests/Number of unique client agents

이 카운터는 지정된 기간에 요청을 전달하는 고유한 클라이언트 에이전트(브라우저) 수를 측정합니다. 이 카운터는 브라우저의 HTTP 요청에 지정된 에이전트에 기반하므로 프록시 서버를 통해 팜에 액세스하는 여러 클라이언트를 구별할 수 있습니다.

참고

다음 카운터는 요청 수를 측정합니다. 이 요청에는 클라이언트에 대한 요청 및 검색 쿼리가 모두 포함됩니다.
SharePointRequests/Total requests

이 카운터는 지정된 기간에 변경되는 총 요청 수를 측정합니다. 빠른 요청과 느린 요청의 비율을 확인하려면 항상 이 카운터를 다음 카운터와 함께 모니터링해야 합니다.
SharePointRequests/Number of requests with time taken < 1 second

이 카운터는 1초 내 처리된 요청 수를 측정합니다. 원활하게 수행되는 팜에서 이 카운터는 Total requests 카운터에 근접합니다.
SharePointRequests/Number of requests with time taken 1-5 seconds

이 카운터는 1 - 5 초 내 처리된 요청 수를 측정합니다. 일반적으로 이 정도 성능은 사용자에게 허용되는 수준이지만 시간에 따른 이 요청의 비율이 증가하면 병목 현상이 증가하고 있음을 나타낼 수 있습니다.
SharePointRequests/Number of requests with time taken 5-10 seconds

이 카운터는 5 - 10 초 내 처리된 요청 수를 측정합니다. 결과가 반환되기 전에 페이지에서 클릭하여 볼 수 있습니다.
SharePointRequests/Number of requests with time taken > 10 seconds

이 카운터는 10초를 초과하여 처리된 요청 수를 측정합니다. 이 요청이 Total requests의 상당한 비율을 차지하는 경우 팜은 응답하지 않습니다. 이 경우 병목 현상이 있는지 조사하고 하드웨어 업그레이드를 고려해야 합니다.

통합 로깅 서비스 로그를 사용하여 쿼리 병목 현상 진단

ULS(통합 로깅 서비스)를 사용하여 Office SharePoint Server 2007 시스템의 성능을 모니터링하고 최적화할 수 있습니다. 시스템 최적화 방법 중 하나로 ULS를 사용해야 하며 다른 방법으로는 성능 모니터, 이벤트 로그 및 웹 로그 등이 있습니다.

이 섹션에서는 ULS 로그를 사용하여 검색 성능의 지연을 진단하는 방법을 보여 줍니다. ULS 로그를 사용하면 어떤 검색 프로세스의 단계에서 대부분의 시간이 소비되고 이로 인해 사용자에게 결과가 반환되는 것을 지연하는지 진단할 수 있습니다. 또한 ULS 로그를 사용하여 시스템 구성에서 사소한 변경으로 인한 성능 향상을 평가해야 합니다.

참고

디스크 공간 사용 및 성능에 영향을 주지 않도록 ULS 로깅 기능은 최소화하여 적절히 사용합니다. ULS에서 진단 성능이 문제가 되는 경우 ULS 로깅을 사용하지 않도록 설정하여 성능을 최대화할 수 있습니다. ULS 로그를 여유 공간이 많은 디스크에 저장하는 것도 좋은 방법 중 하나입니다.

참고

Log Parser 2.2에서 사용할 쿼리의 추가 예제와 자세한 내용은 Microsoft 엔터프라이즈 검색 블로그의 방법: 쿼리 대기 시간에 대해 ULS 로그 마이닝(영문)(https://go.microsoft.com/fwlink/?linkid=148540&clcid=0x412)을 참조하십시오.

통합 로깅 서비스 구성

Office SharePoint Server 2007 중앙 관리 웹 사이트에서 ULS 구성을 시작합니다.

중요

다음 절차를 완료하려면 Farm Administrators 그룹의 구성원이어야 합니다.

검색 성능 문제를 진단하도록 통합 로깅 서비스를 구성하려면

시작, 모든 프로그램, Microsoft Office Server, SharePoint 3.0 중앙 관리를 차례로 클릭합니다.
작업 탭을 클릭합니다.
기록 및 보고 섹션에서 진단 로깅을 클릭합니다.
이벤트 제한 섹션의 범주 선택 목록에서 MS 검색 쿼리 프로세서를 클릭합니다.
추적 로그에 보고할 최소 중요 이벤트에서 높음을 클릭합니다.
페이지 아래쪽에 있는 확인을 클릭합니다.

Log Parser 도구 사용

IIS(인터넷 정보 서비스) 로그와 마찬가지로 Office SharePoint Server 2007 ULS 로그는 텍스트 파일 형식이며 크기가 매우 큽니다. 이 파일의 콘텐츠를 분석하려면 로그 구문 분석 유틸리티를 사용하여 원하는 추적에 초점을 맞추고 검토하기 쉽게 데이터의 형식을 지정하는 것이 좋습니다. 이러한 용도로는 무료로 제공되는 Microsoft Log Parser 2.2(영문)(https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x412) 도구를 사용할 수 있습니다.

Log Parser 도구는 명령줄 프로그램입니다. 다음 매개 변수를 사용하여 ULS 로그가 탭으로 분리된 유니코드 텍스트 파일임을 나타내야 합니다.

logparser -i:TSV -iCodepage:-1 -fixedSep:ON

이 매개 변수 외에도 Log Parser에 로그 파일 분석 방법을 지시하는 Transact-SQL 양식의 쿼리를 제공해야 합니다. 예를 들어 쿼리 프로세서 타이머 메시지에 초점을 맞추려면 다음 WHERE 절을 사용합니다.

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'

참고

Log Parser 명령 프롬프트에 SQL 쿼리 텍스트를 직접 입력할 수 있습니다. 또는 텍스트 파일에 쿼리를 저장하고 file: 매개 변수를 사용하여 Log Parser에 해당 위치를 전달할 수 있습니다. 이 방법은 자주 사용하는 쿼리나 길고 복잡한 쿼리에 유용합니다.

ULS 로그의 검색 메시지

앞에서 설명한 대로 ULS를 구성한 경우 사용자가 쿼리를 실행하면 다음 메시지가 로그 파일에 나타납니다.

Completed query execution with timings

이 메시지는 쿼리가 완료되었으며 쿼리를 설명하는 6개의 타이밍(밀리초)을 포함함을 나타냅니다. 6가지 타이밍은 다음과 같습니다.
- v1. 쿼리를 처리하는 데 걸리는 총 시간입니다.
- v2. 중복 항목을 찾은 후 측정한 쿼리 대기 시간입니다.
- v3. 보안을 조정한 후 측정한 쿼리 대기 시간입니다.
- v4. 인덱스 결과를 검색 데이터베이스의 결과와 연결한 후 측정한 쿼리 대기 시간입니다.
- v5. 인덱스 서버에서 결과가 반환되는 것을 대기하는 데 걸린 시간입니다.
- v6. 검색 데이터베이스에서 가져오기 속성을 제외하고 데이터베이스에 대한 호출에 걸린 시간입니다.
이 6개의 타이밍에서 다음 정보를 계산할 수 있습니다.
- v1 – v2. 속성을 검색하고 검색 항목을 강조 표시하는 데 걸린 시간입니다.
- v2 – v3. 중복 항목을 찾는 데 걸린 시간입니다.
- v3 – v4. 보안 조정에 걸린 시간입니다.
- v4 – v5. 인덱스 결과를 검색 데이터베이스 결과와 연결하는 데 걸린 시간입니다.
Join retry

이 메시지는 검색 데이터베이스에서 반환된 결과가 전체 텍스트 인덱스에서 반환된 결과와 일치하지 않아서 연결할 수 없으므로 다시 시도함을 나타냅니다.
Security Trimming retry

이 메시지는 사용자에게 읽기 권한이 없음을 알리는 결과를 반환하는 쿼리를 사용자가 실행했음을 나타냅니다. 이 쿼리는 충분한 결과를 반환할 때까지 많은 결과를 요청하며 다시 시도됩니다.
Near duplicate removal retry

이 메시지는 실제로 동일한 여러 문서가 결과에서 제외되어 쿼리 프로세서에서 표시할 결과가 충분하지 않음을 나타냅니다. 이 쿼리는 충분한 결과를 반환할 때까지 많은 결과를 요청하며 다시 시도됩니다.

쿼리 타이밍 분석

이 섹션의 앞에서 설명한 메시지 중 Completed query execution with timings 메시지는 쿼리를 처리하는 동안 지연이 발생했음을 진단한 경우 가장 많이 사용되는 메시지입니다. 보안 조정 속도가 느린 경우 v3 – v4 계산 값은 총 처리 시간 v1에서 대부분을 차지합니다.

타이밍을 분석하려면 다음 SQL 쿼리를 Log Parser 도구에 전달합니다. 이 도구에서는 v1 - v6 타이밍 및 이들 간의 차이 값을 포함하는 쉼표로 분리된 파일을 만듭니다.

Select  Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
      TO_INT(Extract_token(Message,8, ' ')) as v2,
      TO_INT(Extract_token(Message,9, ' ')) as v3,
      TO_INT(Extract_token(Message,10, ' ')) as v4,
      TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
      TO_INT(Extract_token(Message,12, ' ')) as v6,
      SUB(v4, TimeSpentInIndex) as JoinTime,
      SUB(v3, v4) as SecurityTrimmingTime,
      CASE v2
           WHEN 0 THEN 0 
           ELSE SUB(v2, v3) 
      End as DuplicateDetectionTime,
      SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution with timings:%'

결과로 생성된 CSV 파일을 Microsoft Office Excel 또는 다른 분석 도구로 가져와 그래프 및 보고서를 만들 수 있습니다. 사용량이 많은 시스템에서는 많은 쿼리가 수행되므로 여러 결과를 활용하여 유용한 분석 자료를 얻을 수 있어야 합니다.

다시 시도 분석

Completed query execution with timings 메시지에서 사용 가능한 타이밍 데이터에는 다시 시도(예: 보안 조정으로 인한 다시 시도)에 대한 정보가 포함되지 않습니다. 쿼리 프로세서에서 다시 시도에 걸리는 시간을 분석하려면 총 쿼리 수를 다른 종류의 다시 시도 수와 비교해야 합니다.

다음 쿼리는 실행한 총 쿼리 수를 계산합니다.

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution%'

다음 쿼리는 보안 조정으로 인한 총 다시 시도 수를 계산합니다.

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Security trimming retry%'

다음 쿼리는 중복 결과 제거로 인한 총 다시 시도 수를 계산합니다.

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Near duplicate removal retry%'

이 쿼리를 사용하여 지연 쿼리 결과를 다시 시도하는 방법을 진단합니다. 다시 시도 수가 총 쿼리 수에서 많은 부분을 차지하면 구성을 수정해야 합니다. 예를 들어 소수의 사용자만 콘텐츠 원본 중 하나에 있는 문서에 액세스하는 경우 보안 조정 다시 시도 수가 늘어날 수 있습니다. 이 경우 인덱스에서 이 원본을 제거하는 것이 좋습니다.

Office SharePoint Server 2007의 검색 성능 향상을 위한 SQL Server 최적화

Microsoft Office SharePoint Server 2007에서는 Microsoft SQL Server를 사용하여 인덱스된 콘텐츠의 콘텐츠, 구성 정보 및 속성을 저장합니다. 따라서 Office SharePoint Server에서 최적의 성능을 보장하려면 SQL Server를 최적화해야 합니다.

참고

Office SharePoint Server 2007에서는 SQL Server 2008 또는 SQL Server 2005에 저장된 데이터베이스를 사용할 수 있습니다.

일반적인 SQL Server 최적화

일부 최적화는 서버 용도에 상관없이 SQL Server 성능을 향상시킵니다. 따라서 Office SharePoint Server 데이터베이스에 대해 최적화가 적용되도록 하는 것에 초점을 맞추는 것이 중요합니다.

데이터베이스 서버를 계획하고 배포하는 경우 다음 권장 사항을 고려합니다.

가능한 경우 전용 서버 또는 서버 팜에서 SQL Server를 실행합니다.
서버 팜에 여러 데이터베이스 서버를 확장 배치합니다. 일반적으로 가용 범위에서 실행하는 4개의 웹 서버에 모두 데이터베이스 서버를 설치해야 합니다.
64비트 운영 체제가 설치된 컴퓨터에서 64비트 버전의 SQL Server를 사용합니다.
하드웨어 예산에서 허용하는 범위 내에서 가능한 많은 디스크 스핀들을 사용합니다.
속도가 빠른 디스크를 사용합니다.
RAID 1+0 또는 RAID 1 디스크 배열에 데이터베이스를 배치합니다.
기본 및 보조 데이터 파일을 저장하지 않는 실제 디스크에 로그 파일을 분리합니다.

참고

이 Office SharePoint Server 문서에서는 일반적인 SQL Server 최적화에 대해 모두 설명하지 않습니다. 자세한 내용은 다음 리소스를 참조하십시오.

저장소 최상의 방법 상위 10개(영문)(https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x412)
SQL Server 최상의 방법(영문)(https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x412)
RAID 수준 및 SQL Server(https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x412)

검색 쿼리 및 인덱스 기능 향상을 위한 SQL Server 최적화

대부분의 Office SharePoint Server 2007 관리자는 크롤링, 인덱스 및 쿼리의 최적화를 우선시합니다. Office SharePoint Server 콘텐츠 인덱스는 SQL Server 데이터베이스 외부의 파일 시스템에 저장됩니다. 그러나 검색 데이터베이스는 인덱스 파일 및 ACL의 메타데이터를 저장합니다. 결과적으로 SQL Server의 성능은 다음 2개의 검색 작업에 직접 영향을 줍니다.

Office SharePoint Server가 메타데이터 및 ACL을 저장하는 경우 인덱스 작업.
쿼리 작업. 모든 Office SharePoint Server 쿼리는 Office SharePoint Server가 검색 데이터베이스에서 ACL을 확인하고 사용자가 볼 수 있는 권한이 없는 결과를 제거하는 동안에 수행되는 보안 조정과 관련이 있습니다. 또한 사용자가 속성을 검색하는 경우 메타데이터는 검색 데이터베이스에서 검색되야 합니다.

이 문서의 앞부분에서 제공한 일반적인 SQL Server 최적화 권장 사항에 따라 시작해야 합니다. 또한 다음 섹션에 나온 최적화는 특별히 인덱스 및 쿼리 작업에 유용합니다.

tempdb 데이터베이스 성능 최적화

모든 사용자 쿼리는 SQL Server tempdb 데이터베이스의 작업과 관련이 있습니다. 따라서 이 데이터베이스의 구성은 사용자에게 쿼리 응답이 표시되는 속도에 직접적인 영향을 줍니다.

다음 단계에 따라 tempdb를 최적합니다.

복구 모델을 SIMPLE로 설정합니다.
tempdb 파일이 필요한 만큼 자동으로 확장될 수 있도록 설정합니다.
파일 확장 증분을 적절한 값으로 설정합니다. 일반적으로 이 증분은 tempdb 파일 크기의 약 10%여야 합니다.
크롤링 및 쿼리 중 모든 작업을 수용할 수 있는 값으로 파일 크기를 설정하여 tempdb 파일에 대한 공간을 미리 할당합니다.
여러 데이터 파일을 사용하여 디스크 대역폭을 최대화합니다. 일반적으로 SQL Server를 실행하는 컴퓨터의 각 CPU 코어에서 하나의 데이터 파일을 사용합니다.
각 데이터 파일을 동일하게 설정합니다.
콘텐츠 데이터베이스, 구성 데이터베이스 및 검색 데이터베이스를 저장하는 디스크와 다른 별도의 실제 디스크에 tempdb 데이터베이스를 배치합니다.

참고

tempdb 최적화에 대한 자세한 내용은 tempdb 성능 최적화(https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x412)를 참조하십시오.

파일 그룹을 사용하여 성능 향상

Office SharePoint Server 2007 크롤링 및 인덱스 프로세스는 I/O가 많이 발생하는 작업이기 때문에 검색 데이터베이스에 많은 양의 데이터를 쓰게 됩니다. 시스템에서 사용량이 적은 시간대가 설정되면 이때 인덱스를 실행하도록 예약하여 인덱스 작업과 사용자 쿼리 간에 리소스 경합이 발생하지 않도록 해야 합니다. 그러나 24시간 작업을 수행하는 조직이나 글로벌 조직에서는 사용량이 큰 차이를 보이지 않습니다. 검색 데이터베이스를 호스트하는 데이터베이스 서버가 해당 I/O 용량에 도달한 경우 사용자 쿼리와 연관된 작업에서 인덱스 I/O 작업을 분리하는 다른 방법을 고려해야 합니다.

검색 데이터베이스는 주로 사용자 쿼리와 관련된 테이블 및 인덱스와 관련된 테이블로 구분할 수 있습니다. 이 테이블 그룹을 2개의 실제 디스크로 분리하는 경우 인덱스가 쿼리 성능에 주는 영향을 최소화해야 합니다. 인덱스 및 쿼리 테이블이 하나의 데이터베이스가 있어도 Microsoft SQL Server 파일 그룹 기능을 사용하여 이와 같이 분리할 수 있습니다.

이렇게 하려면 데이터베이스에서 보조 데이터 파일을 포함하는 사용자 파일 그룹을 만듭니다. 성능을 향상시키려면 이 데이터 파일은 전용 실제 디스크에 있어야 합니다. 그리고 다음 절차에 따라 해당 파일 그룹에 인덱스와 관련된 테이블을 이동합니다. 검색 데이터베이스 크기에 따라 이 절차에 걸리는 시간이 길어질 수도 있습니다. 따라서 사용량이 적은 시간대에 이 절차를 수행하는 것이 좋습니다.

참고

테이블을 이동하는 Transact-SQL 스크립트를 포함하여 검색 데이터베이스에서 파일 그룹을 사용하는 방법에 대한 자세한 내용은 SQL 파일 그룹 및 검색(영문)(https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x412)을 참조하십시오.

전용 파일 그룹으로 인덱스 테이블을 분리하려면

SQL Server Management Studio에서 검색 데이터베이스를 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.
페이지 선택 목록에서 파일 그룹을 클릭합니다.
추가를 클릭하고 새 파일 그룹 이름을 “CrawlFileGroup”으로 지정합니다.
페이지 선택 목록에서 파일을 클릭합니다.
추가를 클릭하고 새 파일 이름을 지정합니다.
파일 그룹 셀에서 CrawlFileGroup을 선택합니다.
경로 셀에서 PRIMARY 파일 그룹과는 다른 실제 디스크에 있는 경로를 선택합니다.
확인을 클릭합니다.
SQL Server Management Studio에서 새 쿼리를 클릭합니다.

쿼리 창에 다음 쿼리를 복사한 다음 실행을 클릭합니다. 이 Transact-SQL 코드는 새 파일 그룹으로 테이블을 이동하는 새 저장 프로시저를 만듭니다.

IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup')
   BEGIN
      DROP  Procedure  dbo.proc_MoveTableToFileGroup
   END
GO
CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup]
(
   @fileGroup sysname,
   @tableName sysname
)
as
begin
   declare @data_space_id int
   declare @object_id int
   declare @index_id int
   declare @index_name sysname
   declare @object_name sysname
   declare @fileGroupName sysname
   declare @index_cols nvarchar(4000)
   declare @sql nvarchar(4000)
   declare @key_ordinal int
   set @index_id = 0
   set @key_ordinal = 0
   select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup
   if @data_space_id is null
   begin
      raiserror ('The specified filegroup does not exist.', 16, 1)
      return
   end
   while 1=1
   begin
      select top 1
            @object_id = i.object_id, 
            @index_id = i.index_id,
            @index_name = i.name,
            @object_name = o.name
         from 
            sys.indexes AS i
         inner join 
            sys.objects AS o
         ON
            i.object_id = o.object_id
         where 
            i.index_id > 0 and
            o.type = 'U' and
            o.name = @tableName and
            i.index_id > @index_id and
            i.data_space_id <> @data_space_id
         order by i.index_id
      if @@rowcount = 0 
      begin
         if @index_id = 0
            print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName
         break
      end
      set @index_cols = null
      set @key_ordinal = 0
      while 1=1
      begin
         select top 1 
            @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + 
            case when i.is_descending_key = 0 then ' asc' else 'desc' end, 
            @key_ordinal = i.key_ordinal
         from 
            sys.index_columns i 
         inner join 
            sys.columns as c
         on 
            i.object_id = c.object_id and
            i.column_id = c.column_id
         where 
            i.object_id = @object_id and 
            i.index_id = @index_id and 
            i.key_ordinal > @key_ordinal
         order by i.key_ordinal
         if @@rowcount = 0 
            break
      end
      select @sql = 
         case when i.is_primary_key = 1 then 
            N'begin try ' + 
            N'begin tran ' + 
            N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + 
            N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 
            'primary key ' +
            case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
            ' (' + @index_cols + ') ' + 
            'with (' +
            'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
            ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
            case when  i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + 
            ') ' + 
            'ON [' + @fileGroupName + ']' + 
            N' commit ' + 
            N'end try ' + 
            N'begin catch ' + 
            N'rollback ' + 
            N'end catch ' 
         else 
            N'create ' + 
            case when  i.is_unique = 1 then 'unique ' else '' end +
            case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
            'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 
            'with (' +
            'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
            ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
            case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 
            'ON [' + @fileGroupName + ']'
         end
from 
         sys.indexes AS i
      where 
         i.object_id = @object_id and
         i.index_id = @index_id
      print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName 
      print @sql
      print ''
      exec sp_executesql @sql
   end
end

SQL Server Management Studio에서 새 쿼리를 클릭합니다.

쿼리 창에 다음 쿼리를 복사한 다음 실행을 클릭합니다. 이 Transact-SQL 코드는 각 인덱스 테이블에서 새 저장 프로시저를 실행합니다.

declare @fileGroup sysname
set @fileGroup = 'CrawlFileGroup'
if not exists (select 1 from sys.filegroups where name = @fileGroup)
begin
   raiserror ('The specified filegroup does not exist.', 16, 1)
   return
end
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList'
begin try
   begin tran
   IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]'))
   ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory]
   exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory'
   ALTER TABLE [dbo].[MSSCrawlContent]  WITH CHECK ADD  CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID])
   REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID])
   commit
end try
begin catch 
   rollback
end catch
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'

검색 기능 향상을 위한 SQL Server 데이터베이스 유지 관리

다른 복잡한 시스템과 마찬가지로 SQL Server 데이터베이스는 최상의 성능을 유지하려면 정기적으로 유지 관리해야 합니다. 이 섹션에서는 최대 성능을 유지 관리하기 위한 몇 가지 권장되는 방법에 대해 설명합니다.

다음 디스크 유지 관리 절차를 통해 데이터베이스 서버 성능을 향상시킬 수 있습니다.

데이터베이스를 확장할 최소 25%의 사용 가능한 디스크 공간을 유지 관리합니다. 디스크 크기 및 사용 가능한 공간을 정기적으로 모니터링하여 이 비율에서 더 떨어지지 않도록 합니다. 관리자가 새 콘텐츠 원본을 추가하면 검색 데이터베이스 크기가 매우 빠르고 급격하고 늘어날 수 있습니다.
디스크 컨트롤러가 디스크 쓰기 캐시를 사용하는 경우 전원 장애로 서비스가 중단되지 않도록 백업 배터리가 있어야 합니다.

다음 SQL Server 유지 관리 절차를 통해 데이터베이스 서버 성능을 향상시킬 수 있습니다.

모든 Office SharePoint Server 데이터베이스에서 DBCC CHECKDBTransact-SQL 루틴을 실행합니다. 그러나 이 루틴은 SQL Server 컴퓨터에 상당한 부담을 주므로 응답 성능에 영향을 줄 수 있습니다. 따라서 PHYSICAL_ONLY 옵션을 사용하여 사용량이 적은 시간에 DBCC CHECKDB를 예약합니다. Office SharePoint Server 크롤링 중에는 이 루틴을 실행하지 않는 것이 좋습니다.
SQL Server를 실행하는 프로덕션 컴퓨터에서 지원되지 않은 작업을 수행하지 않습니다. 예를 들어 데이터베이스 정렬을 변경하거나 Office SharePoint Server 데이터베이스 테이블에 열을 추가하지 않습니다. 지원되지 않는 작업에 대한 자세한 내용은 Microsoft 기술 자료 문서 841057: Office 서버 제품 및 Windows SharePoint Services에서 사용하는 데이터베이스에 대한 변경 지원(https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x412)을 참조하십시오.

시간이 경과함에 따라 검색 데이터베이스를 지원하는 SQL Server 인덱스가 조각화되고 이로 인해 인덱스 및 쿼리 성능이 저하될 수 있습니다. Microsoft 기술 자료 문서 KB943345에는 저장 프로시저 proc_DefragmentIndices를 만드는 Transact-SQL 스크립트가 있습니다. proc_DefragmentIndices를 사용하면 Office SharePoint Server 팜에서 검색 및 콘텐츠 데이터베이스의 조각을 모을 수 있습니다. 그러나 이 저장 프로시저는 서버 리소스를 많이 사용하므로 쿼리 응답 성능이 저하되지 않도록 신중하게 사용해야 합니다.

참고

proc_DefragmentIndices 스크립트 및 사용에 대한 자세한 내용은 Windows SharePoint Services 3.0 데이터베이스 및 SharePoint Server 2007 데이터베이스의 조각을 모으는 방법(https://go.microsoft.com/fwlink/?linkid=105588&clcid=0x412)을 참조하십시오.

또한 특별히 Office SharePoint Server 검색 데이터베이스에서 사용하도록 만든 조각 모음 저장 프로시저 proc_DefragSearchIndexes를 사용할 수 있습니다. 이 저장 프로시저는 IX_MSSDocProps 및 IX_MSSDocSdids와 같이 성능을 최대화할 수 있는 인덱스의 조각만 모으며 데이터베이스 서버 리소스에 대한 요구를 최소화합니다. 이 저장 프로시저는 사용량이 적은 시간에 실행하도록 예약하고 사용자에게 미치는 영향을 신중하게 모니터링해야 합니다.

참고

proc_DefragSearchIndexes 스크립트 및 사용에 대한 자세한 내용은 Microsoft 엔터프라이즈 검색 블로그의 검색 기능 향상을 위한 SQL 인덱스 조각 모음 및 유지 관리(영문)(https://go.microsoft.com/fwlink/?linkid=158799&clcid=0x412)를 참조하십시오.

팜에 있는 데이터베이스 서버에서 디스크 또는 RAID 병목 현상을 진단한 경우 다음 작업을 수행하면 이러한 문제로 인해 발생하는 영향을 줄일 수 있습니다.

별도의 디스크 또는 RAID 배열에 데이터 파일 및 트랜잭션 로그를 재배치합니다. 이 문서의 앞부분에서 설명한 대로 파일 그룹을 사용하면 성능을 최대화할 수 있습니다.
RAID 배열에 디스크를 추가합니다.
속도가 느린 디스크를 더 빠른 디스크로 바꿉니다.

크롤러 기아 상태 방지

크거나 복잡한 조직에서 Office SharePoint Server 2007 인덱스 시스템을 구성하는 경우에는 해결해야 할 과제가 많습니다. 이러한 환경에서는 크롤링하는 데 시간이 많이 걸리는 매우 큰 콘텐츠가 포함된 다양한 종류의 여러 콘텐츠 원본이 존재할 수 있습니다. 또한 검색 결과가 최신 콘텐츠를 반영하도록 인덱스 항목의 상태를 최신으로 유지할 수 있게 신중하게 계획해야 합니다. 이처럼 인덱스 항목의 상태를 최신으로 유지하는 목표를 달성하려면 모든 콘텐츠를 정기적으로 크롤링하도록 인덱서의 성능을 최적화해야 합니다.

인덱스 속도를 떨어뜨리는 주된 원인은 크롤러의 기아 상태입니다. 크롤러가 큐에서 다음 문서를 가져올 다른 스레드를 할당할 수 없는 경우 기아 상태가 발생합니다. 기아 상태는 다음과 같은 경우에 발생할 수 있습니다.

검색 데이터베이스를 호스트하는 데이터베이스 서버에서 리소스 경합이 발생한 경우
크롤링에 참여하는 호스트가 너무 많은 경우
스레드를 신속하게 넘기지 않는 호스트인 경우(이 문서에서는 "리소스 과다 점유" 호스트라고 함)
백업을 크롤링과 동시에 실행하는 경우

리소스 과다 점유 호스트가 스레드를 잠그고 다음 문서로 이동하지 못하도록 하는 경우. 이 잠금은 다음 상황에서 발생할 수 있습니다.

CPU, 메모리 또는 기타 리소스가 부족하여 호스트 속도가 느려진 경우
증분 크롤링을 위해 호스트에 추가 작업이 필요한 경우. 예를 들어 원본이 Microsoft SharePoint Portal Server 2003 서버인 경우 사용 권한이 변경되면 크롤러는 전체 문서를 다시 처리해야 합니다.
속성이 많은 호스트 또는 문서인 경우. 각 문서에 대한 속성이 많으면 검색 데이터베이스를 호스트하는 데이터베이스 서버는 더 많은 작업을 수행해야 합니다. 일반적으로 비즈니스 데이터 카탈로그 콘텐츠 원본 및 내 사이트에는 속성이 많습니다.

보통 다음 종류의 호스트에서 크롤링이 가장 효과적으로 수행됩니다.

Office SharePoint Server 2007 서버. 이 서버에서는 크롤러가 사용할 수 있는 변경 로그를 유지 관리합니다.
파일 공유. 크롤러가 폴더 수준에서 변경 사항을 확인할 수 있으며 각 문서를 검사하지 않습니다.
Exchange 공용 폴더. 크롤러가 폴더 수준에서 변경 사항을 확인할 수 있으며 각 게시물을 검사하지 않습니다.

기아 상태 방지 지침

다음과 같은 최상의 방법을 통해 크롤러 기아 상태를 최소화할 수 있습니다.

콘텐츠 원본 수를 최소화합니다. 이렇게 하면 유사한 크기 및 유형의 호스트를 하나의 콘텐츠 원본으로 그룹화하여 효율성을 높일 수 있습니다.
다른 호스트 종류를 추가하기 전에 큰 Office SharePoint Server 2007 호스트를 먼저 크롤링합니다. 이러한 호스트는 효율적으로 크롤링 효율성이 뛰어나며 증분 크롤링 시 스레드가 매우 빠르게 해제됩니다.
리소스 과다 점유 호스트 크롤링을 동시에 둘 이상 예약하지 않습니다.
먼저 4개의 동시 크롤링을 예약합니다. 일부 인덱스 서버에서는 이 수를 늘릴 수도 있습니다. 자세한 내용은 이 문서의 다음 섹션을 참조하십시오.
크롤러에서 기아 상태가 발생하면 리소스 과다 점유 호스트에서 크롤링을 일시 중지하여 스레드를 해제합니다.

기아 상태 진단 방법

새 Office SharePoint Server 2007 검색 시스템을 설치하는 경우 여러 날 또는 여러 주에 걸쳐 새 콘텐츠 원본을 추가하여 크롤러 구성을 설정합니다. 기아 상태를 방지하고 문제를 쉽게 해결할 수 있도록 각 콘텐츠 원본을 추가할 때 시스템 성능을 모니터링합니다. 이렇게 하면 크롤링 중의 시스템 동작을 자세하게 파악할 수 있습니다.

크롤러가 사용하는 스레드 수는 인덱서 성능 설정에서 결정됩니다. 이 설정을 변경하려면 중앙 관리에서 작업 탭과 서버 제공 서비스를 차례로 클릭한 다음 Office SharePoint Server 검색을 클릭합니다. 다음 표에서는 인덱서 성능 설정이 크롤링 스레드를 제어하는 방법을 보여 줍니다.

인덱서 성능 설정	총 스레드 수	각 호스트의 최대 스레드 수
축소	프로세서 수	프로세서 수
일부 축소	프로세서 수의 4배	프로세서 수 + 4
최대값	프로세서 수의 16배	프로세서 수 + 4

Office SharePoint Server 2007에서 크롤링 스레드 수는 64개를 초과하지 않습니다.

기아 상태가 발생하는 가장 주된 원인은 데이터베이스 서버에서 리소스 경합이 발생하기 때문입니다. Archival 플러그 인을 모니터링하면 이 조건을 진단할 수 있습니다. 성능 모니터에서 Office Server Search Archival 플러그 인 개체와 Total docs in first queue 및 Total docs in second queue 카운터를 사용합니다. 이 카운터가 Portal_Content 인스턴스에서 모두 500이거나 ProfileImport 인스턴스에서 50인 경우 크롤러에서 기아 상태가 발생합니다. 이 문서의 앞부분에 나온 Office SharePoint Server 2007의 검색 성능 향상을 위한 SQL Server 최적화의 설명대로 데이터베이스 서버를 조정합니다.

Archival 플러그 인이 원인이 아닌 기아 상태는 성능 모니터의 Office Server Search Gatherer 개체에서 진단할 수 있습니다. Idle Threads, Threads Accessing Network 및 Threads In Plug-ins 카운터를 확인하고 이 값을 시스템의 총 스레드 수와 비교합니다. 이 카운터에 대한 자세한 내용은 이 문서의 앞부분에 나온 인덱스 서버 모니터링을 참조하십시오.

액세스 제어 목록으로 인한 병목 현상 방지

Office SharePoint Server 2007에서 콘텐츠 원본을 크롤링하고 인덱싱하는 경우 ACL(액세스 제어 목록)을 확인하고 이를 검색 데이터베이스에 저장합니다. 사용자가 인덱스를 검색하면 검색 데이터베이스가 각 결과에 대해 사용자에게 해당 결과에 액세스할 권한이 있는지를 확인합니다. 이 프로세스를 보안 조정이라고 합니다. 중첩 수준이 많은 큰 ACL은 Office SharePoint Server에서 크롤링 및 검색 모두 성능을 떨어뜨릴 수 있습니다. 이 섹션에서는 이러한 성능 저하를 최소화하는 방법에 대해 설명합니다.

Active Directory에서는 Office SharePoint Server 사이트 및 인덱스 콘텐츠의 보안을 유지하는 데 사용할 수 있는 다음과 같은 보안 계정을 제공합니다.

사용자 계정
글로벌 그룹
도메인 로컬 그룹
유니버설 그룹

Office SharePoint Server 2007에서는 SharePoint 그룹도 있어야 합니다. 이 시스템은 매우 유연하며 여러 계층의 중첩을 포함할 수 있습니다. 그러나 보안 계정은 Office SharePoint Server 검색 성능을 떨어뜨릴 수도 있습니다.

Office SharePoint Server 2007 크롤러 및 검색 성능을 최대화하려면 Active Directory 보안 계정 및 SharePoint 그룹을 사용할 때 다음 규칙을 준수합니다.

사용자 그룹을 글로벌 그룹에 배치하고 글로벌 그룹을 도메인 로컬 그룹에 배치합니다. 그리고 도메인 로컬 그룹에 사용 권한을 할당합니다. 이 방법은 Active Directory에서 보안 계정을 사용할 때 권장되는 최상의 방법입니다. 이렇게 하면 도메인 컨트롤러가 그룹 등록을 빠르게 검색할 수 있고 사용자가 해당 포리스트의 리소스에 액세스할 수 있습니다.
유니버설 그룹이 필요한 경우 동일한 시스템을 사용하되, 글로벌 그룹을 유니버설 그룹에 배치하고 유니버설 그룹을 도메인 로컬 그룹에 배치합니다.
도메인 로컬 그룹을 SharePoint 그룹에 배치하여 SharePoint 사이트 및 기타 리소스에 대한 사용 권한을 할당합니다.
그룹 등록에 사용되는 중첩 수준 수를 제한합니다.

다음과 같은 상황은 Office SharePoint Server 2007 검색 성능을 떨어뜨릴 수 있으므로 피해야 합니다.

Office SharePoint Server 사이트 사용 권한을 개별 사용자에게 할당하지 않습니다.

사이트 DACL에 보안 계정이 2,000개 넘게 표시되면 Office SharePoint Server 사이트 속도가 느려집니다. 그러나 Active Directory 또는 SharePoint 그룹에서는 포함하는 사용자 수에 상관없이 보안 계정이 하나입니다. 따라서 SharePoint 그룹을 사용하여 사이트 사용 권한을 할당하고 사용자 또는 Active Directory 그룹을 SharePoint 그룹으로 배치합니다.
중첩 수준이 많은 Active Directory 보안 그룹을 사용하지 않습니다.

사용자가 Office SharePoint Server 사이트에 액세스하려고 하면 서버는 사용자에게 권한을 부여하기 위해 그룹 등록을 평가해야 합니다. 그룹의 중첩 수준이 많은 경우 도메인 컨트롤러에 대해 많은 쿼리가 수행되어야 합니다. 또한 포리스트에 원격 도메인이 필요할 수도 있습니다. 이 쿼리는 사용자에게 액세스 권한을 부여하기 전에 완료되어야 합니다.
연락처를 포함하는 메일 그룹 또는 보안 그룹을 사용하지 않습니다.

Active Directory의 연락처는 전자 메일을 배포하기 위해 그룹에 추가할 수 있습니다. 그러나 연락처는 보안 계정이 아니며 권한 부여와 관련이 없습니다. 따라서 연락처를 포함하는 그룹에 사용 권한을 할당하면 성능이 저하될 수 있습니다.

Office SharePoint Server 2007에서 각 사이트 소유자는 사이트 DACL에 사용자 및 그룹을 추가할 수 있습니다. 따라서 사이트 소유자에게 그룹 등록을 사용하여 병목 현상을 방지하는 방법을 알려주는 것이 좋습니다.

누락된 검색 상자 웹 파트 문제 해결

검색 상자 웹 파트는 다음 상황에서 검색 센터 및 다른 Office SharePoint Server 2007 사용자 인터페이스에 나타나지 않습니다.

개발자가 검색 상자 웹 파트를 숨기거나 제거하도록 검색 센터 콘텐츠 페이지 또는 사이트 마스터 페이지를 수정한 경우
사이트에서 모든 권한 또는 디자인 권한 수준이 부여된 사용자가 검색 상자 웹 파트를 제거하거나 숨긴 경우
검색 서비스가 중단되었거나 관리자가 오프라인으로 설정하여 Office SharePoint Server 팜에서 검색 서비스를 사용할 수 없는 경우

참고

검색 상자 웹 파트에 대한 자세한 내용은 검색 상자 웹 파트 속성 구성(Office SharePoint Server 2007)을 참조하십시오.

참고 항목

개념

Office SharePoint Server 2007 문제 해결
Office SharePoint Server의 검색에 대한 최상의 방법