AD DS 성능 튜닝에 대한 메모리 사용량 고려 사항

이 문서에서는 LSASS(Local Security Authority Subsystem Service, Lsass.exe 프로세스라고도 함), LSASS 구성에 대한 모범 사례 및 메모리 사용에 대한 기대치에 대해 설명합니다. 이 문서는 DC(do기본 컨트롤러)에서 LSASS 성능 및 메모리 사용 분석의 가이드로 사용되어야 합니다. 이 문서의 정보는 이 엔진을 최적화하기 위해 서버 및 DC를 조정하고 구성하는 방법에 대한 질문이 있는 경우에 유용할 수 있습니다.

LSASS는 인증 및 Active Directory 관리를 기본 LSA(로컬 보안 기관)의 관리를 담당합니다. LSASS는 클라이언트와 서버 모두에 대한 인증을 처리하며 Active Directory 엔진도 제어합니다. LSASS는 다음 구성 요소를 담당합니다.

  • 로컬 보안 기관
  • NetLogon 서비스
  • SAM(보안 계정 관리자) 서비스
  • LSA 서버 서비스
  • SSL(Secure Sockets Layer)
  • Kerberos v5 인증 프로토콜
  • NTLM 인증 프로토콜
  • LSA에 로드되는 기타 인증 패키지

Active Directory 데이터베이스 서비스(NTDSAI.dll)는 ESE, ESENT.dll(Extensible Storage Engine)에서 작동합니다.

DC의 LSASS 메모리 사용량에 대한 시각적 다이어그램은 다음과 같습니다.

Diagram of the components that use LSASS memory

LSASS가 DC에서 사용하는 메모리 양은 Active Directory 사용량에 따라 증가합니다. 데이터를 쿼리하면 메모리에 캐시됩니다. 따라서 Active Directory 데이터베이스 파일(NTDS.dit)의 크기보다 큰 메모리 양을 사용하여 LSASS를 확인하는 것이 정상입니다.

다이어그램에 설명된 것처럼 LSASS 메모리 사용량은 ESE 데이터베이스 버퍼 캐시, ESE 버전 저장소 등을 비롯한 여러 부분으로 나눌 수 있습니다. 이 문서의 나머지 부분에서는 이러한 각 부분에 대한 인사이트를 제공합니다.

ESE 데이터베이스 버퍼 캐시

LSASS 내에서 가장 큰 가변 메모리 사용량은 ESE 데이터베이스 버퍼 캐시입니다. 캐시 크기는 1MB 미만에서 전체 데이터베이스의 크기까지 다양할 수 있습니다. 캐시가 클수록 성능이 향상되므로 ESENT(Active Directory)의 데이터베이스 엔진은 캐시를 최대한 크게 유지하려고 합니다. 캐시의 크기는 컴퓨터의 메모리 압력에 따라 다르지만 ESE 데이터베이스 버퍼 캐시의 최대 크기는 컴퓨터에 설치된 실제 RAM에 의해서만 제한됩니다. 다른 메모리 압력이 없는 한 캐시는 Active Directory NTDS.dit 데이터베이스 파일의 크기로 증가할 수 있습니다. 캐시할 수 있는 데이터베이스가 많을수록 DC의 성능이 향상됩니다.

참고 항목

데이터베이스 캐싱 알고리즘이 작동하는 방식 때문에 데이터베이스 크기가 사용 가능한 RAM보다 작은 64비트 시스템에서 데이터베이스 캐시는 데이터베이스 크기보다 30~40% 커질 수 있습니다.

ESE 버전 저장소

ESE 버전 저장소의 가변 메모리 사용량이 있습니다(위 다이어그램의 빨간색 부분). 사용되는 메모리 양은 Windows Server 2019 또는 이전 버전의 Windows가 있는지 여부에 따라 달라집니다.

  • Windows Server 2019를 미리 빌드하는 Windows Server 버전에서 기본적으로 LSASS는 ESE 버전 저장소용 64비트 컴퓨터에서 CPU 수에 따라 최대 400MB의 메모리를 사용할 수 있습니다. 버전 저장소를 사용하는 방법에 대한 자세한 내용은 Ryan Ries의 다음 ASKDS 블로그 게시물을 참조하세요. 버전 저장소 호출 및 모든 버킷에서 벗어났습니다.

  • Windows Server 2019에서는 이 작업이 간소화되고 NTDS 서비스가 처음 시작되면 ESE 버전 저장소 크기가 실제 RAM의 10%로 계산되며 최소 400MB 및 최대 4GB가 됩니다. 이 및 버전 저장소 문제 해결에 대한 자세한 내용은 Ryan Ries: 심층 분석: Server 2019의 Active Directory ESE 버전 저장소 변경 내용의 또 다른 유용한 블로그를 참조하세요.

기타 메모리 사용

마지막으로 코드, 스택, 힙 및 다양한 고정 크기 데이터 구조(예: 스키마 캐시)가 있습니다. LSASS에서 사용하는 메모리 양은 컴퓨터의 부하에 따라 달라질 수 있습니다. 실행 중인 스레드 수가 증가함에 따라 메모리 스택의 수도 증가합니다. 평균적으로 LSASS는 이러한 고정 구성 요소에 100MB에서 300MB의 메모리를 사용합니다. 더 많은 양의 RAM이 설치되면 LSASS는 더 많은 RAM과 적은 가상 메모리를 사용할 수 있습니다.

할 일기본 컨트롤러의 프로그램 수를 제한하거나 최소화하거나 적절한 경우 추가 RAM을 추가합니다.

최적의 성능을 위해 LSASS는 지정된 DC에서 가능한 한 많은 RAM을 사용합니다. LSASS는 다른 프로세스에서 요구하는 대로 RAM을 포기합니다. 이 아이디어는 컴퓨터에서 실행될 수 있는 다른 프로세스를 고려하면서 LSASS의 성능을 최적화하는 것입니다. 주의해야 할 프로그램 목록에는 모니터링 에이전트가 포함됩니다. 일부 고객은 상당한 RAM 리소스를 사용할 수 있는 다양한 서버 함수에 대한 별도의 에이전트를 가지고 있습니다. 일부는 아래에 몇 가지 세부 정보가 있는 많은 WMI 쿼리를 발행할 수 있습니다.

이 때문에 성능을 높이기 위해 DC에서 프로그램 수를 제한하거나 최소화하는 것이 좋습니다. 메모리 요청이 없는 경우 LSASS는 이 메모리를 사용하여 Active Directory 데이터베이스를 캐시하므로 최적의 성능을 달성합니다.

DC에 성능 문제가 있음을 알면 메모리 사용률이 중요한 프로세스도 확인합니다. 문제 해결에 문제가 있을 수 있습니다. 여기에는 Microsoft 구성 요소가 포함될 수 있습니다. 최신 서비스 업데이트를 계속 진행하세요. Microsoft에는 품질 업데이트의 일부로 과도한 메모리 사용률에 대한 솔루션이 포함되어 있으며 이는 DC 성능에도 도움이 될 수 있습니다.

사용 프로필에 따라 상당한 RAM을 사용할 수 있는 기본 제공 OS 기능이 있습니다.

  • 파일 서버. DC는 SYSVOL 및 Netlogon 공유, 서비스 그룹 정책 및 정책 및 시작/로그온 스크립트에 대한 스크립트용 파일 서버이기도 합니다. 그러나 고객이 DC를 사용하여 다른 파일 콘텐츠를 서비스하는 것을 볼 수 있습니다. 그러면 SMB 파일 서버는 RAM을 사용하여 활성 클라이언트를 추적하지만, 무엇보다도 파일 콘텐츠는 OS 파일 캐시를 증가시키고 RAM용 ESE 데이터베이스 캐시와 경쟁하게 됩니다.

  • WMI 쿼리. 모니터링 솔루션은 종종 많은 WMI 쿼리를 만듭니다. 개별 쿼리를 실행하는 것이 저렴할 수 있습니다. 특히 모니터링 솔루션이 Windows에서 관리하는 다양한 이벤트 로그에서 새 이벤트를 추출하기 때문에 약간의 오버헤드가 발생하는 호출 볼륨이 자주 발생합니다.

    가장 많은 볼륨을 생성하는 이벤트 로그는 일반적으로 보안 이벤트 로그입니다. 또한 보안 관리자가 특히 DC에서 수집하려는 이벤트 로그이기도 합니다.

    WMI 서비스는 쿼리를 최적화하는 동적 메모리 할당 체계를 사용합니다. 따라서 WMI 서비스는 ESE 데이터베이스 캐시와 다시 경쟁하면서 많은 메모리를 할당할 수 있습니다.