2008 R2 Terminal Server: «Les ressources système sont insuffisantes pour terminer le service demandé»

Je travaille avec un serveur Terminal Server Windows 2008 R2 malsain configuré dans un environnement vSphere. Il dispose actuellement de 4 processeurs virtuels et de 32 Go de RAM. Aucun engagement excessif.

Le nombre d'utilisateurs simultanés sur ce serveur a fortement augmenté ces derniers mois (~ 70) et est probablement supérieur au niveau recommandé. En raison des applications utilisées par les utilisateurs sur ce système, le fractionnement en plusieurs serveurs sera un défi au-delà de la portée de cette question.

Toutefois, à certains moments de la semaine (et maintenant, presque quotidiennement), les nouvelles ouvertures de session des utilisateurs génèrent les erreurs suivantes: ID d'événement 1500

Windows ne peut pas vous connecter car votre profil ne peut pas être chargé. Vérifiez que vous êtes connecté au réseau et que votre réseau fonctionne correctement.

DÉTAIL - Les ressources système sont insuffisantes pour terminer le service demandé.

Cela reste jusqu'à ce que certains utilisateurs se déconnectent, que les sessions soient manuellement déconnectées ou que le système soit complètement redémarré.

J'aimerais savoir:

• À quelle (s) ressource (s) ce message d'erreur fait-il référence? Qu'est-ce qui est réellement contraint?
• Existe-t-il un réglage ou une configuration au niveau du système d'exploitation qui peut vous aider?
• Les utilisateurs sont satisfaits des performances, à l'exception de la fréquence accrue de ce message d'erreur. Y a-t-il autre chose en jeu ici?
• Y a-t-il une limite absolue au nombre d'utilisateurs qu'un serveur Terminal Server peut accueillir? Je vois plus de 150 utilisateurs décrits dans certains guides de réglage pour les serveurs Terminal Server.

Cela a été résolu.

J'ai commencé à examiner le registre car l'augmentation des ressources CPU et RAM sur la machine virtuelle n'a pas résolu le problème.

J'ai été pointé sur l' outil dureg de Microsoft pour estimer la taille du registre. En naviguant via regedit, j'ai rencontré des problèmes d'ouverture des clés sous HKEY_USERS\.Default\PRINTERS. En utilisant dureg, j'ai commencé à sonder sous cette hiérarchie.

Les imprimantes étaient le problème. La cause et le correctif sont détaillés dans:
La taille de la ruche de registre "HKEY_USERS.DEFAULT" augmente continuellement sur un serveur Windows Server 2008 R2 SP1

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

Cela arrête apparemment la croissance, mais les clés et le registre doivent être compressés pour récupérer de l'espace.

Compression du registre gonflé: 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, quelques étapes ... un peu délicates à faire à distance pendant les heures de production. J'ai essayé de contacter mon expert Microsoft résident pour terminer, mais il était occupé à traquer un problème SCCM ou SCVMM quelque part . En lisant certains forums liés à Citrix, j'ai pris note d'un outil qui pourrait effectuer ce qui précède en moins d'étapes ...

J'ai donc pris un instantané de la machine virtuelle, puis téléchargé et exécuté un logiciel de compression de registre gratuit (Tweaking.com) ; malgré le son écrasant des grognements collectifs des ingénieurs systèmes de Microsoft partout ...

notez les 1,4 Go enregistrés dans la configuration par défaut ...

S'IL VOUS PLAÎT REDÉMARREZ!

Après un redémarrage, tout allait bien. Le nombre d'utilisateurs a atteint 86 sans aucun effet indésirable et aucune erreur liée au profil. J'ai surveillé la ruche du registre de l'imprimante et elle est restée stable.

Dans Windows Server 2003, cette erreur était due à l'épuisement de la mémoire du noyau. Parce que vous avez affaire à Windows Server 2008 R2, je ne sais pas à quel point la cause du problème est étroitement liée à la cause dans W2K3, mais je parierais que c'est un problème de mémoire en raison du nombre d'utilisateurs et de processus. Je voudrais jeter un œil à l'épuisement de la mémoire du pool non paginé comme cause probable. De plus, le nombre de procès est proche de 800, ce qui est assez élevé. MS vous dirait probablement de réduire le nombre de processus, ce qui ne peut être fait qu'en réduisant la charge utilisateur.

Cet article contient de bonnes informations concernant l'utilisation de la mémoire dans Windows et comment vous pouvez afficher la limite du pool non paginé pour voir si c'est la cause du problème:

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

Démarrez l'Analyseur de performances Windows pour surveiller les différents compteurs:

• Commutateurs de contexte
• Entrées de table de page
• Éléments GDI
• Poignées
• … (Tout ce que vous pouvez trouver)

Et voyez si l'un de ces pics lorsque vous obtenez une connexion a échoué.

Aussi: quelque chose cause un% CPU élevé du noyau sur votre système - vous devriez vérifier cela pour voir si cela vous mène à un problème connexe.

Le service de nettoyage de la ruche de profil utilisateur peut aider ici car il "aide à garantir que les sessions utilisateur sont complètement terminées lorsqu'un utilisateur se déconnecte".

Eh bien, d'après ce que j'ai lu sur la planification de la capacité RDS dans Server 2008 R2, vous pourriez simplement exécuter votre pauvre serveur Terminal Server sur des ressources insuffisantes pour le nombre d'utilisateurs que vous l'utilisez. En particulier, je remarque que vous avez 80 utilisateurs sur 4 vCPUS, et MS recommande 1 cœur pour 15 utilisateurs.

Du blog technet intitulé 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 Go de mémoire (RAM) est la limite optimale pour chaque cœur d'un CPU. Par exemple, si vous avez 4 Go de RAM, pour des performances optimales, il devrait y avoir un processeur double cœur.
• 2 CPU Dual Core fonctionnent mieux que le processeur Quad Core simple.
• Bande passante recommandée pour LAN de 30 utilisateurs et WAN de 20 utilisateurs. Bande passante (b) = 100 mégabits par seconde (Mbps) avec Latence (l) Moins de 5 millisecondes.
• Sur un serveur Terminal Server, 64 Mo par utilisateur sont la mémoire idéale (RAM) requise pour GP. Utilisez uniquement + 2 Go pour le système d'exploitation, par exemple (100 utilisateurs * 64) + 2000 = 8,4 Go, soit 8 Go de RAM.
• Plus d'applications utilisées (c.-à-d. Office, applications CAO, etc.) nécessiteront plus de mémoire par utilisateur pour être ajoutées à ce calcul sur la mémoire de base de 64 Mo par utilisateur.
• 15 session TS par cœur de processeur est la limite de performances optimale d'un serveur Terminal Server.
• Le réseau ne doit pas avoir plus de 5 sauts et la latence doit être inférieure à 100 ms.
• 64 kbps est la bande passante idéale par session utilisateur. (256 couleurs, réseau commuté, mise en cache bitmap uniquement)
• Les performances du processeur se dégradent si le% de temps processeur par cœur est constamment supérieur à 65%.
• Les performances des serveurs Terminal Server doublent lorsqu'il s'exécute sur un HW et un système d'exploitation X64.

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

Télécharger les ici

J'ai très peu de temps donc je vais juste faire une réponse sommaire et j'espère l'étoffer plus tard.

Lorsque je faisais des sorts dans les équipes Citrix, je me souviens que nous avions essayé de passer à 15-20 utilisateurs par serveur, mais ceux-ci avaient des applications lourdes en cours d'exécution. Ces jours-ci de x64, nous chargeons plus d'utilisateurs, mais 70+ semble beaucoup.

Le compteur de perfmon maximisant n'était pas rarement un changement de contexte, il étage un serveur tandis que d'autres compteurs comme la RAM, le CPU, etc. semblaient bons. Cela pourrait être une raison (le serveur ne peut pas allouer de ressources avant l'expiration du délai en raison d'un changement de contexte excessif). Voici deux façons de surveiller la commutation de contexte :

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.

Vous pouvez également trouver quelque chose d'utile dans le guide de planification des capacités, vous trouverez un lien vers celui-ci dans cet article de blog .

Lorsque je peux tirer du temps sur cette réponse, je le ferai, je vais simplement ajouter ici une mise en garde sur toutes les mesures basées sur le temps dans une machine virtuelle vSphere.

En raison de la façon dont le vCPU a été extrait des CPU physiques, le vCPU n'a aucune idée de l'heure qu'il est (une seconde virtuelle peut être plus ou moins d'une seconde réelle (ou au moins physique). Par conséquent, basée sur tout le temps les compteurs perfmon (temps CPU, changements de contexte / s et ainsi de suite) sont inexacts (parfois même de manière extravagante), même s'ils peuvent servir d'indicateurs à grain très grossier.

Pour vérifier cela, comparez tout compteur de CPU natif basé sur le temps au sein de la machine virtuelle avec son homologue sur l'hôte vSphere pour cette machine virtuelle. Pour cette raison, VMware publie certains compteurs pour le CPU (et la mémoire qui est également inexacte du point de vue des invités) via les outils VMware dans deux objets perfmon VMguest.

Ainsi, les valeurs temporelles correctes sont rendues disponibles à partir du perfmon invité, mais uniquement si l'on regarde les compteurs d'objets publiés par VMware.

Je pensais juste que ces informations de base étaient un peu pertinentes car les réponses jusqu'à présent se concentrent sur les mesures basées sur le temps à partir d'une machine virtuelle vSphere, où cela est dans certains cas une circonstance cruciale pour une analyse correcte. Elle se rapporte également, bien entendu, directement au thème de cette réponse (inachevée) particulière et à ses commentaires. Cela peut être utile à quelqu'un.

Dès que j'aurai le temps, je modifierai les liens vers les livres blancs, etc. qui expliquent cela, et les chemins de compteur exacts \ noms. Naturellement, tout est également googleable.

Je suggère d'implémenter WSRM (Windows System Resource Manager). Lorsqu'il y a une tonne d'applications, de connexions et de services exécutés sur un hôte, le système ne sait pas que tout le monde doit jouer bien ensemble. Windows Server essaie naturellement d'utiliser toutes ses ressources pour tout terminer tout le temps à moins qu'il en soit informé ... entrez WSRM.

En implémentant WSRM, vous pouvez définir des limites de ressources par toutes sortes de variations pour vous assurer qu'il existe un terrain de jeu égal pour tout ce qui fonctionne ou les utilisateurs connectés. D'après vos notes, cela ne semble pas être un problème ESX / vSphere mais plutôt trop d'utilisateurs connectés qui sont constamment en concurrence pour tout. Vous devrez tester WSRM pour trouver un juste milieu d'équilibrage des ressources entre tout, mais sans affecter les niveaux de performance auxquels tout le monde s'est habitué.

Présentation de WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx