다음을 통해 공유

ADDS 성능 튜닝의 LDAP 고려 사항

  • 아티클

Important

다음은 Active Directory 도메인 Services용 용량 계획 문서에서 자세히 설명하는 Active Directory 워크로드용 서버 하드웨어를 최적화하기 위한 주요 권장 사항 및 고려 사항에 대한 요약입니다. 독자는 이러한 권장 사항의 기술적 이해와 의미를 높이기 위해 Active Directory 도메인 서비스에 대한 용량 계획을 검토하는 것이 좋습니다.

LDAP 쿼리 확인

LDAP 쿼리가 효율적인 쿼리 만들기 권장 사항을 준수하는지 확인합니다.

ACTIVE Directory에 사용할 쿼리를 올바르게 작성, 구성 및 분석하는 방법에 대한 MSDN에 대한 광범위한 설명서가 있습니다. 자세한 내용은 보다 효율적인 Microsoft Active Directory 사용 애플리케이션 만들기를 참조 하세요.

LDAP 페이지 크기 최적화

클라이언트 요청에 대한 응답으로 여러 개체가 있는 결과를 반환하는 경우 do기본 컨트롤러는 결과 집합을 일시적으로 메모리에 저장해야 합니다. 페이지 크기를 늘리면 메모리 사용량이 늘어나고 항목이 불필요하게 캐시에서 제거될 수 있습니다. 이 경우 기본 설정이 최적입니다. 페이지 크기 설정을 늘리기 위해 권장 사항이 만들어진 몇 가지 시나리오가 있습니다. 특별히 부적절한 것으로 식별되지 않는 한 기본값을 사용하는 것이 좋습니다.

쿼리에 많은 결과가 있는 경우 동시에 실행되는 유사한 쿼리의 제한이 발생할 수 있습니다. 이는 LDAP 서버가 쿠키 풀이라고 하는 전역 메모리 영역을 고갈시킬 수 있기 때문에 발생합니다. LDAP 서버 쿠키 처리 방법에 설명된 대로 풀의 크기를 늘려야 할 수도 있습니다.

이러한 설정을 조정하려면 Windows Server 2008 및 최신 작업을 참조하세요기본 컨트롤러는 LDAP 응답에서 5000 값만 반환합니다.

인덱스를 추가할지 여부 결정

인덱싱 특성은 필터에서 특성 이름이 있는 개체를 검색할 때 유용합니다. 인덱싱은 필터를 평가할 때 방문해야 하는 개체 수를 줄일 수 있습니다. 그러나 이렇게 하면 해당 특성을 수정하거나 추가할 때 인덱스를 업데이트해야 하므로 쓰기 작업의 성능이 저하됩니다. 또한 디렉터리 데이터베이스의 크기도 증가하지만, 이점은 종종 스토리지 비용보다 큽니다. 로깅을 사용하여 비용이 많이 들고 비효율적인 쿼리를 찾을 수 있습니다. 식별되면 해당 쿼리에 사용되는 일부 특성을 인덱싱하여 검색 성능을 향상시키는 것이 좋습니다. Active Directory 검색의 작동 방식에 대한 자세한 내용은 Active Directory 검색 작동 방식을 참조 하세요.

인덱스 추가에 도움이 되는 시나리오

  • 데이터를 요청하는 클라이언트 로드는 상당한 CPU 사용량을 생성하며 클라이언트 쿼리 동작을 변경하거나 최적화할 수 없습니다.

  • 인덱싱되지 않은 특성으로 인해 클라이언트 부하가 서버에 상당한 디스크 I/O를 생성하며 클라이언트 쿼리 동작을 변경하거나 최적화할 수 없습니다.

  • 쿼리는 시간이 오래 걸리며 커버 인덱스가 부족하여 클라이언트에 허용되는 기간 내에 완료되지 않습니다.

  • 긴 기간을 가진 대량의 쿼리로 인해 ATQ LDAP 스레드가 소비되고 고갈됩니다. 다음 성능 카운터를 모니터링합니다.

    • NTDS\요청 대기 시간 – 요청이 처리하는 데 걸리는 시간이 적용됩니다. Active Directory는 120초(기본값) 후에 요청을 시간 초과합니다. 그러나 대부분의 쿼리는 훨씬 더 빠르게 실행되어야 하며 매우 오래 실행되는 쿼리는 전체 숫자에서 숨겨져야 합니다. 절대 임계값이 아닌 이 기준선에서 변경 내용을 찾습니다.

      참고 항목

      여기에 높은 값은 다른 할 일기본 및 CRL 검사 대한 "프록시" 요청의 지연을 나타내는 지표일 수도 있습니다.

    • NTDS\예상 큐 지연 – 최적의 성능을 위해 0에 가까워야 합니다. 이는 요청이 서비스되기를 기다리는 데 시간을 소비하지 않음을 의미하기 때문에 이상적으로는 0에 가깝습니다.

이러한 시나리오는 다음 방법 중 하나 이상을 사용하여 검색할 수 있습니다.

기타 인덱스 고려 사항

  • 쿼리 튜닝이 옵션으로 소진된 후 인덱스 만들기가 문제에 대한 올바른 솔루션인지 확인합니다. 하드웨어 크기를 적절하게 조정하는 것은 매우 중요합니다. 올바른 수정이 특성을 인덱싱하는 것일 때만 인덱스를 추가해야 하며 하드웨어 문제를 난독 분석하지 않아야 합니다.

  • 인덱스는 인덱싱되는 특성의 총 크기 최소 크기까지 데이터베이스 크기를 늘입니다. 따라서 특성에 있는 데이터의 평균 크기를 계산하고 특성이 채워질 개체 수를 곱하여 데이터베이스 증가의 추정치를 평가할 수 있습니다. 일반적으로 데이터베이스 크기는 약 1% 증가합니다. 자세한 내용은 데이터 저장소 작동 방식을 참조 하세요.

  • 주로 조직 단위 수준에서 검색 동작이 수행되는 경우 컨테이너화된 검색에 대한 인덱싱을 고려합니다.

  • 튜플 인덱스는 일반 인덱스보다 크지만 크기를 예측하기가 훨씬 어렵습니다. 최대 20%의 성장을 위한 바닥으로 일반 인덱스 크기 추정치를 사용합니다. 자세한 내용은 데이터 저장소 작동 방식을 참조 하세요.

  • 주로 조직 단위 수준에서 검색 동작이 수행되는 경우 컨테이너화된 검색에 대한 인덱싱을 고려합니다.

  • 튜플 인덱스는 내측 검색 문자열 및 최종 검색 문자열을 지원하는 데 필요합니다. 초기 검색 문자열에는 튜플 인덱스가 필요하지 않습니다.

    • 초기 검색 문자열 – (samAccountName=MYPC*)

    • Medial Search 문자열 - (samAccountName=*MYPC*)

    • 최종 검색 문자열 – (samAccountName=*MYPC$)

  • 인덱스 만들기는 인덱스가 빌드되는 동안 디스크 I/O를 생성합니다. 이 작업은 우선 순위가 낮은 백그라운드 스레드에서 수행되며 들어오는 요청은 인덱스 빌드보다 우선 순위가 지정됩니다. 환경에 대한 용량 계획이 올바르게 수행된 경우 투명해야 합니다. 그러나 쓰기가 많은 시나리오 또는 do기본 컨트롤러 스토리지의 부하를 알 수 없는 환경은 클라이언트 환경의 저하를 초래할 수 있으며 작업 시간 을 벗어나야 합니다.

  • 빌드 인덱스가 로컬에서 발생하기 때문에 복제본(replica)tion 트래픽에 미치는 영향은 최소화됩니다.

자세한 내용은 다음을 참조하세요.

추가 참조