[WS 2008 R2] Blocage temporaire à l'ouverture/fermeture session TSE [Résolu]

[shkyo]

Bonjour, voici un problème assez pénible sur lequel je me casse les dents depuis quelques temps...

J'ai un serveur 2008R2 virtuel (sous Hyper-V) suffisamment musclé (4Go de ram, processeur Xeon 2.8GHz) qui a le rôle "Service bureau à distance" installé.

La-dessus viennent se connecter une vingtaine de clients (maxi) en session TSE, et à chaque connexion (ou deconnexion) d'un client cela fige tous le monde pendant 5 à 15s !!! Ce qui est à l'usage, assez chiant...

Ce serveur ne fait rien d'autre, pour info je l'ai passé en SP1 au cas où, mais cela n'a rien changé...
Les clients se connectent à partir de poste en WinXP SP3 et quelques Win7Pro, mais ils ont tous la dernière version du client RDP (la 7.0).

Voilà, quelqu'un a-t-il une idée sur ce problème? Merci d'avance!!!

[sevyc64]

J'ai un serveur 2008R2 virtuel (sous Hyper-V) suffisamment musclé (4Go de ram, processeur Xeon 2.8GHz) qui a le rôle "Service bureau à distance" installé.

Suffisament musclé, non!
WS2008R2, donc 64bits. Déjà, 4Go de ram, c'est la limite basse pour un système 64bits

En plus un serveur et qui-plus-est, un serveur TSE avec une vingtaine d'utilisateurs, il doit swapper sur le disque comme un malade ton serveur. Tu devrais envisager de sérieusement augmenter la mémoire. Avec 16Go voire 24, tu serais déjà un peu plus à l'aise.

[shkyo]

Envoyé par sevyc64

Suffisament musclé, non!
WS2008R2, donc 64bits. Déjà, 4Go de ram, c'est la limite basse pour un système 64bits

En plus un serveur et qui-plus-est, un serveur TSE avec une vingtaine d'utilisateurs, il doit swapper sur le disque comme un malade ton serveur. Tu devrais envisager de sérieusement augmenter la mémoire. Avec 16Go voire 24, tu serais déjà un peu plus à l'aise.

Ah? Mais le moniteur de ressources ne dépasse pas les 3Go de ram à pleine charge! Je rappelle qu'il ne fait que ça, rien d'autre.
Le serveur virtuel qui héberge les 2 bases SQL a lui 10Go de ram.
Sachant qu'avant, il avait 7Go de ram et qu'on l'a réduit pour mettre un 4ème serveur virtuel sur la bécane, et le problème était le même... (oui je traine ce boulet depuis quelques temps!).

Pour infos, la bécane physique est un bi-xéon à 6 coeurs chacun avec 24Go de ram et 1.6To de HD en RAID5, il n'a que 6 mois...

[sevyc64]

Il suffit de faire le compte.

Sur les 4Go, si tu enlève la part que le système a besoin, je ne sais pas combien c'est, mais pour du 64bits, ça doit au moins 1Go, il reste 3Go.
3Go à partager entre 20 utilisateurs, ça fait en gros 150Mo par utilisateurs. Certes la gestion de la mémoire est optimisée, les applications, par exemple, ne sont pas forcément chargée en un exemplaire par utilisateur, mais 150Mo, ça fait quand même pas énorme.

JE ne sais pas exactement comment se calcule la quantité de mémoire pour un serveur TSE, mais en comptant, ne serait-ce qu'une fenêtre de 512Mo par utilisateur, pour 20 utilisateurs ça te fait déjà 10Go.

Si un expert passe par là, il pourra en dire plus.

[shkyo]

Ben là en ce moment par exemple, j'ai 15 users en session TSE, et j'ai la mémoire à 1.6Go, ça me laisse de la marge jusqu'à 4Go.

Je vais préciser un peu plus les configs... donc c'est du tout Microsoft, on est en domaine et le serveur qui gère l'AD, le DNS, Exchange 2003 et les sauvegardes est un serveur physique (Xéon quad-core 3.2GHz, 4Go ram et 200Go de HD en RAID5) sous 2003R2 en SP2.

Ensuite, on a un big serveur en bi-xéon 6 cores chacun à 2.8GHz, 24Go ram et 1.6To de HD en RAID5, sur lequel tourne un 2008R2 x64 version Core. C'est lui qui héberge les 3 serveurs virtuels effectifs.
- Un qui a 4Go de ram et qui gère l'anti-virus serveur, les licences TSE, et c'est tout (2008R2 x64 Entreprise).
- Un qui a 10Go de ram et qui héberge un MS SQL 2008 et les fichiers partagés des users (2008R2 x64 Entrerise).
- Un dernier qui a 4Go de ram et qui sert juste de serveur TSE et rien d'autre (2008R2 x64 Entreprise SP1).

C'est donc sur le serveur TSE que ça déconne! Pour info, on utilise le nouveau système de gestion des imprimantes "easyprint" qui évite d'installer pleins de pilotes sur le serveur.

Quand à l'eventviewer, rien de spécial à signaler, quelques erreurs de redirection d'imprimantes, mais peu.

[truncate]

Un serveur TSE est un serveur applicatif avant tout.
A moins que le programme tourne exclusivement en Store Procedure, il ne faut jamais sous estimer celui ci tant au niveau memoire, qu'au niveau processeur...

4 Go en 2008 et RDS..... pas d'experience la dessus... en standard on ne descend pas en dessous de 6 Go.

MAIS... La sous dimenssion du serveur n'explique pas qu'il se fige 15 a 30 sec !

Je pencherais plutot sur un probleme de communication entre le serveur TSE et le serveur SQL qui heberge (je suppose) les profils itinerants des utilisateurs (ou redirection "Mes Docs", "Applic data",...)

(Je ne connais pas Hyper-V en pratique mais ce "post" me rassure sur ma retissence a l'utilisé... mais ca ! c'est purement subjectif
Sous VMWare Server 2.0 avec un hote en windows 2003, on avait ce genre de probleme et cela a disparu avec VMWare ESXi (disponible en gratuit).
Ce qui me fait dire que les hotes Microsoft laisse a desirer au niveau de la gestion des ressources, meme si le principe n'est pas le meme que hyper-V.)

[shkyo]

Win2008R2 avec un seul rôle n'est pas aussi lourd que ça, je regardais encore ce matin, avec 15 users connectés dans leur session TSE, j'avais la charge de ram à seulement 1.6Go... sur 4Go, il y a encore de la marge!

Par contre, dernière nouvelles après d'autres tests, il semblerait que le montage des imprimantes y soit pour quelque-chose...
Car au niveau du client TSE, suivant qu'on demande de monter les imprimantes du client ou non, le freeze de connection est quasi-inexistant ou présent!
A creuser, donc...

[shkyo]

Maintenant, c'est certain que le soucis vient des imprimantes, au niveau du client TSE, quand on décoche l'option de montage des imprimantes, la connexion est quasi instantanée!! Et quand c'est coché... de 5 à 15s de freeze... La différence de temps de freeze venant certainement du nombre d'imprimantes qui sont installées sur le poste du client.

Malgré tout, on a trouvé un palliatif : c'est d'augmenter la puissance dispo pour la machine virtuelle, pour l'instant elle n'avait qu'un processeur affecté dans HyperV, mais en la montant à 4 processeurs (le maxi donc) ça devrait mieux passer et limiter le temps de freeze. On a fait des tests sur notre serveur de test en le passant à 2 processeurs virtuels et déjà ça respirait un peu mieux!