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.
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.
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 .
W tym momencie zabrakło mi kawy i pomysłów. Jak mam dalej rozwiązywać ten problem?
mmc.exeotwartym (prawdopodobnie domyślnym oknem „Menedżera serwera?”) Osiągnęła również regularne skoki.Odpowiedzi:
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.
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).
Oto spojrzenie na stos jednego z tych wydarzeń:
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%.
źródło
Możesz być w stanie to ścigać, tworząc mały zestaw modułów zbierających dane.
tracerpt –l “file.etl” –of CSVJeśli moje przeczucie jest prawidłowe, zobaczysz, że niektóre urządzenia (IP: port) wbijają DC.
źródło
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
źródło
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ć
źródło