Windows Server 2008

Mierzymy puls naszego serwera Udostępnij na: Facebook

Autor: Steven Choy

Opublikowano: 8 stycznia 2009

Zawartość strony
 Zwiększanie czytelności wyników   Zwiększanie czytelności wyników
 Co i kiedy mierzyć   Co i kiedy mierzyć
 Wąskie gardła dysku twardego   Wąskie gardła dysku twardego
 Wąskie gardło pamięci   Wąskie gardło pamięci
 Wąskie gardło procesora   Wąskie gardło procesora
 Wąskie gardło sieci   Wąskie gardło sieci
 Wąskie gardło procesu   Wąskie gardło procesu
 Podsumowanie   Podsumowanie

Wyobraźmy sobie, że jest poniedziałek rano, a w biurze wita nas niecierpliwy użytkownik, który narzeka, że serwer działa zbyt wolno. Od czego zacząć pomoc?

Monitor wydajności, wygodne narzędzie wbudowane w Windows, może ułatwić nam zdiagnozowanie problemu.

Do Monitora wydajności można wejść, wpisując perfmon w wierszu poleceń lub wybierając Wydajność (Performance) lub Niezawodność (Reloability) oraz Monitor wydajności (w Windows Vista i Windows Server 2008) z menu Narzędzia administracyjne (Administrative Tools). Aby dodać liczniki wydajności i obiekty, które mają być monitorowane, trzeba po prostu kliknąć znak plus i dokonać wyboru z mnóstwa możliwych opcji.

Jak więc mierzymy puls serwera? Jest ponad 60 podstawowych obiektów wydajności, a każdy obiekt zawiera wiele liczników. W tym artykule, omawiam liczniki, które ukazują istotne informacje o pracy serwera oraz opisuję typowe przedziały próbkowania, które najczęściej stosują inżynierowie Microsoft Service Support do rozwiązywania problemów związanych z wydajnością.

Oczywiście decydujący punkt odniesienia przy rozwiązywaniu problemów zapewnia linia bazowa. Ponieważ obciążenie serwera zależy od wymagań biznesowych i zmienia się od czasu do czasu, zależnie od cyklu biznesowego, ważne jest zdefiniowanie linii bazowej ustalonej przy normalnym obciążeniu w określonym przedziale czasu. To pozwala nam obserwować zmiany i rozpoznawać trendy.

Zwiększanie czytelności wyników

Zanim zagłębimy się w analizę liczników, które reprezentują podstawowe informacje o serwerach, podam dwa triki, które ułatwiają pomiar ważnych informacji o serwerach przy użyciu Monitora wydajności. Zwróćmy uwagę, że te triki nie są potrzebne w Windows Vista oraz Windows Server 2008, lecz jeśli uruchamiamy Monitor wydajności we wcześniejszych wersjach Windows, te dwa ulepszenia mogą okazać się bardzo przydatne.

Po pierwsze, można usunąć cały rozpraszający szum próbkowania, który zakrywa graficzny widok linii trendu. W Windows Vista oraz Windows Server 2008, Monitor wydajności może wyświetlać do 1000 punktów danych w widoku graficznym. W poprzednim wersjach Windows, limitem było tylko 100 punktów danych. Kiedy punktów jest więcej niż 100, Monitor wydajności „pakietuje” punkty danych. Pakiet jest reprezentowany przez linię pionową, wskazującą wartość minimalną, średnią i maksymalną punktów próbek zawartych w pakiecie.

Patrząc na wykres z rysunku 1, trudno dostrzec linie trendu, gdy w tym jednocześnie jest wyświetlonych tak dużo danych. Wykres z rysunku 2 pokazuje, o ile łatwiej szybko zrozumieć dane, gdy wszystkie nieistotne informacje wizualne są wyłączone. Szczegóły na temat tego, tak wyłączać te pionowe linie, można znaleźć w artykule dostępnym na stronie support.microsoft.com/kb/283110.

Rysunek 1 : Dane o wydajności pokazane z rozpraszającymi pakietami i bez przecinków.

Rysunek 2 : Oczyszczony widok danych z przecinkami rozdzielającymi.

Druga sztuczka polega na dodaniu przecinków jako separatorów w liczbach, co ułatwia czytanie wartości pokazanych w licznikach. Windows Vista oraz Windows Server 2008 domyślnie włączają przecinki rozdzielające. Jednak w poprzednich wersjach Windows Monitor wydajności nie robi tego domyślnie.

Być może nie wygląda to na wielką różnicę, lecz popatrzmy na rysunek 1, który pokazuje liczniki wydajności bez przecinków, a następnie popatrzmy na rysunek 2, który przedstawia liczniki z przecinkami. Ten ostatni jest znacznie bardziej czytelny. Proste instrukcje na temat dodawania przecinków do liczników wydajności w Windows XP, można znaleźć w artykule pod adresem support.microsoft.com/kb/300884.

 Do początku strony Do początku strony

Co i kiedy mierzyć

Wąskie gardła występują, gdy zasób dochodzi do kresu swoich możliwości, co powoduje spowolnienie działania całego systemu. Wąskie gardło jest zwykle spowodowane przez niewystarczające lub źle skonfigurowane zasoby, źle działające komponenty oraz nieprawidłowe żądania zasobów przez program.

Jest pięć podstawowych obszarów zasobów, które mogą spowodować wąskie gardła i mieć wpływ na wydajność serwera: dysk fizyczny, pamięć, proces, procesor oraz sieć. Jeśli którykolwiek z tych zasobów jest nadmiernie wykorzystywany, nasz serwer lub aplikacja mogą stać się wyraźnie wolniejsze lub się zawiesić. Przejdę przez wszystkie te obszary, podając wskazówki dotyczące liczników, które powinny być stosowane oraz proponowane progi pomiarów pulsu naszych serwerów.

Ponieważ odstęp próbkowania ma znaczący wpływ na rozmiar pliku rejestru oraz obciążenie serwera, trzeba ustawić ten odstęp na podstawie średniego czasu pomiędzy wystąpieniami problemu , aby można było ustalić linię bazową, zanim problem ponownie się pojawi. To pozwoli na wykrycie każdego trendu prowadzący do tego problemu.

Piętnaście minut stanowi dobre okno do ustalania linii bazowej podczas normalnej pracy. Ustawmy odstęp próbkowania na 15 sekund, jeśli średni czas, jaki upływa do pojawienia się problemu to około cztery godziny. Jeśli czas pojawiania się problemu, to osiem godzin lub więcej, ustawiamy odstęp próbkowania na nie mniej niż pięć minut; w innym przypadku dostaniemy na koniec bardzo duży plik rejestru, co utrudni analizę danych.

 Do początku strony Do początku strony

Wąskie gardła dysku twardego

Ponieważ system dysków przechowuje i obsługuje programy oraz dane na serwerze, wąskie gardło dotyczące użycia i szybkości dysku będzie miało duży wpływ na całkowitą wydajność serwera.

Zwróćmy uwagę, że jeśli obiekty dysku nie były uaktywnione na naszym serwerze, aby je włączyć trzeba użyć narzędzia wiersza poleceń Diskperf,. Zauważmy także, że Czas dysku (%) (% Disk Time) może przekraczać 100 procent, dlatego wolę używać liczników Czas bezczynności (%) (% Idle Time), Odczyty dysku/s (Avg. Disk sec/Read) oraz Zapisy dysku/s (Avg. Disk sec/write), które dają mi bardziej dokładny obraz tego, jak zajęty jest dysk twardy. Więcej na temat licznika Czasu dysku (%) można znaleźć w artykule na stronie support.microsoft.com/kb/310067.

Poniżej podane są liczniki, na których opierają się inżynierowie Microsoft Service Support przy monitorowaniu dysku.

  • Dysk logiczny\Wolny obszar (%) (LogicalDisk\% Free Space) Mierzy procent wolnego obszaru na wybranym dysku logicznym. Musimy zwrócić uwagę na wartość poniżej 15 procent, gdyż ryzykujemy wyczerpanie się wolnego obszaru dla systemu operacyjnego do przechowywania plików krytycznych. Oczywistym rozwiązaniem jest tutaj dodanie większego obszaru dysku.
  • Dysk fizyczny\Czas bezczynności (%) (PhysicalDisk\% Idle Time) Mierzy procent czasu, w jakim dysk był bezczynny podczas czasu próbkowania. Jeśli licznik ma wartość poniżej 20 procent, system dyskowy jest zapełniony. Można rozważyć zastąpienie obecnego systemu dyskowego przez szybszy system.
  • Dysk fizyczny\Odczyty dysku/s (PhysicalDisk\Avg. Disk Sec/Read) Mierzy w sekundach średni czas odczytu danych z dysku. Jeśli liczba jest większa niż 25 milisekund (ms), oznacza to, że system dyskowy doznaje opóźnień podczas czytania z dysku. W przypadku serwerów krytycznych dla misji, udostępniających SQL Server® i Exchange Server, akceptowany próg jest dużo niższy, w przybliżeniu 10 ms. Najbardziej logicznym rozwiązaniem jest tutaj zastąpienie obecnego systemu dyskowego szybszym systemem.
  • Dysk fizyczny\Zapisy dysku/s (PhysicalDisk\Avg. Disk Sec/Write) Mierzy w sekundach średni czas zapisu danych na dysk. Jeśli liczba jest większa niż 25 milisekund (ms), oznacza to, że system dyskowy doznaje opóźnień podczas zapisywania na dysk. W przypadku serwerów krytycznych dla misji, udostępniających SQL Server® i Exchange Server, akceptowany próg jest dużo niższy, w przybliżeniu 10 ms. Przypuszczalnym rozwiązaniem jest tutaj zastąpienie obecnego systemu dyskowego szybszym systemem.
  • Dysk fizyczny\Średnia długość kolejki dysku ( PhysicalDisk\Avg. Disk Queue Length) Wskazuje, ile operacji we/wy czeka na udostępnienie dysku twardego. Jeśli ta wartość jest większa niż dwukrotna liczba szpindli, oznacza to, że sam dysk może być wąskim gardłem.
  • Pamięć\Bajty pamięci podręcznej (Memory\Cache Bytes) Wskazuje rozmiar pamięci używanej jako pamięć podręczna systemu plików. Może być wąskim gardłem dysku, jeśli ma wartość przekracza 300 MB.

 Do początku strony Do początku strony

Wąskie gardło pamięci

Brak pamięci zwykle jest spowodowany zbyt małą pamięcią RAM, brakiem pamięci lub przełącznikiem pamięci umieszczonym w boot.ini. Zanim przejdziemy do liczników, trzeba omówić przełącznik /3GB.

Więcej pamięci redukuje aktywność we/wy dysku, co z kolei poprawia wydajność aplikacji. Przełącznik /3GB został wprowadzony w Windows NT jako metoda zapewniania większej pamięci dla programów w trybie użytkownika.

Windows wykorzystuje wirtualny obszar adresowy o wielkości 4 GB (niezależnie ot tego, ile pamięci fizycznej RAM ma system). Domyślnie dolne 2 GB są zarezerwowane dla programów w trybie użytkownika, a górne 2 GB dla programów w trybie jądra. Za pomocą przełącznika /3GB, 3 GB są dawane procesom w trybie użytkownika. To oczywiście dzieje się kosztem pamięci jądra, które będzie miało tylko 1 GB wirtualnego obszaru pamięci. Może to spowodować problem, ponieważ Bajty w puli niestronicowanej (Pool Non-Paged Bytes), Bajty w puli stronicowanej (Pool Paged Bytes), Swobodne wpisy tabeli stron systemu (Free System Page Tables Entries) oraz sterta pulpitu są ściśnięte razem w tym jednogigabajtowym obszarze. Dlatego przełącznik /3GB powinien być stosowany tylko po gruntownym przetestowaniu w danym środowisku.

Trzeba to wziąć pod uwagę, jeśli podejrzewamy, że mamy do czynienia z wąskim gardłem związanym z pamięcią. Jeśli przełącznik /3GB nie jest przyczyną problemu, można użyć tych liczników do diagnozowania potencjalnego wąskiego gardła pamięci.

  • Pamięć\Zadeklarowane bajty w użyciu (%) (Memory\% Committed Bytes in Use) Mierzy współczynnik zadeklarowanych bajtów do zadeklarowanego limitu – innymi słowy, rozmiar wirtualnej pamięci w użyciu. Wskazuje na brak pamięci, jeśli ta liczba jest większa niż 80 procent. Oczywistym rozwiązaniem jest w tej sytuacji dodanie więcej pamięci.
  • Pamięć\Dostępna pamięć (MB) (Memory\Available Mbytes) Mierzy w megabajtach rozmiar pamięci fizycznej, dostępnej do uruchamiania procesów. Jeśli ta wartość jest mniejsza niż 5 procent całkowitej fizycznej pamięci, oznacza to, że rozmiar pamięci jest niewystarczający i że może to zwiększyć aktywność stronicowania. Aby rozwiązać ten problem, trzeba po prostu dodać więcej pamięci.
  • Pamięć\ Swobodne wpisy tabeli stron systemu ( Memory\Free System Page Table Entries) Wskazuje liczbę wpisów tabeli stron systemu, które nie są aktualnie wykorzystywane przez system. Jeśli ta liczba jest mniejsza niż 5000, może wystąpić wyciek pamięci.
  • Pamięć\ Bajty w puli niestronicowanej (Memory\Pool Non-Paged Bytes) Mierzy w bajtach rozmiar puli niestronicowanej. Jest to obszar pamięci systemu dla obiektów, które nie mogą być zapisywane na dysk, lecz zamiast tego muszą pozostawać w pamięci fizycznej ta długo, jak długo są przydzielone. Jeśli ta wartość jest większa niż 175 MB (lub 100 MB z przełącznikiem /3GB), możliwy jest wyciek pamięci. Typowy identyfikator zdarzenia (Event ID) 2019 jest zapisywany w dzienniku zdarzeń systemu.
  • Pamięć\Bajty w puli stronicowanej (Memory\Pool Paged Bytes) Mierzy w bajtach rozmiar puli stronicowanej. Jest to obszar pamięci systemu dla obiektów, które mogą być zapisywane na dysku, gdy nie są używane. Jeśli ta wartość jest większa niż 250 MB (lub 170 MB z przełącznikiem /3GB), możliwy jest wyciek pamięci. Typowy identyfikator zdarzenia (Event ID) 2020 jest zapisywany w dzienniku zdarzeń systemu.
  • Pamięć\Strony/s (Memory\Pages per Second) Mierzy tempo, w którym strony są czytane z dysku lub na nim zapisywane, aby rozwiązać błędy wymuszonego końca strony. Jeśli ta wartość w wyniku nadmiernego stronicowania jest większa niż 1000, może mieć miejsce wyciek pamięci.

 Do początku strony Do początku strony

Wąskie gardło procesora

Przeciążenie procesora może być spowodowane tym, że sam procesor nie ma wystarczającej mocy lub może być wynikiem niewydajnej aplikacji. Trzeba dokładnie sprawdzić, czy procesor nie poświęca za dużo czasu na stronicowanie w wyniku braku dostatecznej pamięci fizycznej. Przy badaniu potencjalnego wąskiego gardła procesora, inżynierowie Microsoft Service Support korzystają z podanych poniżej liczników.

  • Procesor\Czas procesora (%) (Processor\% Processor Time) Mierzy procent czasu, jaki upłynął, w którym procesor jest zajęty przy wykonywaniu aktywnego wątku. Jeśli procent jest większy niż 85, procesor jest przeciążony, a serwer może wymagać szybszego procesora.
  • Procesor\Czas użytkownika (%) (Processor\% User Time) Mierzy procent czasu, jaki procesor jest zajęty w trybie użytkownika. Jeśli ta wartość jest duża, serwer jest zajęty przy wykonywaniu aplikacji. Jedynym z możliwym rozwiązań jest tutaj optymalizacja aplikacji, która zużywa zasoby procesora.
  • Procesor\Czas przerwań (%) (Processor\% Interrupt Time) Mierzy czas, jaki procesor poświęca na odbieranie i obsługiwanie przerwań sprzętowych podczas określonych odstępów próbkowania. Jeśli wartość licznika jest większa niż 15 procent, wskazuje to możliwe problemy sprzętowe.
  • System\Długość kolejki procesora (System\Processor Queue Length) Wskazuje liczbę wątków w kolejce procesora. Jeśli ta liczba jest dwukrotnie większa od liczby procesorów dla dłuższego okresu czasu, serwer nie ma dostatecznej mocy procesora.

 Do początku strony Do początku strony

Wąskie gardło sieci

Wąskie gardło sieci, ma oczywiście wpływ na zdolność serwera do wysyłania i odbierania danych w całej sieci. To może być problem z kartą sieciową na serwerze, a być może sieć jest nasycona i powinna być podzielona na segmenty. Do diagnozowania potencjalnych wąskich gardeł sieci można użyć podanych poniżej liczników.

  • Interfejs sieciowy\Całkowita liczba bajtów/s (Network Interface\Bytes Total/Sec) Mierzy tempo, w jakim bajty są wysyłane i odbierane w każdym adapterze sieci, łącznie ze znakami ramki. Sieć jest nasycona, jeśli odkryjemy, że jest wykorzystane ponad 70 procent interfejsu. Dla NIC o szybkości 100-Mb/s, interfejs zużywa 8,7MB/s (100 Mb/s = 100000 kb/s = 12,5 MB/s* 70 procent). W takiej sytuacji można dodać szybszą kartę sieciową lub podzielić sieć na segmenty.
  • Interfejs sieciowy \Długość kolejki wyjściowej (Network Interface\Output Queue Length) Mierzy długość kolejki pakietów wyjściowych liczoną w pakietach. Jeśli ta wartość jest większa niż 2, sieć jest nasycona. Można rozwiązać ten problem, dodając szybszą kartę sieciową lub segmentując dysk.

 Do początku strony Do początku strony

Wąskie gardło procesu

Na wydajność serwera będzie znacząco wpływać źle zachowujący się lub niezoptymalizowany proces. Wycieki wątków i dojść będą ostatecznie prowadzić do zawieszenia a serwera, a nadmierne użycie procesora spowoduje jego powolną pracę. Poniższe liczniki są niezbędne przy diagnozowaniu wąskich gardeł związanych z procesem.

  • Proces\ Licznik dojść (Process\Handle Count) Mierzy całkowitą liczbę dojść, które są aktualnie otwarte przez proces. Jeśli ten licznik ma wartość większą od 10 000, oznacza to możliwy wyciek dojść.
  • Proces\ Liczba wątków (Process\Thread Count) Mierzy liczbę wątków aktualnie aktywnych w procesie. Jeśli ten licznik ma wartość większą od 500 między minimalną a maksymalną liczbą wątków, oznacza to możliwy wyciek dojść.
  • Proces\ Bajty prywatne (Process\Private Bytes) Wskazuje rozmiar pamięci, która jest przypisana do tego procesu i która nie może być współużytkowana z innymi procesami. Jeśli ta wartość jest większa niż 250 między minimalną a maksymalną liczbą wątków, może to oznaczać wyciek pamięci.

 Do początku strony Do początku strony

Podsumowanie

Teraz wiemy, z jakich liczników korzystają inżynierowie z Service Support w firmie Microsoft do diagnozowania różnych wąskich gardeł. Oczywiście najbardziej prawdopodobne jest, ze będziemy korzystać ze swojego zestawu ulubionych liczników, dostosowanego do własnych, specyficznych potrzeb. Możemy oszczędzić czas, jeśli nie będziemy musieli dodawać wszystkich swoich ulubionych liczników ręcznie za każdym razem, gdy potrzebujemy monitorować nasze serwery. Na szczęście w Monitorze wydajności jest opcja, która pozwala zapisywać wszystkie liczniki w szablonie do późniejszego użycia.

Można nadal się zastanawiać, czy należy uruchamiać Monitor wydajności lokalnie, czy też zdalnie. I jaki wpływ na wydajność otrzymamy, jeśli uruchomimy Monitor wydajności lokalnie? To zależy od określonego środowiska. Wpływ na wydajność serwera jest prawie pomijalna, jeśli ustawimy okresy próbkowania na przynajmniej pięć minut.

Możemy chcieć uruchomić Monitor wydajności lokalnie, jeśli wiemy, że istnieje problem z wydajnością serwera, ponieważ Monitor wydajności może nie być w stanie wyłapać danych ze zdalnej maszyny, gdy jest uruchomiony bez zasobów na serwerze. Uruchomienie go zdalnie z centralnej maszyny jest rzeczywiście najlepsze w sytuacjach, gdy chcemy monitorować lub ustalać linię bazową wielu serwerów.

O autorze

Steven Choy jest starszym inżynierem z Microsoft Premier Field Engineering. Obsługuje agencje rządowe oraz klientów komercyjnych z ich projektami dotyczącymi wdrożenia i migracji komputerów biurkowych, zarządzania aktualizacjami oraz zasad grup. Aktualnie koncentruje się na wizualizacji serwera i zdrowiu serwera.

 Do początku strony Do początku strony

Windows Server 2008