„Szczytowe” użycie procesora na kontrolerach domeny

25

Mamy dwa kontrolery domeny z systemem Windows Server 2008 SP2 (niestety nie 2008 R2) w małej domenie 150 klientów, które wykazują bardzo „szczytowe” użycie procesora. Kontrolery domeny zachowują się tak samo i są hostowane na vSphere 5.5.0, 1331820. Co dwie lub trzy sekundy użycie procesora skacze do 80-100%, a następnie szybko spada, pozostaje niskie przez sekundę lub dwie, a następnie skacze w górę jeszcze raz.

Wydajność Menedżera zadań DC3


Analiza danych historycznych dotyczących wydajności maszyny wirtualnej wskazuje, że warunek ten utrzymuje się przez co najmniej rok, ale częstotliwość wzrosła od marca.

Wydajność maszyny wirtualnej DC3



Obrażającym procesem jest SVChost.exe, który pakuje usługi klienta DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) i LMHOSTS (lmhsvc.dll). Z pewnością nie jestem ekspertem w dziedzinie wewnętrznych systemów Windows, ale nie mogłem znaleźć niczego szczególnie nietypowego podczas przeglądania procesu za pomocą Process Explorer, poza tym, że wydaje się, że EventLog wywołuje mnóstwo wywołań RpcBindingUnbind .

DC3 Process Explorer dla SVCHost.exe



W tym momencie zabrakło mi kawy i pomysłów. Jak mam dalej rozwiązywać ten problem?


źródło
Po prostu spitballing tutaj: 1. Czy masz system monitorowania, który odpytuje dzienniki zdarzeń na DC? 2. Czy masz włączoną kontrolę, która może prowadzić do dużej aktywności dziennika zdarzeń na kontrolerach domeny?
joeqwerty
1
Chciałem się włączyć, ponieważ ten wątek pojawił się w wyszukiwarce Google dla dziennika zdarzeń wysokiego procesora. Ten problem nadal występuje na serwerze 2012. Właśnie rozwiązałem dokładnie ten sam problem na serwerze DC 2012. Sprawdź rozmiary plików dziennika. Domyślna ścieżka dziennika to% SystemRoot% \ System32 \ Winevt \ Logs \ Overwrite radio powoduje problemy z obsługą większych rozmiarów plików dziennika. Ustawiam mój, aby archiwizował dziennik, gdy jest pełny i najazd.
KraigM,
W przypadku osób przybywających tutaj z Google ten problem z usługą dziennika zdarzeń dotyczy również komputerów z systemem Windows Server niebędących kontrolerami. W moim przypadku wystarczająca liczba użytkowników z mmc.exeotwartym (prawdopodobnie domyślnym oknem „Menedżera serwera?”) Osiągnęła również regularne skoki.
Nickolay

Odpowiedzi:

25

TL; DR: plik EventLog był pełny. Zastępowanie wpisów jest kosztowne i / lub nie jest dobrze zaimplementowane w systemie Windows Server 2008.


W @pk. oraz sugestię @joeqwerty i po zapytaniu doszedłem do wniosku, że najprawdopodobniej wydaje się, że zapomniana implementacja monitorowania skrobała dzienniki zdarzeń.

Zainstalowałem Monitor sieci Microsoft na jednym z kontrolerów domeny i zacząłem filtrować MSRPC przy użyciu ProtocolName == MSRPCfiltra. Ruch był duży, ale wszystko odbywało się pomiędzy kontrolerem RODC naszej zdalnej strony i niestety nie korzystało z tego samego portu docelowego, co proces EventLog nasłuchujący. Cerować! Idzie ta teoria.

Aby uprościć i ułatwić uruchamianie oprogramowania monitorującego, postanowiłem rozpakować usługę EventLog z SVCHost. Następujące polecenie i ponowne uruchomienie kontrolera domeny poświęcają jeden proces SVCHost dla usługi EventLog. Ułatwia to dochodzenie, ponieważ do tego PID nie jest przypisanych wiele usług.

SC config EventLog Type= own

Następnie skorzystałem z ProcMon i skonfigurowałem filtr, aby wykluczyć wszystko, co nie korzystało z tego PID. Nie widziałem ton nieudanych prób EventLog, aby otworzyć brakujące klucze rejestru, jak wskazano jako możliwą przyczynę tutaj (najwyraźniej kiepskie aplikacje mogą zarejestrować się jako źródła zdarzeń w bardzo złych warunkach). Przewidywalnie widziałem wiele udanych wpisów ReadFile w dzienniku zdarzeń bezpieczeństwa (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

ReadFile Security.evtx

Oto spojrzenie na stos jednego z tych wydarzeń: RpcBindingUnbind

Zauważysz najpierw RPCBinding, a następnie RPCBindingUnbind. Było ich dużo . Jak tysiące na sekundę. Dziennik bezpieczeństwa jest naprawdę zajęty lub coś nie działa poprawnie z Security.evtxdziennikiem.

W EventViewer dziennik zabezpieczeń rejestrował tylko 50-100 zdarzeń na minutę, co wydawało się odpowiednie dla domeny tego rozmiaru. Cerować! Istnieje teoria numer dwa, że ​​mieliśmy jakąś aplikację z bardzo szczegółową kontrolą zdarzeń włączoną w lewo w zapomnianym kącie, nadal obowiązkowo odpędzając. Wciąż odnotowano wiele (~ 250 000) zdarzeń, mimo że odsetek rejestrowanych zdarzeń był niski. Może rozmiar kłody?

Dzienniki zabezpieczeń - (prawy przycisk myszy) - Właściwości ... a maksymalny rozmiar dziennika został ustawiony na 131 072 KB, a rozmiar dziennika obecnie wynosi 131 072 KB. Zaznaczono przycisk „Zastąp zdarzenia w razie potrzeby”. Uznałem, że ciągłe usuwanie i zapisywanie pliku dziennika było prawdopodobnie ciężką pracą, zwłaszcza gdy było tak pełne, więc zdecydowałem się wyczyścić dziennik (zapisałem stary dziennik na wypadek, gdyby był potrzebny do późniejszej kontroli) i pozwoliłem na utworzenie usługi EventLog nowy pusty plik. Wynik: użycie procesora powróciło do rozsądnego poziomu około 5%.

Społeczność
źródło
Dobra robota. Przenieś także TL; DR na górę odpowiedzi?
Zlatko
Po prostu FYI ... to po prostu uderzyło w kilka naszych kontrolerów domeny, z których większość to 2012/2012 R2. Wygląda więc na równie słabo zaimplementowane w nowszych wersjach systemu Windows Server.
HopelessN00b
Więc to jest mój problem, ALE ustawiłem archiwizację, gdy jest pełna i nie przesadzam. Maksymalny rozmiar dziennika to 1 GB, a obecny rozmiar to 639 MB. Zastanawiam się, co robić inaczej niż może wyczyścić dziennik jako test. To jest na 2008 R2 Std i wpływa na PDC i wtórne DC. Oba są maszynami wirtualnymi. Musiałem przydzielić 2 gniazda / 1 rdzeń dla każdego DC, albo oba ustalą przydziały 1/1 i nie będą już odpowiadać. Dodanie większej ilości pamięci RAM nic nie dało. W tym momencie stale wykorzystuje od 60 do 100% procesora.
Travis,
Zapisano / wyczyściłem dziennik bezpieczeństwa. Nadal działa 74% zużycie procesora.
Travis,
5

Możesz być w stanie to ścigać, tworząc mały zestaw modułów zbierających dane.

  • Otwórz Monitor wydajności i utwórz nowy zestaw modułów zbierających dane zdefiniowany przez użytkownika.
  • Wybierz Ręcznie (bez szablonu) i wybierz Tylko dane śledzenia zdarzeń .
  • Dodaj usługę domenową Active Directory: Podstawowe dane i zapisz zestaw.
  • Zmień warunek zatrzymania w obszarze Właściwości na 1 minutę.
  • Uruchom zestaw i poczekaj.
  • Po zakończeniu przekonwertuj zapisany plik .etl na plik .csv, używająctracerpt –l “file.etl” –of CSV
  • Przeanalizuj dane summary.csv i dumpfile.csv w programie Excel. Możesz pobrać ten dokument Import-DC-Info.xlsm, aby pomóc Ci w analizie.

Jeśli moje przeczucie jest prawidłowe, zobaczysz, że niektóre urządzenia (IP: port) wbijają DC.

pk.
źródło
1

Z pewnością trudny. Oprócz pozostawienia go w spokoju (1 procesor / 50% obciążenia .. kogo to obchodzi?), Możesz spróbować skonfigurować nowy kontroler domeny i zobaczyć po kilku dniach, czy ten daje ci to samo zachowanie. Jeśli tak, możesz spróbować ze śladem Wireshark (oczywiście jest to spowodowane tym przez sieć)

Następną rzeczą, która przychodzi mi na myśl, jest proste połączenie z Microsoft

MichelZ
źródło
-2

Travis, „archiwum” ci nie pomogło. W rzeczywistości nawet wyczyszczenie dziennika zdarzeń, gdy był on 2/3 wyhodowany, nie pomogło. Ale „archiwum” pomogło KraigM.

kce: wyczyściłem plik "nadpisujący" o wielkości 131 MB i zobaczyłem spadek wydajności z powiedzmy 55% o 5%, ale PYTANIE: być może w końcu znowu zobaczyłeś wysokie wykorzystanie, ponieważ może to (a) zostać uruchomione tylko po spełnieniu warunku nadpisania lub (b) może się pogorszyć liniowo, gdy rozmiar usuwanego pliku wzrośnie z 0 MB do 131 MB.

Niektórzy widzą to w pliku security.evtx, a jeden widział to w dzienniku operacyjnym Harmonogramu zadań. Proponuję całkowicie odinstalować system AV (którego używasz) i spróbować. Intruzi muszą ukrywać swoje ślady, a ich ślady są wykonywane w zaplanowanych zadaniach, które konfigurują lub logują się. Więc ukryją swoje ścieżki, łamiąc uchwyty tych dzienników zdarzeń i przepisując je, aby pominąć swoje ścieżki. AV może wykrywać to w błędny sposób, ponieważ gdyby był to Microsoft, zgłoszono by więcej tego wysokiego wykorzystania, ale widzę tylko kilka postów, gdy Googling. Widzę to również na serwerze 2008 R2 dla dziennika security.evtx. Brak subskrybentów dziennika zdarzeń, brak zewnętrznych monitorów. Zauważyłem, że kilka usług AV (McAfee) działa i miały one bardzo niskie całkowite wykorzystanie serwera przez tak wiele dni, więc podejrzewam, że zostało odinstalowane i tylko częściowo (prawdopodobnie potrzebuje specjalnego deinstalatora McAfee) i zastanawiam się, czy są jakieś problemy pozostawiona (lub nawet normalnie zainstalowana) usługa McAfee lub działające sterowniki filtrów McAfee, które w jakiś sposób biorą normalny zapis do dziennika zdarzeń i decydują w swoim filtrowaniu, że muszą to przekształcić w pełny odczyt całego dziennika zdarzeń. Zaufaj mi, sterowniki filtrów innych firm z niektórych firm AV są błędne i na pewno mają 10000 razy więcej błędów niż implementacja rejestrowania zdarzeń przez Microsoft, co jest bardzo prawdopodobne. Podsumowując, 100% odinstaluj WSZYSTKIE AV I ZOBACZ, JEŚLI problem zostanie rozwiązany. Jeśli tak, skontaktuj się z firmą AV, aby naprawić AV. Nie zaleca się tworzenia wyjątków dla plików.

Ponadto, używając procmon, zwróć uwagę na wywołania WriteFile, ponieważ plik zapisu powoduje, że menedżer filtrów odczytuje cały plik. W moim przypadku odczyt został zainicjowany około 30 sekund po zakończeniu zapisu, co może być zgodne z projektem. Ale był spójny i w moim przypadku plik miał 4 GB, a plik do odczytu obejmował 64 KB plików o długości 64 KB każdy i wykorzystał 35% procesora, aby to osiągnąć. Bardzo smutny.


Aktualizacja 23.03.2016 Spojrzałam na sterowniki filtrów na tym komputerze po tym, jak stwierdziłam, że musiał to być jeden z nich (mechanizm dziennika zdarzeń nigdy nie byłby sam w sobie wadliwy lub liczba tego rodzaju raportów byłaby oszałamiająca i nie jest). Widziałem niektóre sterowniki filtrów z AV i znanej firmy zewnętrznej, która zwiększa wydajność dysku maszyny wirtualnej dzięki czytaniom z wyprzedzeniem i zapytałem głównego architekta (który był bardzo miły i uprzejmy), czy jego produkt może nadmiernie agresywnie czytać cały dziennik zdarzeń bezpieczeństwa (który wyraźnie zdarzał się na jedno polecenie). Byłoby to pomocne w przypadku mniejszych dzienników zabezpieczeń, ale nie tych o podanych tutaj rozmiarach. Nie ma mowy, że powiedział. Zgodził się, że to może być AV.

Jak powiedziałem do osoby na platformie Azure poniżej, nie otrzymamy kontynuacji z oryginalnego plakatu, jeśli problem pojawi się ponownie po wyczyszczeniu dziennika zdarzeń, ponieważ jest to częste i błędne rozwiązanie, ponieważ wydajność z czasem ponownie się zmniejsza. Nazywa się to „kontynuacją” i widzę, że z pierwszej ręki oryginalne rozwiązanie plakatu może oszukać tych, którzy nie podejmą dalszych działań, wierząc, że rozwiązali problem. Niemal też dałem się zwieść. Wyczyściłem dziennik zdarzeń i poprawiłem wydajność - ale użyłem procmon i zobaczyłem, że problem będzie narastał i rozwijał się z czasem, aż stanie się problematyczny. Z jakiegoś powodu kolega z platformy Azure surowo mnie krytykuje, gdy oryginalny plakat nie był kontynuowany (być może umarł, został zwolniony, zrezygnował z pracy lub został zajęty). Przedstawiciel platformy Azure uważa, że ​​jeśli oryginalny plakat nie był kontynuowany, musi to być naprawiony problem. Jest to irytujące i zagadkowe, ponieważ nie mogę myśleć o nikim, kto byłby tak wysoko oceniany technicznie, kto zająłby to stanowisko. Przepraszam, jeśli zrobiłem nerw. Być może w mojej aktywizacji gdzie indziej w Internecie, w której wzywam ludzi, wpadłem mu w nerwy - tutaj (błąd serwera) po prostu jestem uprzejmy i dzielę się głęboką wiedzą techniczną, a wynik pana Azurea zastrasza, czy mój wkład techniczny jest nawet konieczne lub jest dla mojego bloga (nie mam takiego bloga). Nie zamierzam jeszcze wysyłać tego linku do około pół tuzina kluczowych kumpli w firmie Microsoft i pytam ich, co się dzieje z tego rodzaju zastraszaniem od kluczowego pracownika MSFT, ponieważ jestem szczególnie skoncentrowany na jak najlepszym interesie społeczność na uwadze i poniższe odpowiedzi pana Azure są, w kilku słowach, niewiarygodne, witriolijne, denerwowanie i zastraszanie - jestem pewien, że niektórzy ludzie lubią to robić innym. Początkowo byłem obrażony, ale jestem ponad tym i wiem, że pasywni lub aktywni czytelnicy docenią to, co mówię, i docenią moje komentarze - stoję za nim w 100%, bez względu na legalistyczne powody, dla których jest to subtelnie nieodpowiednie tutaj, czy nie. M. Azure, proszę, okazuj życzliwość i powstrzymuj się od rzucania moich komentarzy w złym świetle. Po prostu przejdź przez to i okaż powściągliwość i nie komentuj ponownie. proszę, praktykujcie dobroć i powstrzymujcie się od przedstawiania moich komentarzy w złym świetle. Po prostu przejdź przez to i okaż powściągliwość i nie komentuj ponownie. proszę, praktykujcie dobroć i powstrzymujcie się od przedstawiania moich komentarzy w złym świetle. Po prostu przejdź przez to i okaż powściągliwość i nie komentuj ponownie.

Złupić

złupić
źródło
Wygląda na to, że zwracasz się do osób, które skomentowały, a nie OP i oryginalne pytanie. Sugerujesz, jak usunąć AV. OP już rozwiązał problem i zidentyfikował go jako problem z dziennikiem zdarzeń. Nie uważam tego za prawidłową odpowiedź.
David Makogon,
Nie udało się tego rozwiązać, jeśli dokładnie przeczytałeś plakaty i moje streszczenie. Musisz cierpieć z powodu tego problemu, aby parsować ich słowa znacznie ostrożniej niż robiłeś i to widziałeś. Przykro mi, że nie jesteś w stanie tego zrobić i tak surowo mnie osądziłeś. Na przykład OP powiedział, że wrócił do rozsądnego poziomu 5%, ale łatwo mógł powrócić po wyczyszczeniu dziennika, a on nie sprawdził - w rzeczywistości stało się to z innym komentatorem. Dlatego nic nie zostało rozwiązane, ponieważ nie potwierdził, że wyniki pozostały na poziomie 5% na stałe.
harry
Przepraszam Harry - to nie jest odpowiedź; zgłaszasz roszczenia do błędnego oprogramowania i mówisz OP, aby współpracował z ich firmą antywirusową. Jest to świetne dla twojego osobistego bloga lub artykułu, ale artykuł wstępny nie jest odpowiedzią na dwuletnie pytanie z zaakceptowaną odpowiedzią, z podstawową przyczyną niezwiązaną z antywirusem.
David Makogon
@harry zaskakująco wróciłem tu ponownie, próbując to wszystko rozgryźć :) Brak systemu AV w systemie. Zrobiłem kilka aktualizacji systemu Windows i zmieniłem maksymalny plik dziennika do archiwizacji do 500 MB z 1 GB. Nawet przy 1 GB przewijał się tylko raz na 8 miesięcy, podczas gdy mój inny DC przewijał się o wiele więcej. Postępowałem zgodnie z sugestią „SC config EventLog Type = own”, aby rozbić plik dziennika. Po ponownym uruchomieniu proces Evenlog spadł poniżej 1%. „Dhcp i lmhosts”, które zostały dołączone do procesu, mają również poniżej 1% CPU. Rejestrowałem tylko około 15 zdarzeń bezpieczeństwa na sekundę.
Travis
Podejrzewałem, że agent SSO, który uruchomiłem, miał z tym coś wspólnego, ponieważ miał wiele błędów, ale wyłączenie usługi nie spowodowało spadku zużycia procesora nawet po ponownym uruchomieniu. Agent SSO został ponownie uruchomiony, a procesor jest nadal niski, więc kto wie.
Travis