도메인 컨트롤러의 "Peaky"CPU 사용량

소규모 "클라이언트"CPU 사용량이 많은 150 개의 작은 클라이언트 도메인에 Windows Server 2008 SP2 (2008 R2는 아님) 도메인 컨트롤러가 두 개 있습니다. 도메인 컨트롤러는 모두 동일한 동작을 나타내며 vSphere 5.5.0, 1331820에서 호스팅됩니다. 2 ~ 3 초마다 CPU 사용량이 최대 80 ~ 100 %로 증가한 다음 빠르게 감소하고 1 ~ 2 초 정도 낮게 유지 된 다음 점프합니다. 다시.

가상 머신의 히스토리 성능 데이터를 보면이 조건이 최소 1 년 동안 진행되었지만 빈도가 3 월 이후 증가했음을 나타냅니다.

문제가되는 프로세스는 DHCP 클라이언트 (dhcpcsvc.dll), EventLog (wevtsvc.dll) 및 LMHOSTS (lmhsvc.dll) 서비스를 래핑하는 SVChost.exe입니다. 확실히 Windows 내부 전문가는 아니지만 ProcessLog를 사용하여 프로세스를 볼 때 EventLog가 많은 RpcBindingUnbind 호출을 트리거하는 것 외에는 특히 잘못된 것을 찾을 수 없습니다 .

이 시점에서 나는 커피와 아이디어가 부족합니다. 이 문제를 계속 해결하려면 어떻게해야합니까?

TL; DR : EventLog 파일이 가득 찼습니다. 항목 덮어 쓰기는 비싸거나 Windows Server 2008에서 잘 구현되지 않았습니다.

에서 @pk. 및 @joeqwerty의 제안 주위 요청 후, 나는 그것이 가장 가능성이 잊어 버린 모니터링 구현은 이벤트 로그를 긁는 것을 듯했다.

도메인 컨트롤러 중 하나에 Microsoft의 네트워크 모니터 를 설치 하고 ProtocolName == MSRPC필터를 사용하여 MSRPC에 대한 필터링을 시작했습니다 . 많은 트래픽이 있었지만 원격 사이트의 RODC 사이에 있었으며 불행히도 수신 EventLog 프로세스와 동일한 대상 포트를 사용하지 않았습니다. 꿰매다! 그런 이론이 있습니다.

일을 단순화하고 모니터링 소프트웨어를보다 쉽게 ​​실행할 수 있도록 SVCHost에서 EventLog 서비스를 풀기로 결정했습니다. 다음 명령과 도메인 컨트롤러를 다시 부팅하면 하나의 SVCHost 프로세스가 EventLog 서비스에 전용됩니다. 해당 PID에 여러 서비스가 연결되어 있지 않기 때문에 조사가 조금 더 쉽습니다.

SC config EventLog Type= own

그런 다음 ProcMon에 의존하여 해당 PID를 사용하지 않는 모든 것을 제외하도록 필터를 설정했습니다. 여기에 가능한 원인으로 표시된대로 누락 된 레지스트리 키를 여는 EventLog에 의한 실패한 시도가 많이 보이지 않았습니다 (분명히 크 래피 응용 프로그램은 매우 열악한 방법으로 이벤트 소스 로 등록 할 수 있음 ). 보안 이벤트 로그 (C : \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx)의 성공적인 ReadFile 항목이 많이있었습니다.

이러한 이벤트 중 하나에 대한 스택을 살펴 보겠습니다.

먼저 RPCBinding을 확인한 다음 RPCBindingUnbind를 알 수 있습니다. 이것들이 많이 있었습니다 . 초당 수천 개처럼. 보안 로그가 실제로 사용 중이거나 로그에 문제가있는 것입니다 Security.evtx.

EventViewer에서 보안 로그는 분당 50-100 개의 이벤트 만 기록하며이 크기의 도메인에 적합 해 보였습니다. 꿰매다! 매우 장황한 이벤트 감사가 잊혀진 구석에서 왼쪽으로 켜진 채로 일부 응용 프로그램이 여전히 정중하게 떨쳐 버렸다는 이론이 있습니다. 기록되는 이벤트 비율이 낮더라도 여전히 많은 (250,000 개)의 이벤트가 기록되었습니다. 아마도 로그 크기?

보안 로그-(오른쪽 클릭)-속성 ... 및 최대 로그 크기는 131,072KB로 설정되었으며 로그 크기는 현재 131,072KB입니다. '필요에 따라 이벤트 덮어 ​​쓰기'라디오 버튼이 확인되었습니다. 로그 파일을 지속적으로 삭제하고 쓰는 것이 로그 파일이 가득 찼을 때 특히 어려운 일이라고 생각하여 로그 지우기를 선택했습니다 (나중에 감사를 위해 이전 로그를 저장 한 경우). 새로운 빈 파일. 결과 : CPU 사용량이 약 5 %의 정상 수준으로 돌아갑니다.

작은 데이터 수집기 ​​집합을 만들어이 문제를 추적 할 수 있습니다.

• 성능 모니터를 열고 새 사용자 정의 데이터 콜렉터 세트를 작성하십시오.
• 선택하지 매뉴얼 (어떤 템플릿을)를 선택 이벤트 추적 데이터 만.
• Active Directory 도메인 서비스 : 핵심 데이터를 추가하고 세트를 저장하십시오.
• 변경 정지 상태 에서 속성을 1 분.
• 세트를 시작하고 기다리십시오.
• 완료되면, 저장된 변환 은 .etl의 A와 파일을 .CSV 사용tracerpt –l “file.etl” –of CSV
• Excel에서 summary.csv 및 dumpfile.csv 데이터를 분석하십시오 . 이 Import-DC-Info.xlsm doc 을 다운로드 하여 분석에 도움을 줄 수 있습니다.

직감이 맞다면 DC를 망치는 일부 장치 (IP : 포트)를 보게 될 것입니다.

확실히 어려운 일입니다. 그냥 내버려 두는 것 외에도 (1 CPU / 50 % 부하. 누가 신경 쓰겠습니까?) 새 도메인 컨트롤러를 설정하고 며칠 후에도 동일한 동작을 제공하는지 확인할 수 있습니다. 그렇다면 Wireshark 추적으로 시도하고 싶을 수도 있습니다 (분명히 네트워크 에서이 문제가 발생했습니다)

다음으로 떠오르는 것은 Microsoft에 대한 간단한 호출입니다.

트래비스, "아카이브"가 도움이되지 않았습니다. 실제로, 2/3 성장 일 때 이벤트 로그를 지우더라도 도움이되지 않습니다. 그러나 "보관"은 KraigM에 도움이되었습니다.

kce : 131MB "덮어 쓰기"파일을 지우고 55 % o 5 %에서 성능 저하를 보았지만 질문 : 아마도 (a) 덮어 쓰기 조건에 도달했을 때만 트리거되거나 (b) 지워진 파일의 크기가 0MB에서 131MB로 증가함에 따라 선형 적으로 악화 될 수 있습니다.

일부는 security.evtx에서 이것을보고 다른 하나는 작업 스케줄러 운영 로그에서이를 보았습니다. AV를 완전히 제거하고 사용하는 것이 좋습니다. 침입자는 자신의 트랙을 숨겨야하며, 트랙은 설정 한 예약 된 작업 또는 로그인 한 작업에서 만들어집니다. 따라서 이러한 이벤트 로그에 대한 핸들을 해제하고 트랙을 건너 뛰도록 다시 작성하여 트랙을 숨 깁니다. AV는 버그가있는 방식으로이를 감지 할 수 있습니다. Microsoft 인 경우이 높은 활용률이 더 많이보고되었지만 Googling에서 게시물이 거의없는 것을 볼 수 있습니다. security.evtx 로그에 대한 서버 2008 R2에서도이 내용이 표시됩니다. 이벤트 로그 가입 자나 외부 모니터가 없습니다. 몇 개의 AV 서비스 (McAfee)가 실행되는 것을 관찰하고 서버의 전체 사용률이 너무 며칠 동안 서버가 완전히 제거 된 것으로 의심되며 부분적으로 만 (McAfee의 특수 제거 프로그램이 필요할 수 있음) 의심되는 부분이 있는지 궁금합니다 어떤 방식 으로든 이벤트 로그에 정상적인 쓰기를 수행하고이를 필터링하여 전체 이벤트 로그를 완전히 읽어야하는지 여부를 결정하는 흔적 (또는 정상적으로 설치된) McAfee 서비스 또는 McAfee 필터 드라이버. 일부 AV 회사의 타사 필터 드라이버는 버그가 많으며 Microsoft의 이벤트 로깅 구현보다 10000 배 더 버그가 많으므로 완벽 할 것입니다. 요약하면, 모든 av 제거 및 100 % 제거 문제가 100 % 제거됩니다. 그렇다면 AV 회사와 협력하여 AV를 수정하십시오. 에 대한 파일 예외를 만드는 것은 좋지 않습니다.

또한 procmon을 사용할 때는 Writefile이 필터 관리자가 전체 파일을 읽도록 트리거하기 때문에 WriteFile 호출에주의하십시오. 필자의 경우, 쓰기가 의도적으로 설계된 후 약 30 초 후에 읽기가 시작되었습니다. 그러나 일관성이 있었고 제 경우에는 파일이 4GB 였고 파일 읽기는 64KB 길이의 64K 읽기 파일을 포함했으며이를 달성하기 위해 CPU의 35 %를 사용했습니다. 너무 슬퍼.

업데이트 03/23/2016 나는이 컴퓨터에서 필터 드라이버를 보았는데 그 중 하나 때문에 발생했다고 결론을 내 렸습니다 (이벤트 로그 메커니즘은 자체 버그가 있거나 이런 종류의 보고서 수가 엄청날 것입니다. 그렇지 않습니다). AV 및 잘 알려진 타사 회사의 일부 필터 드라이버를 미리 읽음으로써 가상 컴퓨터 디스크 성능을 향상시키고 제품이 전체적으로 과도하게 읽을 수 있는지 수석 건축가 (매우 친절하고 은혜로운 사람)에게 물었습니다. 보안 이벤트 로그 (프로 시저마다 명확하게 발생 함). 이는 소규모 보안 로그에는 도움이되지만 여기에보고 된 크기의 보안 로그에는 도움이되지 않습니다. 그가 말한 방법은 없습니다. 그는 AV일지도 모른다는 데 동의했다.

아래의 Azure 동료에게 말했듯이 이벤트 로그를 지운 후 문제가 다시 표면화되면 원래 포스터의 후속 조치가 없습니다. 시간이 지남에 따라 성능이 다시 저하되기 때문에 일반적이고 잘못된 솔루션이기 때문입니다. 이것을 "사후 조사"라고하며, 원래의 포스터 솔루션이 후속 조치를하지 않은 사람들이 문제를 해결했다고 믿게 할 수 있습니다. 나도 거의 바보에요. 이벤트 로그를 지우고 성능이 향상되었지만 procmon을 사용하여 문제가 발생할 때까지 시간이 지남에 따라 문제가 점차 커지고 느리게 진행되는 것을 보았습니다. 어떤 이유로, Azure 동료는 원래 포스터가 후속 조치를 수행하지 않았을 때 (죽거나, 해고 당하거나, 종료되거나, 바빴을 때) 나를 강력하게 비난합니다. 아래의 Azure 동료는 원래 포스터가 후속 조치를 취하지 않은 경우 수정 된 문제 여야한다고 생각합니다. 기술적으로 높은 평가를받는 사람이이 입장을 취하는 사람을 생각할 수 없기 때문에 이것은 혼란스럽고 수수께끼입니다. 신경을 찔렀다면 사과드립니다. 어쩌면 사람들을 부르는 인터넷의 다른 곳에서 나의 행동주의에서 그의 신경을 얻었을 것입니다-여기 (serverfault) 나는 단순히 친절하고 깊은 기술적 지식을 공유하고 있으며 Azure의 결과는 기술적 기여가 필요하거나 내 블로그에 있습니다 (나는 그런 블로그가 없습니다). 아직이 링크를 Microsoft의 약 6 개 핵심 직원에게 보내려고하지 않고, 주요 MSFT 직원이 괴롭힘을 당하고있는 것에 대해 궁금한 점이 있습니다. 마음에 드는 커뮤니티와 Azure 씨의 아래 답변은 몇 마디로 믿기 어려울뿐 아니라 불안하고 괴롭힘-어떤 사람들은 다른 사람들과 즐겁게 행동합니다. 나는 처음에 불쾌감을 주었지만 그것을 넘어서고 수동적이거나 능동적 인 독자들은 내가 말하는 것을 고맙게 생각하고 내 의견을 고맙게 생각할 것입니다. 여기서 미묘하게 부적절한 이유가있는 법적 이유와 상관없이 100 % 뒤에 서 있습니다. M. Azure, 친절을 연습하고 어두운 곳에서 내 의견을 제시하지 마십시오. 그냥 극복하고 구속을 보여주십시오. 친절을 연습하고 어두운 곳에서 내 의견을 제시하지 마십시오. 그냥 극복하고 구속을 보여주십시오. 친절을 연습하고 어두운 곳에서 내 의견을 제시하지 마십시오. 그냥 극복하고 구속을 보여주십시오.

괴롭히다