Bonjour à tous,

Après moultes recherches, temps passé sur des forums et sites, je décide de venir ici présenter ma problématique en esperant avoir des idées lumineuses de votre part ^^

Voici la config:

HP Proliant DL380P Gen8 bi Xeon E52650
96G RDDR3 1866Mhz
1 RAID SSD HP mainstream
1 RAID SAS 15K HP

Les deux disques sont OK niveau place.

Microsoft server 2012 R2, HyperV installé dessus et celui ci comporte trois VM
1. AD
2. SQL 2012
3. TS

Il y a en tout 70 connexions Remote App sur le TS
Ce sont des magasins de distribution, bcp d'écriture SQL, pas mal de requetes sur ventes d'un article sur des periodes données, chiffre d'affaire par heure etc etc, mais évidemment pas tous au meme moment.

La RAM est allouée de la manière suivante:

1. AD : 4G de RAM
2. SQL 2012: 20G de RAM
3. TS: 50G de RAM

La RAM est en loadbalancing entre les deux Nodes, 48G pr chaque processeur.

L'AD est sur le Node 0 et toute sa ram aussi
Le SQL est sur le Node 0 et toute sa ram également
Le TS est sur le Node 0 et 1 et sa ram balancée entre les deux Nodes.

Nous rencontrons depuis qq semaines des ralentissements temporaires sur les sessions remote app des points de vente, avec principalement des messages d'erreur d'inscription SQL.
Nous avons déjà analysé à plusieurs reprises l'activité sur le sql et ts lors de ces ralentissements et nous ne trouvons rien de très probant...

Le SQL est tout le temps à 85% de charge mémoire.
Le TS est en général à 55-60% de charge. Par moments, pr des raisons assez inconnues, la charge memoire de certaines sessions RemoteApp augmente de manière sensible, du genre 4X la ram habituelle....

Il arrive, comme tt à l'heure, que le SQL monte à 93-94% de charge memoire et j'ai le sentiment qu'il commence à écrire sur le disque par manque de RAM... ce qui provoquerait les ralentissements, sans savoir l'origine de la montée en charge de 85 à 93-94%...

Aussi, ces augmentations subites de charge memoire de certaines sessions remoteapp n'ont pas encore été elucidées...

1. avez vous des préoconisations sur le bon paramétrage et la bonne quantité de RAM pr un serveur SQL comme le notre ?
2. Idem pr un serveur TS avec 70 connexions simultanées
3. Nous n'arrivons plus à allouer de ram supplémentaire sur le SQL malgré que nous ayons encore 16G de ram libre... une idée ? le SQL prend en otage la memoire restante ?

Info qui a son importance et que j'ai oubliée: le SQL possède trois DB principales en fonctionnement.
une de 98 gigas, une de 95 gigas et une de 10 gigas. Les sessions sur la DB de 10 gigas fonctionnent bien sur impeccablement, ils sont trois à se connecter dessus.

Si vous avez besoin d'autres infos, je suis avec attention vos réponses

Merci d'avance pr votre aide

Julien