it-swarm.com.de

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 gestiegen (~ 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 über den Rahmen dieser Frage hinausgeht.

An bestimmten Punkten 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. Überprüfen Sie, ob Sie mit dem Netzwerk verbunden sind und ob Ihr Netzwerk ordnungsgemäß funktioniert.

DETAIL - Es sind nicht genügend Systemressourcen vorhanden, um den angeforderten Dienst abzuschließen.

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 Tuning oder eine Konfiguration auf Betriebssystemebene, die dabei helfen kann?
  • Benutzer sind mit der Leistung zufrieden, mit Ausnahme der erhöhten Häufigkeit dieser Fehlermeldung. Ist hier noch etwas im Spiel?
  • Gibt es eine absolute Begrenzung für die Anzahl der Benutzer, die ein Terminalserver aufnehmen kann? Ich sehe mehr als 150 Benutzer, die in bestimmten Optimierungshandbüchern für Terminalserver beschrieben sind.

(enter image description here

(enter image description here

21
ewwhite

Dies wurde gelöst.

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 zu schätzen. Beim Surfen über regedit sind Probleme beim Öffnen der Schlüssel unter HKEY_USERS\.Default\PRINTERS Angefallen. Mit dureg begann ich unter dieser Hierarchie zu suchen.


Drucker waren das Problem. Die Ursache und Lösung sind detailliert beschrieben in:
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 zurückzugewinnen.

Komprimierte aufgeblähte Registrierung: 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 ... etwas schwierig, während der Produktionsstunden aus der Ferne zu arbeiten. Ich habe versucht, meinen ansässigen Microsoft-Experten zu erreichen, um den Vorgang abzuschließen, aber er war damit beschäftigt, ein SCCM oder SCVMM-Problem irgendwo zu verfolgen . Beim Lesen einiger Citrix-bezogener Foren habe ich ein Tool zur Kenntnis genommen, mit dem die oben genannten Schritte mit weniger Schritten ausgeführt werden können ...

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

Beachten Sie die 1,4 GB, die in der Standardkonfiguration gespeichert sind ...tucows

BITTE REBOOTEN !

Nach einem Neustart war alles in Ordnung. Die Benutzerzahl erreichte 86 ohne negative Auswirkungen und ohne profilbezogene Fehler. Ich habe die Druckerregistrierung Hive überwacht und sie wird stabil gehalten.

16
ewwhite

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 würde wetten, 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. Darüber hinaus liegt die Anzahl der Proccesen bei fast 800, was ziemlich hoch ist. MS würde Ihnen wahrscheinlich sagen, dass Sie die Anzahl der Prozesse reduzieren sollen, was nur durch Reduzierung der Benutzerlast möglich ist.

Dieser Artikel enthält einige gute Informationen zur Speichernutzung in Windows und dazu, wie Sie das Limit für nicht ausgelagerten Pool anzeigen können, um festzustellen, ob dies die Ursache des Problems ist:

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

3
joeqwerty

Starten Sie Windows Performance Monitor, um die verschiedenen Leistungsindikatoren zu überwachen:

  • Kontextwechsel
  • Seitentabelleneinträge
  • GDI-Elemente
  • Griffe
  • … (Was auch immer Sie finden können)

Und prüfen Sie, ob einer dieser Peaks bei einem fehlgeschlagenen Login auftritt.

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


Der Dienst ser Profile Hive Cleanup kann hier hilfreich sein, da er "dazu beiträgt, dass Benutzersitzungen vollständig beendet werden, wenn sich ein Benutzer abmeldet".

2
MikeyB

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 Sie verwenden. Insbesondere stelle ich fest, dass Sie 80 Benutzer auf 4 vCPUS haben, und MS empfiehlt 1 Kern 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. Z.B. Wenn Sie 4 GB RAM) haben, sollte für eine optimale Leistung eine Dual-Core-CPU vorhanden sein.
  • 2 Dual-Core-CPUs bieten eine bessere Leistung als Single-Quad-Core-Prozessoren.
  • Empfohlene Bandbreite für LAN von 30 Benutzern und WAN von 20 Benutzern. Bandbreite (b) = 100 Megabit 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 Betriebssystem, z. (100 Benutzer * 64) + 2000 = 8,4 GB, d. H. 8 GB RAM.
  • Für mehr verwendete Anwendungen (d. H. Office, CAD Apps usw.)) muss mehr Speicher pro Benutzer zu dieser Berechnung hinzugefügt werden als über den 64-MB-Basisspeicher pro Benutzer.
  • 15 TS-Sitzungen pro CPU-Kern sind die optimale Leistungsgrenze eines Terminalservers.
  • Das Netzwerk sollte nicht mehr als 5 Hops haben und die Latenz sollte unter 100 ms liegen.
  • 64 kbps ist die ideale Bandbreite pro Benutzersitzung. (256 Farben, Switched Network, nur Bitmap-Caching)
  • Die CPU-Leistung verschlechtert sich, wenn die prozentuale Prozessorzeit pro Kern konstant über 65% liegt.
  • Die Leistung von Terminalservern verdoppelt sich, wenn sie unter X64 HW und OS ausgeführt werden.

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

Hier herunterladen

1
HopelessN00b

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

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

Das Maximieren des Perfmon-Zählers war nicht selten eine Kontextumschaltung, sondern führte zu einem Ausfall eines Servers, während andere Zähler wie RAM, CPU usw. gut aussahen. Möglicherweise könnte dies ein Grund sein (der Server kann aufgrund einer übermäßigen Kontextumschaltung keine Ressourcen vor dem Timeout zuweisen). Hier sind zwei Möglichkeiten zum Überwachen der Kontextumschaltung :

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.

Vielleicht finden Sie auch etwas Nützliches im Handbuch zur Kapazitätsplanung. Einen Link dazu finden Sie in dieser Blog-Beitrag .

Wenn ich die Zeit für diese Antwort ermitteln 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 sie zeitbasiert Perfmon-Zähler (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 alle nativen zeitbasierten CPU-Zähler innerhalb der VM mit ihrem Gegenstück auf dem vSphere-Host für diese VM. Aus diesem Grund veröffentlicht VMware einige Zähler für die CPU (und den ebenfalls ungenauen Speicher) aus der Gastperspektive) über VMware-Tools in zwei VMguest-Perfmon-Objekte.

Somit werden die korrekten zeitbasierten Werte innerhalb des Gast-Perfmon verfügbar gemacht, jedoch 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 eine korrekte Analyse ist. Es bezieht sich natürlich auch direkt auf das Thema dieser bestimmten (unvollendeten) Antwort und ihre Kommentare. Es kann für jemanden von Nutzen sein.

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

1
ErikE

Ich würde vorschlagen, WSRM (Windows System Resource Manager) zu implementieren. Wenn auf einem Host eine Menge Apps, Verbindungen und Dienste ausgeführt werden, weiß das System nicht, dass jeder Nizza zusammen spielen muss. Windows Server versucht natürlich, alle Ressourcen zu nutzen, um alles jederzeit abzuschließen, es sei denn, es wird darauf hingewiesen ... Geben Sie WSRM ein.

Durch die Implementierung von WSRM können Sie Ressourcenlimits für alle Arten von Variationen festlegen, um sicherzustellen, dass für alle laufenden oder verbundenen Benutzer gleiche Wettbewerbsbedingungen bestehen. Aus Ihren Notizen geht hervor, dass es sich nicht um ein ESX/vSphere-Problem handelt, sondern um zu viele verbundene Benutzer, die ständig um alles konkurrieren. Sie müssen WSRM testen, um ein zufriedenstellendes Medium zu finden, mit dem Ressourcen zwischen allem ausgeglichen werden können, ohne jedoch das Leistungsniveau zu beeinträchtigen, an das sich alle gewöhnt haben.

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

0
MethoteK