lsass

 

• Q. LSASS High CPU가 “LDAP workload” 때문일 때 나타나는 대표 증상은?
  A. DC 응답 지연으로 애플리케이션 타임아웃/로그온 지연·자격 증명 재입력 반복·LDAP 검색 속도 저하·전반적 시스템 버벅임(+메모리 급증 동반 가능). 현장에서는 “간헐적 성공/실패” 패턴

 

• Q. 초동 수집은 무엇을, 왜/어떻게 모을까?
  A. (1) 1644 이벤트 로깅(비싼/비효율 쿼리 식별) (2) AD Diagnostics Data Collector Set(ADPERF)로 성능 카운터·레포트 확보 (3) netstat -anob·tasklist /svc(과도 연결/서비스 매핑) (4) 네트워크/WPR 트레이스(지연 구간) (5) LSASS 덤프(스택 확인). 재현 구간 5–15분 단위로 모으는 게 효율적입니다. 또한 1644 분석 스크립트(Event1644Reader.ps1) 사용을 문서가 권장합니다. Microsoft Learn

 

• Q. 1644 이벤트 로깅은 정확히 어떻게 켜나?
  A. Microsoft 지침(원 KB 3060643)에 따라 LDAP 진단 로깅을 활성화하고(레지스트리/GPO 경로가 문서화됨), “Expensive/ Inefficient/ Long-Running” 임계치 값을 환경에 맞게 설정합니다. 이후 Event1644Reader.ps1로 집계·시각화하세요. Microsoft Learn

 

• Q. 1644에서 “어떤 필드”를 중점 해석해야 하나?
  A. 필터/스코프·조회 속성·반환 개수·방문(Visited) 개수·실행 시간·사용된 인덱스(Index used)·추정 크기(Estimated size). “Index used: … / estimated size …” 신호가 핵심이며, 같은 필터가 반복적으로 고비용이면 즉시 후보로 지정합니다.

 

• Q. “소수의 비싼 쿼리” vs “너무 많은 정상 쿼리”를 어떻게 가르나?
  A. 동일/유사 필터가 특정 클라이언트에서 반복(쿼리당 비용↑)되면 전자, 다양한 클라이언트에서 경량 쿼리가 폭증(합계 비용↑)하면 후자입니다. 대응전략이 달라지므로 초기에 이 분류가 중요합니다.

 

• Q. LDAP 검색의 라이프사이클(아주 상위 수준)은?
  A. 클라이언트 쿼리 → DC의 검색 구조/인덱스 평가 → NTDS.DIT 후보 스캔 → 결과 반환. 병목은 “평가 단계(인덱스 미스/범위 과대)”에서 가장 잘 발생합니다.

 

• Q. “인덱스”는 정확히 무엇이며, 어떤 이득을 주나?
  A. 인덱스는 (a) 평가 레코드 수를 줄이거나 (b) 방문 순서를 최적화하거나 (c) 둘 다로 비용을 낮춥니다. 보조(secondary) 인덱스는 키 정렬 → 실제 레코드(북마크)로 연결됩니다.

 

• Q. 기본(default) 인덱스와 보조 인덱스, 그리고 기본 테이블은?
  A. DNT_index(전체 레코드), PDNT_(동일 컨테이너 하위), Ancestors_Index(컨테이너+하위 트리)가 기본. 특정 속성 기반의 탐색은 보조 인덱스가 담당합니다.

 

• Q. “무엇에 인덱스를 줄지” 결정 기준은?
  A. 1644에서 “반복+고비용”으로 드러난 필터의 속성을 1순위로. 결과 선택도가 높을수록(매칭 수가 적을수록) 인덱스 효과가 큽니다. 적용 전후로 1644의 “Index used/Visited/Elapsed”를 비교해 검증하세요.

 

• Q. 인덱싱(검색 플래그 변경)은 어떻게 이뤄지고, 어떤 영향이 있나?
  A. 스키마의 searchFlags를 수정하면 포리스트 전체에 복제됩니다. 각 DC는 변경 수신 후 백그라운드로 인덱스를 재구성하므로, 환경·객체 수에 비례한 CPU 부하/복제 지연을 예상하세요. 또한 searchFlags 자체 정의와 관리 권한은 공식 스키마 문서에 정리돼 있습니다. Microsoft Learn

 

• Q. 인덱싱 후 “잘 먹히는지” 무엇을 확인하나?
  A. (1) 1644에 Index used가 명시되는지 (2) Visited↓, Elapsed↓, Returned/Visited 비율 개선 (3) 앱 체감 성능(로그온·쿼리 시간) 개선. 동일 부하 조건으로 전/후를 비교하세요.

 

• Q. ANR(모호명 해석)은 왜 주의가 필요한가?
  A. 여러 속성을 한 번에 매칭하므로 강력하지만 범위가 넓어 고비용이 되기 쉽습니다. 과사용 시 인덱스/서버 부하가 급증하므로 필요한 속성만 ANR에 포함하고, 1644로 비용을 상시 점검하세요.

 

• Q. “중간 일치(CN=ninj)”가 위험한 이유와 튜플 인덱스는?
  A. 선행 와일드카드/중간 매칭은 일반 인덱스로 최적화가 어려워 튜플 인덱스 힌트가 필요합니다. 튜플/서브트리/VLV 관련 searchFlags 비트와 성능 영향은 프로토콜 명세에 명확히 정의돼 있습니다. Microsoft Learn

 

• Q. VLV(가상 목록 보기)는 무엇이고, 언제 인덱스가 필요한가?
  A. 클라이언트가 정렬 키를 주면 DC가 정렬·부분전송(주소록 시나리오 등)합니다. 안정 성능을 위해 VLV 인덱스를 권장하며, .NET LDAP 클라이언트는 VlvRequest/ResponseControl로 이를 요청/처리합니다. Microsoft Learn

 

• Q. 애플리케이션(쿼리) 쪽에서 즉시 할 수 있는 최적화는?
  A. (1) 선행/중간 와일드카드 축소(접두 일치·정확 일치 선호) (2) 불필요한 속성/필터 제거(Attributes to Return 최소화) (3) Base DN/Scope(기본=Subtree) 좁히기 (4) 중복·폴링성 조회 캐싱/백오프 적용. 이후 1644로 재검증하세요.

 

• Q. “문제 재현→원인 특정→개선 검증”의 실무 루틴은?
  A. ADPERF 수집(과부하 DC에서도 유효하게 레포트 생성하는 팁 포함)→1644 집계→상위 N개 필터 튜닝/인덱싱→지표 재측정의 루프를 짧게 돌립니다. Microsoft Directory Services 팀의 AD Diagnostics DCS 글이 구체적 팁을 제공합니다. TECHCOMMUNITY.MICROSOFT.COM

 

• Q. “이게 정말 LDAP 때문인지” 프로세스/네트워크 관점 교차검증은?
  A. netstat -anob로 특정 프로세스의 LDAP 포트(389/636) 다중 연결·큐 적체 확인, tasklist /svc로 서비스 매핑, WPR/네트워크 트레이스로 RTT/리트랜스/지연 구간 파악—이후 1644 타임라인과 대조합니다.

 

• Q. Event1644Reader.ps1은 실제로 무엇을 해주나?
  A. 1644 로그를 수집·정규화해 “비싼/비효율/장시간 쿼리”를 요약, 사용 인덱스·추정 크기 등 신호를 표로 뽑아 인덱싱 후보를 빠르게 도출합니다(원 문서=KB 3060643). Microsoft Learn

 

• Q. searchFlags는 어디에서/어떻게 관리하며, 무엇을 주의해야 하나?
  A. 스키마의 searchFlags 속성으로 인덱스/특수 인덱스(ANR/튜플/VLV 등)·보안(Confidential)까지 제어합니다. 인덱싱은 스키마 업데이트이므로 변경 영향·복제를 고려하고, 특히 ANR·튜플 인덱스는 신중히 적용하세요. Microsoft Learn+2Microsoft Learn+2

 

• Q. 최종 체크리스트(요약)는?
  A. ① 증상·재현 구간 명확화 ② 1644·ADPERF·네트워크/WPR·프로세스 수집 ③ 상위 필터 식별(“Index used/Visited/Elapsed” 주시) ④ 인덱싱 또는 쿼리 튜닝(ANR/튜플/VLV 주의) ⑤ 전/후 1644·체감 성능 검증 ⑥ 잔여 상위 항목 반복. 이 순서를 표준 런북으로 굳히면 재발 대응이 빨라집니다.