Discussion :

[juliendebaty]

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

[julien94320]

Question bete :

Comment est configurer votre allocation de mémoire au niveau de votre instance :



Il faut savoir que si vous avez laisser la valeur par défaut a ce niveau SQL Server est prioritaire sur l'OS et peut prendre toute la RAM disponible sur la machine ce qui peut geler la machine ...

Il faut impérativement modifier cette valeur.

Pour 20 Go de mémoire dispo sur l'os je metterai 12 Go pour l'instance SQL et 8 restant pour l'OS et le reste ...

Julien

[juliendebaty]

Bonjour,

Merci pr votre réponse !

C'est une VM, voici donc les deux paramétrages RAM de la VM et du SQL server en lui meme.

Je pense que la paramétrage est bon, mais peut etre que la quantité de RAM allouée est juste... un avis là dessus ?

[julien94320]

Bonjour,

Non votre paramétrage est faux !

Vous ne laissez pas de marge a votre OS pour qu'il puisse "vivre".

Il faut savoir que SQL Server est prioritaire sur votre OS.

Petit Probleme :

Dans votre cas vous avez autorisé SQL Server à allouer 20 Go sur votre instance et vous avez 20 Go dédier a votre OS .

Si SQL Server Demande 20Go combien reste-il a votre OS ?


Reponse :

Rien !

Explication : SQL Server va s'accaparer des 20 Go dispo (il est prioritaire sur l'OS), votre OS va demandé a SQL Server de lui rendre de la mémoire, mais en attendant que SQL Server rende de la mémoire la machine risque d'etre gelé ( et ça peut etre long car SQL Server va essayer de terminer son traitement avant ) ...

Dans votre cas la bonne configuration est :

16 Go (80 %) alloué a l'instance SQL Server et 4 Go (20 %) restant pour l'OS ( il a besoin de vivre lui aussi !) => ce que je vous avais dit dans mon précédent post ( j'avais même été plus loins en laissant 8 Go a l'OS car avec les OS 64 bits 4 go c'est un peu juste ... )

[juliendebaty]

Effectivement, je comprends mieux ce que vous me dites mnt.

je pensais que MS Server 2012 gerait de manière auto le % de memoire pr la VM en elle meme et pr le SQL serveur....

Pensez vous que cela uniquement pourrait provoquer les erreurs et lenteurs du SQL ?

Je vais modifier après l'arrivée de la memoire RAM que nous venons de commander, je crains que 12G de RAM pr le SQL soit beaucoup trop leger

[julien94320]

Pensez vous que cela uniquement pourrait provoquer les erreurs et lenteurs du SQL ?

Oui c'est une piste possible (Si l'os ou SQL n'a plus de mémoire il swap, vérifiez donc avec le perfmon ...)

Autre piste interessante la virtualisation ( Il est préférable de ne pas virtualiser SQL Server ) :

http://blog.developpez.com/sqlpro/p8...virtualisation

Autre point l'utilisation et le paramétrage de vos disques : Quel conf ? SAN ? quel type de RAID ( 0,1,5 ? ) ...

Si vous avez envie d'améliorer vos compétences SQL une bonne suggestion :

http://www.eyrolles.com/Informatique...-9782212135923