|
| Sun ONE Directory Server 5.2 설치 및 조정 설명서 |
Directory Server는 클라이언트 요청에 보다 신속하게 응답할 수 있도록 디렉토리 정보를 메모리와 디스크에 캐시합니다. 캐싱을 적절히 조절하면 클라이언트 요청을 처리할 때 디스크 하위 시스템에 대한 액세스를 최소화할 수 있습니다.
주 캐시가 제대로 조정 및 작동되지 않으면 다른 조정 작업도 성능에 큰 도움이 되지 않습니다.
캐시 종류
Directory Server는 표 6-1에 설명된 것처럼 세 가지 종류의 캐시를 처리합니다.
Directory Server는 기본 운영 체제에서 처리하는 파일 시스템과 디스크 하위 시스템의 입출력 버퍼도 사용합니다.
그림 6-1은 자체 항목 캐시가 있는 접미사 세 개를 처리하는 Directory Server 인스턴스의 캐시를 보여줍니다. 이 인스턴스는 8장 "로깅 조정"에 설명된 것처럼 트랜잭션 로그, 데이터베이스 및 기타 파일과 로그를 별도의 디스크 하위 시스템에 저장하여 중요한 디스크 작업을 처리하도록 구성되어 있습니다.
그림 6-1 특정 인스턴스의 항목 캐시와 데이터베이스 캐시
데이터베이스 캐시
각 Directory Server 인스턴스에는 한 개의 데이터베이스 캐시가 있습니다. 데이터베이스 캐시는 색인과 항목이 있는 데이터베이스의 페이지를 저장합니다. 각 페이지는 항목이 아니라 데이터베이스 일부가 포함된 메모리 조각입니다. 데이터베이스 캐시 크기(nsslapd-dbcachesize)는 사용자가 지정합니다. 데이터베이스 캐시 공간은 서버를 시작할 때 할당되기 때문에 데이터베이스 캐시 크기의 변경 사항은 서버를 다시 시작한 후에 적용됩니다.
Directory Server는 최대 데이터베이스 캐시 크기를 유지하기 위해 데이터베이스 파일과 데이터베이스 캐시 간에 페이지를 이동합니다. 데이터베이스 캐시 자체를 관리하기 위한 메모리가 추가로 필요하므로 Directory Server에서 데이터베이스 캐시에 사용하는 실제 메모리 양은 지정한 크기보다 최대 25%까지 늘어날 수 있습니다.
대규모 데이터베이스 캐시를 사용하는 경우, Solaris 시스템에서는 pmap(1) 유틸리티와 같은 도구로 메모리 사용을 모니터하고 실제로 테스트함으로써 Directory Server의 메모리 사용량이 사용 가능한 물리적 메모리 크기를 초과하지 않도록 하십시오. 사용할 수 있는 물리적 메모리를 초과하면 시스템이 반복해서 페이징을 시작하므로 성능이 크게 저하됩니다.
Directory Server에서 지원하는 UNIX 플랫폼의 ps(1) 유틸리티를 -p pid 및 -o format 옵션과 함께 사용하여 Directory Server와 같은 특정 프로세스에서 현재 사용하는 메모리를 볼 수도 있습니다(ns-slapd). Windows 시스템에서는 "작업 관리자"의 "프로세스" 탭 페이지에 프로세스 당 메모리 사용량이 표시됩니다(slapd.exe). 자세한 내용은 운영 체제 설명서를 참조하십시오.
실제로 32비트 서버에서는 데이터베이스 캐시 크기를 2GB 이하로 제한해야 합니다.
주 Windows 및 AIX 플랫폼에서는 데이터베이스 캐시에 1GB(1,073,741,824 바이트) 이상 할당하지 마십시오.
nsslapd-dbcachesize 값의 올바른 범위에 대한 자세한 내용은 Sun ONE Directory Server Reference Manual을 참조하십시오.
항목 캐시
항목 캐시에는 클라이언트 응용 프로그램에 전달할 수 있도록 서식이 지정된 최근 액세스 항목이 저장됩니다. 접미사의 항목 캐시 크기(nsslapd-cachememsize)와 최대 항목 수(nsslapd-cachesize)는 사용자가 지정합니다. 항목 캐시는 필요에 따라 할당할 수 있습니다.
항목 캐시에 저장된 항목은 이미 서식이 지정되어 있으므로 Directory Server는 항목 캐시의 항목을 매우 효율적으로 반환할 수 있습니다. 데이터베이스 항목은 원시 바이트 문자열로 저장되며 클라이언트 응용 프로그램에 전달하기 전에 서식을 지정하고 항목 캐시에 저장해야 합니다.
항목 캐시 크기를 지정하는 경우 nsslapd-cachememsize는 Directory Server가 기본 메모리 할당 라이브러리에서 요청하는 메모리 양을 나타냅니다. 메모리 할당 라이브러리에서 이러한 요청을 처리하는 방법에 따라 실제 사용되는 메모리는 Directory Server가 항목 캐시에 최종적으로 사용할 수 있는 메모리 양보다 훨씬 클 수 있습니다.
Directory Server 프로세스에 사용되는 실제 메모리는 주로 사용된 메모리 할당 라이브러리와 캐시된 항목에 따라 결정됩니다. 작은 속성 값을 가진 다수의 항목이 큰 속성 값을 가진 소수의 항목보다 오버헤드가 큽니다.
실제로 32비트 서버에서는 항목 캐시 크기를 2GB 이하로 제한해야 합니다.
주 AIX 플랫폼에서는 Directory Server가 maxdata = 0x50000000으로 작성되기 때문에 데이터베이스 캐시와 항목 캐시에 각각 1GB를 할당할 수 있습니다. maxdata 값을 변경해야 하면 Sun ONE 지원 담당자에게 문의하십시오.
nsslapd-cachememsize 및 nsslapd-cachesize 값의 올바른 범위에 대한 자세한 내용은 Sun ONE Directory Server Reference Manual을 참조하십시오.
가져오기 캐시
가져오기 캐시는 대량 로드 또는 가져오기라고도 하는 접미사 초기화 중에만 작성되어 사용됩니다. 배포 시 offline 접미사 초기화만 사용하는 경우 가져오기 캐시와 데이터베이스 캐시는 사용되지 않으므로 "총 캐시 크기"에 설명된 것처럼 총 캐시 크기를 계산할 때 이 두 항목을 추가할 필요가 없습니다. 가져오기 캐시 크기(nsslapd-import-cachesize)는 사용자가 지정합니다. 가져오기 캐시는 초기화에 할당된 다음 초기화 후에 해제되기 때문에 가져오기 캐시 크기를 변경하면 다음에 접미사를 재설정하여 초기화할 때 적용됩니다.
Directory Server는 데이터베이스 캐시와 같은 방식으로 가져오기 캐시를 처리합니다. 따라서 스와핑을 방지하려면 사용할 수 있는 물리적 메모리가 충분한지 확인해야 합니다.
실제로 32비트 서버에서는 가져오기 캐시 크기를 2GB 이하로 제한해야 합니다. nsslapd-import-cachesize 값의 올바른 범위에 대한 자세한 내용은 Sun ONE Directory Server Reference Manual을 참조하십시오.
파일 시스템 캐시
운영 체제는 사용할 수 있는 메모리 중 Directory Server 캐시와 기타 응용 프로그램에서 사용하지 않는 메모리는 파일 시스템 캐시에 할당합니다. 이 캐시에는 디스크에서 최근에 읽은 데이터가 저장되므로 이후 요청은 디스크에서 다시 데이터를 읽을 필요 없이 캐시에서 복사된 데이터를 가져올 수 있습니다. 메모리 액세스가 디스크 액세스보다 훨씬 빠르기 때문에 파일 시스템 캐시에서 사용할 수 있는 물리적 메모리를 남겨 두면 성능이 향상됩니다.
파일 시스템 캐시에 대한 자세한 내용은 운영 체제 설명서를 참조하십시오.
총 캐시 크기
동시에 사용되는 모든 캐시의 합계는 사용할 수 있는 물리적 메모리의 전체 크기보다 파일 시스템 캐시에 할당된 메모리만큼 작아야 합니다. 따라서 실제로 32비트 서버에서는 총 캐시 크기를 2GB 이하로 제한해야 합니다. 사용되는 총 캐시는 지정한 크기보다 훨씬 늘어날 수 있습니다. 캐시 크기 및 Directory Server 프로세스 크기가 사용 가능한 물리적 메모리를 초과하지 않도록 설정하는 방법은 "데이터베이스 캐시"를 참조하십시오.
주 Windows 플랫폼에서 응용 프로그램이 사용할 수 있는 최대 주소 공간은 2GB입니다. 총 캐시 크기가 이 제한을 초과하면 Directory Server는 오류 메시지를 표시하고 종료됩니다.
Directory Server가 온라인 상태일 때 접미사를 초기화(대량 로드)하는 경우 데이터베이스 캐시, 항목 캐시 및 가져오기 캐시 크기의 합계는 사용 가능한 물리적 메모리의 전체 크기보다 작아야 합니다.
표 6-2 접미사 초기화(가져오기) 작업 및 캐시 사용 여부
캐시 종류
오프라인 가져오기
온라인 가져오기
데이터베이스
아니요
예
항목
예
예
가져오기
예
예
Directory Server가 중지된 상태에서 모든 접미사 초기화를 오프라인으로 수행하면 이러한 제한을 해결할 수 있습니다. 이 경우 가져오기 캐시와 데이터베이스 캐시가 함께 사용되지 않으므로 오프라인 접미사 초기화에서는 가져오기 캐시에, 온라인 사용에서는 데이터베이스 캐시에 같은 메모리를 할당할 수 있습니다. 하지만 이런 특수한 경우를 구현하려면 작업 시스템에서 다른 사용자가 온라인 대량 로드를 수행하지 않도록 해야 합니다. 이 경우에도 동시에 사용되는 캐시의 합계는 사용 가능한 물리적 메모리의 전체 크기보다 작아야 합니다.
검색 시 캐시 사용 방법
그림 6-2는 Directory Server에서 어떻게 기본 DN을 지정한 검색과 필터를 사용한 검색을 모두 처리하는지 보여줍니다. 각각의 선은 여러 수준의 메모리를 액세스하는 스레드를 나타내고 점선은 효과적인 조정을 통해 캐시 사용을 최소화하는 단계를 나타냅니다.
그림 6-2 검색 및 캐시
기본 검색 프로세스
그림에 표시된 것처럼 기본 검색(기본 DN을 지정한 검색)은 Directory Server에서 처리되는 가장 간단한 검색 유형입니다. 이 검색을 처리하기 위해 Directory Server는 다음과 같은 작업을 수행합니다.
- 항목 캐시에서 지정된 기본 DN의 항목을 검색하려고 시도합니다.
항목을 찾으면 Directory Server는 후보 항목이 검색에 제공된 필터와 일치하는지 확인합니다.
항목이 일치하면 Directory Server는 서식이 지정된 캐시 항목을 신속하게 클라이언트 응용 프로그램으로 반환합니다.
- 데이터베이스 캐시에서 항목을 검색하려고 시도합니다.
항목을 찾으면 Directory Server는 이 항목을 접미사의 항목 캐시에 복사한 다음, 항목 캐시에서 찾은 것처럼 처리합니다.
- 데이터베이스 자체에서 항목을 검색하려고 시도합니다.
항목을 찾으면 Directory Server는 이 항목을 데이터베이스 캐시에 복사한 다음, 데이터베이스 캐시에서 찾은 것처럼 처리합니다.
하위 트리 및 one-level 검색 프로세스
역시 그림 6-2에 표시된 것처럼 하위 트리 또는 트리의 한 수준에서 검색하려면 항목 집합을 처리하는 추가 작업이 필요합니다. 이 검색을 처리하기 위해 Directory Server는 다음과 같은 작업을 수행합니다.
- 데이터베이스 캐시의 색인을 사용하여 필터와 일치하는 후보 항목 집합을 구성하려고 시도합니다.
적절한 색인이 없으면 데이터베이스 자체 항목에서 후보 항목 집합을 생성해야 합니다.
- 다음과 같은 방법으로 각 후보 항목을 처리합니다.
- 기본 검색을 수행하여 항목을 검색합니다.
- 이 항목이 검색에 제공된 필터와 일치하는지 확인합니다.
- 항목이 필터와 일치하면 클라이언트 응용 프로그램으로 반환합니다.
이렇게 하면 Directory Server에서 메모리에 후보 항목 집합을 구성할 필요가 없습니다.
Directory Server를 조정하기 전에 예상되는 검색 유형을 알고 있다면 가장 바람직하겠지만 실제 테스트를 통해 가정을 확인하는 것도 한 가지 대안이 될 수 있습니다.
업데이트 시 캐시 사용 방법
그림 6-3은 Directory Server에서 어떻게 업데이트를 처리하는지 보여줍니다. 각각의 선은 여러 수준의 메모리를 액세스하는 스레드를 나타내고 점선은 효과적인 조정을 통해 캐시 사용을 최소화하는 단계를 나타냅니다.
그림 6-3 업데이트 및 캐시
업데이트는 검색보다 많은 처리가 필요합니다. 업데이트를 처리하기 위해 Directory Server는 다음과 같은 작업을 수행합니다.
- 기본 DN 검색을 수행하여 업데이트할 항목을 검색하거나 추가 작업인 경우 해당 항목이 확실히 없는지 확인합니다.
- 데이터베이스 캐시를 변경하고 특히 업데이트로 영향을 받는 색인을 업데이트합니다.
업데이트로 영향을 받는 데이터가 데이터베이스 캐시에 로드되어 있지 않으면 해당 데이터가 캐시에 로드되는 동안 이 단계에서 디스크 작업이 수행될 수 있습니다.
- 변경 사항을 트랜잭션 로그에 쓰고 이 정보가 디스크로 플러시될 때까지 기다립니다.
자세한 내용은 "트랜잭션 로깅"을 참조하십시오.
- 업데이트된 항목의 서식을 지정하고 접미사의 항목 캐시에 복사합니다.
- 업데이트 성공 확인 메시지를 클라이언트 응용 프로그램으로 반환합니다.
접미사 초기화 시 캐시 사용 방법
그림 6-4는 Directory Server에서 어떻게 접미사 초기화(대량 로드 가져오기)를 처리하는지 보여줍니다. 각각의 선은 여러 수준의 메모리를 액세스하는 스레드를 나타내고 점선은 효과적인 조정을 통해 캐시 사용을 최소화하는 단계를 나타냅니다.
그림 6-4 접미사 초기화(대량 로드) 및 캐시
접미사를 초기화하기 위해 Directory Server는 다음과 같은 작업을 수행합니다.
- 버퍼로 사용되는 항목 캐시에 LDIF 항목을 공급하는 스레드를 시작합니다.
- 영향을 받는 각 색인에 대한 스레드와 가져오기 캐시에 항목을 작성하는 스레드를 시작합니다. 이 스레드는 항목 캐시에 공급된 항목을 사용합니다.
- 가져오기 캐시가 부족하면 데이터베이스 파일에서 읽고 씁니다.
Directory Server는 접미사 초기화 중에 로그 메시지를 쓸 수도 있지만 트랜잭션 로그에는 쓰지 않습니다.
Directory Server와 함께 제공되는 ldif2db(/usr/sbin/directoryserver ldif2db)와 같은 접미사 초기화 도구는 캐시 적중률과 가져오기 처리량에 관한 피드백을 제공합니다. 캐시 적중률과 가져오기 처리량이 모두 감소하면 가져오기 캐시가 너무 작은 것이므로 가져오기 캐시 크기를 증가시키는 것이 좋습니다.
검색 최적화
최상의 성능을 내려면 최대한 많은 디렉토리 데이터를 메모리에 캐시하십시오. 디렉토리가 디스크에서 정보를 읽지 않도록 차단하면 디스크 입출력 병목이 감소합니다. 디렉토리 트리 크기, 사용할 수 있는 메모리 양, 사용되는 하드웨어 등에 따라 여러 가지 방법으로 이 작업을 수행할 수 있습니다. 검색 성능을 최적화하기 위해 배포에 따라 항목 캐시와 데이터베이스 캐시에 할당하는 메모리 양을 늘리거나 줄일 수도 있습니다. 아니면 다른 서버의 Directory Server 소비자에 검색을 분산하도록 선택할 수 있습니다.
메모리에 모든 항목과 색인 저장
최적의 경우를 가정해 보십시오. 사용할 수 있는 물리적 메모리가 데이터베이스 캐시와 항목 캐시를 모두 저장하기에 충분합니다. 항목 캐시는 디렉토리에 있는 모든 항목을 저장할 수 있고 데이터베이스 캐시는 최소한 모든 색인을 저장할 수 있을 정도로 큽니다. 이 경우 캐시에서 모든 항목을 찾을 수 있으므로 Directory Server는 파일 시스템 캐시나 디스크에서 항목을 검색할 필요가 없습니다.
하지만 업데이트 후에도 데이터베이스 색인이 모두 데이터베이스 캐시에 저장될 수 있는지 확인해야 합니다. 데이터베이스 캐시에 색인을 저장할 공간이 부족하면 Directory Server는 검색 요청이 있을 때마다 디스크에서 색인을 읽어야 하기 때문에 처리량이 크게 감소합니다. 그림 6-5와 같이 Directory Server 콘솔의 "상태" 탭에는 적중률과 기타 유용한 정보가 표시됩니다.
그림 6-5 Directory Server 콘솔에서 캐시 적중률 모니터
혹은 명령줄에서 아래 명령으로 검색을 실행하여 페이징 및 캐시 작업을 모니터할 수 있습니다.
$ ldapsearch -D admin -w password \
-b cn=monitor,cn=database_name,cn=ldbm database,cn=plugins,cn=config데이터베이스 캐시에 .db3 파일의 데이터베이스 색인을 모두 저장하는 데 필요한 메모리 양을 대략적으로 추정하려면 아래 수식을 사용합니다. 사진과 같은 큰 이진 속성이 없는 일반 항목과 기본 색인 구성을 사용하는 경우 이 수식으로 상당히 정확한 결과를 얻을 수 있습니다.
nsslapd-dbcachesize = 1.2 x SUMall .db3 files (파일 크기)
항목 캐시에 모든 항목을 저장하는 데 필요한 메모리 양과 항목 캐시의 슬롯 수를 대략적으로 추정하려면 아래 수식을 사용합니다. 사진과 같은 큰 이진 속성이 없는 일반 항목과 기본 색인 구성을 사용하는 경우 다시 이 수식으로 상당히 정확한 결과를 얻을 수 있습니다.
nsslapd-cachesize = 4.5 x (LDIF의 항목 수)
nsslapd-cachememsize = 3.8 x (id2entry.db3 파일 크기)
실제 테스트를 통해 추정 값을 확인하고 정정합니다. 특히 항목 캐시는 할당된 양보다 훨씬 많은 메모리를 사용할 수 있습니다.
충분한 메모리, 32비트 Directory Server
항목 캐시와 데이터베이스 캐시에 모든 데이터를 저장하기에 충분한 메모리가 있지만 64비트 Directory Server 프로세스를 지원하지 않는 시스템을 가정해 보십시오. 예를 들어, 하드웨어 제약 조건 때문에 Solaris 시스템에 배포할 수 없는 경우 32비트 프로세스의 메모리 제한을 고려하여 적절하게 캐시 크기를 지정하고 파일 시스템 캐시에 사용할 수 있는 메모리를 남겨 두는 것이 중요합니다.
주 파일 시스템 캐시는 시스템에서 실행되는 다른 프로세스, 특히 파일 기반의 작업과 공유됩니다. 따라서 Directory Server 전용이 아닌 시스템에서는 특히 다른 캐시보다 제어하기가 어렵습니다.
시스템에서 파일 시스템 캐시를 다른 프로세스에 재할당할 수도 있습니다.
메모리 축소, 일부 파일 시스템 캐시 사용
항목 캐시와 데이터베이스 캐시에 모든 데이터를 저장하기에는 불충분하지만 상당량의 가용 메모리가 있는 시스템을 가정해 보십시오. 이 경우 항목 캐시와 데이터베이스 캐시 크기의 합계가 사용할 수 있는 물리적 메모리를 초과함으로써 잦은 가상 메모리 페이징이 발생하여 시스템이 거의 중단되는 상황이 발생하지 않도록 해야 합니다.
항목 캐시와 데이터베이스 캐시 크기를 500KB 정도로 낮게 설정하여 파일 시스템 캐시에서 사용할 수 있는 메모리를 남겨 두는 것이 좋습니다. 이렇게 하면 Directory Server는 디스크의 항목과 색인을 반복해서 읽을 필요 없이 파일 시스템 캐시에 저장된 데이터만으로 검색을 끝낼 수 있습니다.
혹은 어느 정도의 검색 패턴이 있을 경우 특정 배포의 검색이 대부분 디렉토리 항목 중 소규모의 동일 집합에 액세스하므로 이러한 검색용으로 항목과 색인을 캐시할 때 얻는 이점이 이례적인 검색 요청을 처리할 때의 손실을 상쇄한다는 가정 하에 항목 캐시와 데이터베이스 캐시를 더 크게 설정할 수도 있습니다. 실제 테스트를 통해 가정을 확인하고 정정합니다.
메모리 축소, 파일 시스템 캐시 축소
항목 캐시와 데이터베이스 캐시에 모든 데이터를 저장할 수 없을 뿐만 아니라 파일 시스템 캐시에 데이터를 캐시할 수 있는 메모리도 부족한 시스템을 가정해 보십시오. 이 경우 사용할 수 있는 메모리를 최대한 활용해야 합니다.
항목 캐시와 데이터베이스 캐시 크기를 가능한 한 작게 설정하여 파일 시스템 캐시에서 사용할 수 있는 메모리를 최대한 많이 남겨 두십시오. 파일 시스템 캐시에 메모리를 남겨 두면 최소한 항목이 3에서 4.5의 계수로 데이터베이스나 항목으로 확장되는 것을 방지할 수 있으므로 이론상 디스크 입출력 작업이 감소합니다. 특정 배포에 대해 실제 테스트를 수행하여 이 가정을 확인합니다.
업데이트 최적화
최상의 업데이트 성능을 내려면 먼저 발견되는 모든 트랜잭션 로그 병목을 제거합니다. 자세한 내용은 "트랜잭션 로깅"을 참조하십시오.
그런 다음, 메모리의 업데이트를 처리하기에 충분한 메모리를 데이터베이스 캐시에 할당하여 디스크 작업을 최소화합니다. Directory Server 콘솔에서 적중률을 읽어 데이터베이스 캐시의 효율성을 모니터할 수 있습니다. 그림 6-5와 같이 Directory Server 콘솔의 "상태" 탭에는 접미사 적중률이 표시됩니다.
또한, 파일 시스템 캐시용으로 상당량의 가용 메모리를 남겨 두십시오. Directory Server를 일정 시간 동안 실행하면 디스크 읽기가 필요 없을 정도의 충분한 항목과 색인이 파일 시스템 캐시에 저장될 것입니다. 메모리의 데이터베이스 캐시가 크면 데이터가 자주 플러시되지 않으므로 메모리의 데이터베이스 캐시를 업데이트할 때 성능이 저하됩니다.
데이터를 디스크로 플러시하는 것도 병목이 될 수 있으므로 Sun StorEdge™ 디스크 어레이와 같은 별도의 RAID 시스템에 데이터베이스를 저장하여 업데이트 성능을 향상시킬 수 있습니다. Solaris 시스템에서는 iostat(1M)와 같은 유틸리티를 사용하여 잠재적인 입출력 병목을 확인할 수도 있습니다. Windows 시스템에서 입출력 병목을 처리하는 방법은 Windows 도움말을 참조하십시오.
캐시 초기화 및 모니터
캐시 초기화란 이후의 Directory Server 동작이 램프 업(ramp up)이 아니라 정상적인 작동 성능을 반영하도록 캐시에 데이터를 채우는 것을 의미합니다. 잠재적인 최적화를 측정하고 분석하기 전에 캐시를 초기화하십시오.
ldapsearch 유틸리티를 사용하여 접미사의 항목 캐시를 초기화합니다. 예를 들어 아래 명령을 실행합니다.
$ ldapsearch -D directoryManager -w password -b suffix objectclass=\* > /dev/null
검색을 수행하여 데이터베이스 캐시를 초기화하고 특히 캐시에 색인을 로드합니다. (mail=*)와 같은 필터를 사용하여 검색하면 실재 색인을 초기화할 수 있습니다. 다른 색인을 초기화하려면 색인화할 각 속성의 가능한 모든 값을 검색하는 필터 형식을 적용하여 Sun ONE Directory Server Resource Kit searchrate 유틸리티를 사용해 보십시오. 예를 들어 mail 속성에 대한 동일 검색의 성능을 확인하려면 각 전자 우편 주소 줄에 한 개의 전자 우편 주소가 있는 파일을 생성한 다음 searchrate 유틸리티를 사용하여 이 파일로 검색합니다. 예를 들어 아래 명령을 실행합니다.
$ searchrate -b suffix -f "(mail=%s)" -i mail.file -K -t 10
시간을 절약하려면 -K 옵션과 -t 옵션을 사용하는 것이 좋습니다. searchrate 유틸리티를 -K 옵션과 함께 사용하면 연결을 계속 열어두기 때문에 검색할 때마다 바인드되지 않고 한 번만 바인드됩니다. -t 옵션을 사용하면 사용할 스레드 수를 지정할 수 있습니다. searchrate 유틸리티에 대한 자세한 내용은 Sun ONE Directory Server Resource Kit 설명서를 참조하십시오. Sun ONE Directory Server Resource Kit는 "Directory Server 도구 다운로드"에 설명된 방법으로 구할 수 있습니다.
다른 캐시를 초기화한 후에 사용 가능한 파일 시스템 캐시를 초기화할 수 있습니다. 파일 시스템 캐시를 초기화할 경우 파일 시스템 캐시의 정보가 플러시되지 않도록 차단할 수는 없지만 램프 업(ramp up) 시간을 향상시킬 수 있습니다. UNIX 시스템에서 파일 시스템 캐시를 초기화하려면 수퍼유저로 dd(1M) 명령을 사용할 수 있습니다. 데이터베이스 파일이 기본 위치에 저장되어 있는 Solaris 시스템에서는 아래 명령을 실행합니다.
# for db in ServerRoot/slapd-serverID/db/*/*.db3
> do
> dd if=?wd?$db of=/dev/null bs=512k
> done
0+1 records in
0+1 records out
...캐시를 초기화한 후 테스트를 수행하여 캐시 조정으로 원하는 결과를 달성했는지 여부를 모니터할 수 있습니다. 그림 6-5와 같이 Directory Server 콘솔의 "상태" 탭에서 "접미사" 노드를 선택하면 캐시 모니터 정보가 표시됩니다. 혹은 명령줄에서 아래 명령으로 검색을 실행하여 페이징 및 캐시 작업을 모니터할 수 있습니다.
$ ldapsearch -D admin -w password \
-b cn=monitor,cn=database_name,cn=ldbm\ database,cn=plugins,cn=config데이터베이스 캐시가 충분히 크고 캐시가 초기화되면 적중률(dbcachehitratio)은 높고, 읽는 페이지 수(dbcachepagein)와 기록되는 클린 페이지 수(dbcacheroevict)는 작아야 합니다. 여기서 "높음"과 "낮음"은 배포 제약 조건에 상대적인 의미로 이해해야 합니다.
접미사 항목 캐시가 충분히 크고 캐시가 초기화되면 적중률(entrycachehitratio)이 높아야 합니다. 항목 캐시 크기(currententrycachesize)는 최대 크기(maxentrycachesize)의 80% 이하여야 합니다. 마지막으로 항목 크기(currententrycachecount)는 접미사의 총 항목 수와 같거나 비슷해야 합니다.
기타 최적화
캐시 크기 조정은 검색, 업데이트 또는 대량 로드 속도를 향상시키는 방법 중 하나입니다. 캐시를 조정하면 캐시의 성능 병목이 시스템의 다른 부분으로 이동합니다. 자세한 내용은 본 설명서의 다른 장을 참조하십시오.