Serwer terminali R2 z 2008 r .: „Nie ma wystarczających zasobów systemowych, aby ukończyć żądaną usługę”

Pracuję z niezdrowym serwerem terminali Windows 2008 R2 skonfigurowanym w środowisku vSphere. Obecnie ma 4 vCPU i 32 GB pamięci RAM. Bez nadmiernego zaangażowania.

Liczba jednoczesnych użytkowników na tym serwerze gwałtownie wzrosła w ostatnich miesiącach (~ 70) i ​​prawdopodobnie przekracza zalecany poziom. Ze względu na aplikacje używane przez użytkowników w tym systemie podział na wiele serwerów będzie wyzwaniem wykraczającym poza zakres tego pytania.

Jednak w niektórych punktach w ciągu tygodnia (a teraz prawie codziennie) nowe logowania użytkowników powodują następujące błędy: Identyfikator zdarzenia 1500

System Windows nie może się zalogować, ponieważ nie można załadować Twojego profilu. Sprawdź, czy masz połączenie z siecią i czy sieć działa poprawnie.

SZCZEGÓŁY - Nie ma wystarczających zasobów systemowych, aby ukończyć żądaną usługę.

Pozostaje to do momentu wylogowania się niektórych użytkowników, ręcznego odłączenia sesji lub całkowitego zrestartowania systemu.

Chciałbym wiedzieć:

• Do jakich zasobów odnosi się ten komunikat o błędzie? Co jest właściwie ograniczone?
• Czy istnieje możliwość strojenia lub konfiguracji na poziomie systemu operacyjnego, która może w tym pomóc?
• Użytkownicy są zadowoleni z wydajności, z wyjątkiem zwiększonej częstotliwości tego komunikatu o błędzie. Czy jest tu coś innego?
• Czy istnieje bezwzględny limit liczby użytkowników, które może pomieścić serwer terminali? Widzę ponad 150 użytkowników opisanych w niektórych przewodnikach dostrajania serwerów terminali.

Zostało to rozwiązane.

Zacząłem sprawdzać rejestr, ponieważ zwiększenie zasobów procesora i pamięci RAM na maszynie wirtualnej nie rozwiązało problemu.

Wskazano mi narzędzie dureg Microsoftu do oszacowania wielkości rejestru. Przeglądając regedit, napotkałem problemy z otwieraniem kluczy pod HKEY_USERS\.Default\PRINTERS. Używając dureg, zacząłem sondować w tej hierarchii.

Problemem były drukarki. Przyczyna i naprawa są szczegółowo opisane w:
Rozmiar gałęzi rejestru „HKEY_USERS.DEFAULT” stale rośnie na serwerze z systemem Windows Server 2008 R2 z dodatkiem SP1

Poprawka: http://support.microsoft.com/kb/2871131

To najwyraźniej zatrzymuje wzrost, ale klucze i rejestr muszą zostać skompresowane, aby odzyskać miejsce.

Kompresowanie nadętego rejestru: http://support.microsoft.com/kb/2498915

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

Hmm, kilka kroków ... trochę trudne do zrobienia zdalnie w godzinach produkcji. Próbowałem skontaktować się z moim rezydentem, ekspertem Microsoft , ale był zajęty ściganiem jakiegoś problemu SCCM lub SCVMM . Czytając niektóre fora związane z Citrix, zauważyłem narzędzie, które może wykonać powyższe czynności przy mniejszej liczbie kroków ...

Zrobiłem więc migawkę maszyny wirtualnej, a następnie pobrałem i uruchomiłem bezpłatne oprogramowanie do kompresji rejestru (Tweaking.com) ; pomimo przytłaczającego dźwięku zbiorowych jęków inżynierów systemów Microsoft na całym świecie ...

zwróć uwagę na 1,4 GB zapisane w domyślnej konfiguracji ...

PROSZĘ Zrestartować!

Po ponownym uruchomieniu wszystko poszło dobrze. Liczba użytkowników osiągnęła 86 bez złych efektów i bez błędów związanych z profilem. Monitorowałem gałąź rejestru drukarki i jest stabilna.

W systemie Windows Server 2003 błąd ten był wynikiem wyczerpania pamięci jądra. Ponieważ masz do czynienia z systemem Windows Server 2008 R2, nie jestem pewien, jak ściśle jest związana przyczyna problemu z przyczyną w W2K3, ale założę się, że jest to problem z pamięcią ze względu na liczbę użytkowników i procesów. Przyjrzałbym się wyczerpaniu pamięci puli niestronicowanej jako prawdopodobną przyczynę. Ponadto liczba procesów wynosi prawie 800, co jest dość wysoką wartością. MS prawdopodobnie powiedziałby ci, aby zmniejszyć liczbę procesów, co można zrobić tylko poprzez zmniejszenie obciążenia użytkownika.

W tym artykule zawarto kilka dobrych informacji dotyczących wykorzystania pamięci w systemie Windows i sposobu wyświetlania limitu puli niestronicowanej, aby sprawdzić, czy to jest przyczyną problemu:

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Uruchom Monitor wydajności systemu Windows, aby monitorować różne liczniki:

• Przełączniki kontekstowe
• Wpisy tabeli stron
• Elementy GDI
• Uchwyty
• … (Cokolwiek można znaleźć)

I sprawdź, czy któryś z tych szczytów występuje po nieudanym logowaniu.

Ponadto: coś powoduje wysoki procesor jądra w twoim systemie - powinieneś to sprawdzić, aby zobaczyć, czy prowadzi to do powiązanego problemu.

Usługa czyszczenia gałęzi profilu użytkownika może tutaj pomóc, ponieważ „pomaga zapewnić całkowite zakończenie sesji użytkownika, gdy użytkownik się wyloguje”.

Cóż, z tego, co przeczytałem o planowaniu pojemności RDS w Server 2008 R2, możesz po prostu używać słabego serwera terminali przy niewystarczających zasobach dla liczby użytkowników, którzy go używają. W szczególności zauważam, że masz 80 użytkowników na 4 vCPUS, a MS zaleca 1 rdzeń na 15 użytkowników.

Z blogu technet zatytułowanego Wskazówki dotyczące planowania i określania wielkości RDS :

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

• 2 GB pamięci (RAM) to optymalny limit dla każdego rdzenia procesora. Np. Jeśli masz 4 GB pamięci RAM, aby uzyskać optymalną wydajność, powinien być dwurdzeniowy procesor.
• 2 dwurdzeniowy procesor działa lepiej niż pojedynczy czterordzeniowy procesor.
• Zalecana przepustowość dla sieci LAN dla 30 użytkowników i WAN dla 20 użytkowników. Przepustowość (b) = 100 megabitów na sekundę (Mb / s) przy opóźnieniu (l) Mniej niż 5 milisekund.
• Na serwerze terminali 64 MB na użytkownika jest wymaganiem Idealnej pamięci (RAM) dla GP Użyj tylko 2 GB dla systemu operacyjnego Np. (100 użytkowników * 64) + 2000 = 8,4 GB, tj. 8 GB RAM.
• Więcej używanych aplikacji (np. Office, aplikacje CAD itp.) Będzie wymagało dodania większej ilości pamięci na użytkownika do tego obliczenia w porównaniu z 64 MB pamięci podstawowej na użytkownika.
• 15 sesji TS na rdzeń procesora to optymalny limit wydajności serwera terminali.
• Sieć nie powinna mieć więcej niż 5 przeskoków, a opóźnienie powinno wynosić poniżej 100 ms.
• 64 kb / s to idealna przepustowość na sesję użytkownika. (256 kolorów, sieć przełączana, tylko buforowanie bitmap)
• Wydajność procesora spada, jeśli% czasu procesora na rdzeń jest stale powyżej 65%.
• Wydajność serwerów terminali podwaja się, gdy działa na X64 HW i systemie operacyjnym.

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

Pobierz to tutaj

Mam bardzo mało czasu, więc zrobię tylko szkicową odpowiedź i mam nadzieję, że później ją uzupełnię.

Kiedy robiłem zaklęcia w zespołach Citrix, przypominam sobie, że próbowaliśmy wyrównać do 15-20 użytkowników na serwer, ale te miały uruchomione ciężkie aplikacje. W dzisiejszych czasach x64 wczytujemy więcej użytkowników, ale 70+ nie brzmi dużo.

Maksymalne przekroczenie licznika perfmon nie było rzadko przełączaniem kontekstu, umieszczało serwer na podłodze, podczas gdy inne liczniki, takie jak RAM, CPU itp., Wyglądały dobrze. Być może to może być powód (serwer nie może przydzielić zasobów przed przekroczeniem limitu czasu z powodu nadmiernego przełączania kontekstu). Oto dwa sposoby monitorowania przełączania kontekstu :

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

Możesz również znaleźć coś użytecznego w przewodniku planowania wydajności, znajdziesz link do tego w tym poście na blogu .

Kiedy będę mógł uzyskać czas na odpowiedź, zrobię to, dodając tutaj ostrzeżenie o wszystkich pomiarach opartych na czasie na maszynie wirtualnej vSphere.

Ze względu na to, jak vCPU zostało wydzielone z fizycznych procesorów, vCPU nie ma pojęcia, która jest godzina (jedna wirtualna sekunda może być większa lub mniejsza niż jedna rzeczywista (lub przynajmniej fizyczna) sekunda. W konsekwencji, oparta na czasie) liczniki perfmon (czas procesora, przełączniki kontekstu / s itd.) są niedokładne (czasem nawet bardzo dzikie), nawet jeśli mogą służyć jako bardzo gruboziarniste wskaźniki.

Aby to sprawdzić, porównaj dowolny licznik procesorów oparty na czasie natywnym w maszynie wirtualnej z jej odpowiednikiem na hoście vSphere dla tej maszyny wirtualnej. Z tego powodu VMware publikuje niektóre liczniki procesora (i pamięci, która również jest niedokładna z perspektywy gościa) za pośrednictwem narzędzi VMware do dwóch obiektów perfgu VMguest.

W ten sposób poprawne wartości oparte na czasie są udostępniane z poziomu konta gościa, ale tylko jeśli spojrzymy na liczniki obiektów opublikowanych VMware.

Pomyślałem, że ta podstawowa informacja jest trochę istotna, ponieważ dotychczasowe odpowiedzi koncentrują się na pomiarach czasowych z poziomu maszyny wirtualnej vSphere, gdzie w niektórych przypadkach jest to kluczowa okoliczność dla prawidłowej analizy. Odnosi się również oczywiście bezpośrednio do tematu tej konkretnej (niedokończonej) odpowiedzi i jej komentarzy. Może być komuś przydatny.

Jak tylko będę miał czas, dokonam edycji w linkach do oficjalnych dokumentów itp., Które to rozwiną, oraz dokładnych ścieżek liczników \ ​​nazw. Oczywiście wszystko jest również Google.

Sugerowałbym wdrożenie WSRM (Windows System Resource Manager). Kiedy jest mnóstwo aplikacji, połączeń, usług działających na jednym hoście, system nie wie, że wszyscy muszą dobrze się bawić. Windows Server naturalnie próbuje wykorzystać wszystkie swoje zasoby, aby uzupełniać wszystko przez cały czas, chyba że zostanie poinformowany ... wejdź w WSRM.

Wdrażając WSRM, możesz ustawić limity zasobów według różnych odmian, aby zapewnić równe szanse wszystkim działającym użytkownikom lub użytkownikom podłączonym. Z twoich notatek nie wydaje się, aby był to problem ESX / vSphere, ale raczej zbyt wielu połączonych użytkowników, którzy stale walczą o wszystko. Będziesz musiał przetestować WSRM, aby znaleźć szczęśliwy środek równoważący zasoby między wszystkim, ale także nie wpływający na poziomy wydajności, do których wszyscy się przyzwyczaili.

Przegląd WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx