2008 R2 Terminal Server: "Es sind nicht genügend Systemressourcen vorhanden, um den angeforderten Dienst abzuschließen."

Ich arbeite mit einem fehlerhaften Windows 2008 R2-Terminalserver, der in einer vSphere-Umgebung konfiguriert ist. Es verfügt derzeit über 4 vCPUs und 32 GB RAM. Keine Überbindung.

Die Anzahl der gleichzeitigen Benutzer auf diesem Server ist in den letzten Monaten stark angestiegen (~ 70) und liegt möglicherweise über dem empfohlenen Wert. Aufgrund der von den Benutzern auf diesem System verwendeten Anwendungen ist die Aufteilung in mehrere Server eine Herausforderung, die den Rahmen dieser Frage sprengt.

Zu bestimmten Zeitpunkten während der Woche (und jetzt fast täglich) führen neue Benutzeranmeldungen jedoch zu folgenden Fehlern: Ereignis-ID 1500

Windows kann Sie nicht anmelden, da Ihr Profil nicht geladen werden kann. Stellen Sie sicher, dass Sie mit dem Netzwerk verbunden sind und dass Ihr Netzwerk ordnungsgemäß funktioniert.

DETAIL - Es sind nicht genügend Systemressourcen vorhanden, um den angeforderten Dienst auszuführen.

Dies bleibt so lange bestehen, bis sich einige Benutzer abmelden, Sitzungen manuell getrennt werden oder das System vollständig neu gestartet wird.

Ich würde gerne wissen:

• Auf welche Ressource (n) bezieht sich diese Fehlermeldung? Was ist eigentlich eingeschränkt?
• Gibt es ein Tunable oder eine Konfiguration auf Betriebssystemebene, die dabei helfen können?
• Die Benutzer sind mit der Leistung zufrieden, mit Ausnahme der erhöhten Häufigkeit dieser Fehlermeldung. Spielt hier noch etwas?
• Gibt es ein absolutes Limit für die Anzahl der Benutzer, die ein Terminalserver aufnehmen kann? Ich sehe mehr als 150 Benutzer in bestimmten Optimierungshandbüchern für Terminalserver beschrieben.

Dies wurde behoben.

Ich begann die Registrierung zu untersuchen, da das Problem durch Erhöhen der CPU- und RAM-Ressourcen auf der virtuellen Maschine nicht behoben werden konnte.

Ich wurde auf das Dureg- Tool von Microsoft verwiesen , um die Größe der Registrierung abzuschätzen. Beim Browsen über regedit sind Probleme beim Öffnen der Schlüssel unter aufgetreten HKEY_USERS\.Default\PRINTERS. Mit duregbegann ich unter dieser Hierarchie zu suchen.

Drucker waren das Problem. Ursache und Fehlerbehebung finden Sie unter:
Die Größe der Registrierungsstruktur "HKEY_USERS.DEFAULT" nimmt auf einem Windows Server 2008 R2 SP1-basierten Server kontinuierlich zu

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

Dies stoppt anscheinend das Wachstum, aber die Schlüssel und die Registrierung müssen komprimiert werden, um Speicherplatz freizugeben.

Aufgeblähte Registrierung komprimieren: 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, ein paar Schritte ... irgendwie schwierig, während der Produktionsstunden aus der Ferne zu tun. Ich habe versucht, meinen ansässigen Microsoft-Experten zu erreichen, um den Vorgang abzuschließen, aber er war damit beschäftigt, irgendwo ein SCCM- oder SCVMM-Problem aufzuspüren . Beim Durchlesen einiger Citrix-bezogener Foren habe ich ein Tool zur Kenntnis genommen, mit dem das oben Genannte mit weniger Schritten ausgeführt werden kann ...

Also habe ich einen Snapshot einer virtuellen Maschine erstellt, dann eine Freeware-Registrierungskomprimierungssoftware (Tweaking.com) heruntergeladen und ausgeführt . trotz des überwältigenden Geräusches des kollektiven Stöhnens der Microsoft-Systemingenieure überall ...

Beachten Sie die in der Standardkonfiguration gespeicherten 1,4 GB.

BITTE NEUSTARTEN!

Nach einem Neustart war alles in Ordnung. Die Benutzeranzahl erreichte 86 ohne negative Auswirkungen und ohne profilbezogene Fehler. Ich habe die Registrierungsstruktur des Druckers überwacht und sie wird stabil gehalten.

In Windows Server 2003 war dieser Fehler auf die Erschöpfung des Kernelspeichers zurückzuführen. Da es sich um Windows Server 2008 R2 handelt, bin ich mir nicht sicher, wie eng die Ursache des Problems mit der Ursache in W2K3 zusammenhängt, aber ich wette, dass es sich aufgrund der Anzahl der Benutzer und Prozesse um ein Speicherproblem handelt. Ich würde einen Blick auf die Erschöpfung des nicht ausgelagerten Poolspeichers als wahrscheinliche Ursache werfen. Außerdem ist die Anzahl der Prozesse mit fast 800 recht hoch. MS würde Sie wahrscheinlich auffordern, die Anzahl der Prozesse zu reduzieren, was nur durch eine Reduzierung der Benutzerlast erreicht werden kann.

In diesem Artikel finden Sie einige nützliche Informationen zur Speichernutzung in Windows und dazu, wie Sie das Limit für nicht ausgelagerte Pools anzeigen können, um festzustellen, ob dies die Ursache des Problems ist:

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

Starten Sie den Windows-Systemmonitor, um die verschiedenen Leistungsindikatoren zu überwachen:

• Kontextwechsel
• Seitentabelleneinträge
• GDI-Elemente
• Griffe
• … (Was immer du finden kannst)

Und sehen Sie nach, ob einer dieser Peaks auftritt, wenn Sie eine fehlgeschlagene Anmeldung erhalten.

Außerdem: Etwas verursacht einen hohen Prozentsatz an Kernel-CPU auf Ihrem System - Sie sollten dies untersuchen, um festzustellen, ob es zu einem verwandten Problem führt.

Der Benutzerprofil-Bereinigungsdienst kann hier Abhilfe schaffen, da er "dazu beiträgt, dass Benutzersitzungen vollständig beendet werden, wenn sich ein Benutzer abmeldet".

Nach dem, was ich über die RDS-Kapazitätsplanung in Server 2008 R2 gelesen habe, wird Ihr schlechter Terminalserver möglicherweise nur mit unzureichenden Ressourcen für die Anzahl der Benutzer ausgeführt, die ihn verwenden. Insbesondere stelle ich fest, dass Sie 80 Benutzer mit 4 vCPUS haben, und MS empfiehlt 1 Core pro 15 Benutzer.

Aus dem Technet-Blog mit dem Titel RDS Sizing and Capacity Planning Guidance :

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 Arbeitsspeicher (RAM) ist die optimale Grenze für jeden Kern einer CPU. Wenn Sie beispielsweise 4 GB RAM haben, sollte für eine optimale Leistung eine Dual-Core-CPU vorhanden sein.
• 2 Dual Core-Prozessoren sind leistungsstärker als Single Quad Core-Prozessoren.
• Empfohlene Bandbreite für LAN von 30 Benutzern und WAN von 20 Benutzern. Bandbreite (b) = 100 Megabits pro Sekunde (Mbit / s) mit Latenz (l) Weniger als 5 Millisekunden.
• Auf einem Terminalserver sind 64 MB pro Benutzer die ideale Speicheranforderung (RAM) für GP. Verwenden Sie nur + 2 GB für das Betriebssystem, z. B. (100 Benutzer * 64) + 2000 = 8,4 GB, dh 8 GB RAM.
• Für mehr verwendete Anwendungen (z. B. Office, CAD-Apps usw.) muss mehr Speicher pro Benutzer zu dieser Berechnung hinzugefügt werden, und zwar über den 64-MB-Basisspeicher pro Benutzer.
• 15 TS-Sitzung pro CPU-Kern ist die optimale Leistungsgrenze eines Terminalservers.
• Das Netzwerk sollte nicht mehr als 5 Hops haben und die Latenz sollte unter 100 ms liegen.
• 64 kbit / s ist die ideale Bandbreite pro Benutzersitzung. (256 Farben, Switched Network, nur Bitmap-Caching)
• Die CPU-Leistung nimmt ab, wenn die prozentuale Prozessorzeit pro Kern konstant über 65% liegt.
• Die Leistung der Terminalserver verdoppelt sich, wenn sie unter einer X64-Hardware und einem Betriebssystem ausgeführt werden.

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

Hier herunterladen

Ich habe sehr wenig Zeit, deshalb werde ich nur eine skizzenhafte Antwort geben und sie hoffentlich später ausarbeiten.

Als ich in Citrix-Teams Zaubersprüche ausführte, haben wir versucht, 15 bis 20 Benutzer pro Server zu erreichen, auf denen jedoch einige schwere Apps ausgeführt wurden. In diesen Tagen von x64 laden wir mehr Benutzer, aber 70+ klingt nach viel.

Das Maximieren des Leistungsindikators war nicht selten eine Kontextumschaltung, sondern belegte einen Server, während andere Leistungsindikatoren wie RAM, CPU usw. gut aussahen. Möglicherweise kann dies ein Grund sein (der Server kann keine Ressourcen zuweisen, bevor das Zeitlimit abgelaufen ist, da zu viele Kontexte geändert wurden). Es gibt zwei Möglichkeiten, die Kontextumschaltung zu überwachen :

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.

Möglicherweise finden Sie im Handbuch zur Kapazitätsplanung auch einen Link dazu in diesem Blogbeitrag .

Wenn ich die Zeit für diese Antwort abrufen kann, füge ich hier nur eine Warnung zu allen zeitbasierten Messungen in einer virtuellen vSphere-Maschine hinzu.

Aufgrund der Art und Weise, wie die vCPU von den physischen CPUs abstrahiert wurde, hat die vCPU keine Ahnung, wie spät es ist (eine virtuelle Sekunde kann mehr oder weniger als eine reale (oder zumindest physische) Sekunde sein. Infolgedessen ist dies zeitbasiert Leistungsindikatoren (CPU-Zeit, Kontextwechsel / Sek. usw.) sind ungenau (manchmal sogar wild), selbst wenn sie als sehr grobkörnige Indikatoren dienen können.

Um dies zu überprüfen, vergleichen Sie einen nativen zeitbasierten CPU-Zähler in der VM mit dem entsprechenden Zähler auf dem vSphere-Host für diese VM. Aus diesem Grund veröffentlicht VMware einige Leistungsindikatoren für CPU (und Arbeitsspeicher, die auch aus Sicht des Gasts ungenau sind) über VMware-Tools in zwei VMguest-Perfmon-Objekten.

Somit werden die korrekten zeitbasierten Werte innerhalb des Gastperfmons verfügbar gemacht, aber nur, wenn man sich die Zähler für veröffentlichte VMware-Objekte ansieht.

Ich fand diese grundlegenden Informationen nur ein wenig relevant, da sich die bisherigen Antworten auf zeitbasierte Messungen innerhalb einer virtuellen vSphere-Maschine konzentrieren, wobei dies in einigen Fällen ein entscheidender Umstand für die korrekte Analyse ist. Es bezieht sich natürlich auch direkt auf das Thema dieser speziellen (unvollendeten) Antwort und ihrer Kommentare. Es kann jemandem von Nutzen sein.

Sobald ich Zeit habe, bearbeite ich Links zu den Whitepapers usw., die darauf eingehen, und die genauen Zählerpfade \ Namen. Natürlich ist auch alles googleable.

Ich würde vorschlagen, WSRM (Windows System Resource Manager) zu implementieren. Wenn es eine Menge Apps, Verbindungen und Dienste gibt, die auf einem Host ausgeführt werden, weiß das System nicht, dass alle gut zusammenspielen müssen. Windows Server versucht natürlich, alle Ressourcen zu nutzen, um die gesamte Zeit über alles fertig zu stellen, es sei denn, es wird darauf hingewiesen ... Geben Sie WSRM ein.

Durch die Implementierung von WSRM können Sie Ressourcenbeschränkungen für alle Arten von Variationen festlegen, um sicherzustellen, dass für alle aktiven und verbundenen Benutzer die gleichen Bedingungen gelten. Aus Ihren Notizen geht hervor, dass es sich nicht um ein ESX / vSphere-Problem handelt, sondern vielmehr um zu viele verbundene Benutzer, die ständig um alles kämpfen. Sie müssen WSRM testen, um ein Medium zu finden, mit dem Sie die Ressourcen ausbalancieren können, das sich jedoch nicht auf das Leistungsniveau auswirkt, an das sich alle gewöhnt haben.

WSRM-Übersicht: http://technet.microsoft.com/en-us/library/cc732553.aspx