Discussion :

[AlternantOracle]

Bonjour à tous,

Je viens vers vous car je ne sais plus ou donner de la tête concernant les "best practices" d'allocation mémoire SQL server.
Je cherche en effet une formule basique magic qui n'existe pas pour configurer le max et min memory SQL server d'une instance en fonction de la ram disponible sur le serveur.

Je précise que ce serveur hébergera seulement SQL Server et à part l'anti-virus et le logiciel pour sauvegarder les backups sur bande rien n'est installé.
Je précise aussi que je suis en LPIM avec mes comptes de service.

Ici, plusieurs écoles s'affrontent. J'ai du lire une bonne vingtaine d'articles et tous n'utilisent pas la même formule.

En effet, le plus optimisé serait de faire des perfmon durant une journée de production et voir ainsi combien est nécessaire à SQL server.

Seulement comme vous le savez déja il faut toujours aller très vite pour des causes diversses liées aux contraintes de production.

Je me voi mal demander à qqun qui instal plusieurs instances par jour de faire ce genre de tests, surtout si il n'es pas DBA.

Voici 2 exemples ...
http://www.sqlservercentral.com/blog...005_2F00_2008/
http://www.red-gate.com/community/books/accidental-dba ->chapitre 4

Pour 64Go quand l'un laisse 5,5 Go pour l'OS, l'autre laisse 10 Go ... Pareil concernant le min memory on peut lire tout et n'importe quoi sur le net.

Bref je sais plus ou donner de la tête :s

[bvesan]

Bonjour,
S'il existe de nombreux conseils concernant l'allocation de la mémoire à SQL Server, c'est que la formule magique n'existe pas !
Personnellement, voici, à défaut de formule magique, une méthode que j'essaye d'appliquer:
Le but est bien entendu triple:
Eviter que la mémoire allouée à SQL Server n'arrive dans le PageFile, éviter que Windows (ou une application concurrente) ne subisse le même sort, et bien entendu profiter au maximum de la mémoire pour améliorer les performances sur l'instance.

• La machine est elle dédiée à une instance SQL Server ? Si ça n'est pas le cas (et cela inclue une instance SSIS ou SSAS), il faut connaître (lorsque cela est possible) le maximum de mémoire consommé par ces applications.
• La machine va-t-elle être utilisée en tant que serveur de fichiers ? Le cache de NTFS, qui peut correspondre à une large portion de mémoire (plusieurs Go) lorsque de gros fichiers sont transférés (c'est par exemple lors de la copie de gros fichiers de sauvegarde de bases vers un répertoire partagé...), risque d'entrer en concurrence avec l'instance SQL Server dans ce cas.
• L'instance SQL Server va-t-elle piocher dans la mémoire virtuelle (mémoire physique + Pagefile) ou uniquement dans la mémoire physique ? Lorsque vous utilisez AWE ou que le compte de service dispose du privilège "Lock Pages in Memory", seule la mémoire physique est allouable à SQL Server. Saturer la mémoire virtuelle est bien entendu moins critique que saturer la mémoire physique.

Lorsque vous connaissez la réponse à ces questions, vous avez une bonne idée de ce qui peut entrer en concurrence pour la mémoire.
J'ai tendance à laisser entre 1 et 2Go pour Windows, et le reste de la mémoire pour toutes les applications...

Concernant le Min Memory, toujours à titre personnel, je systématise Min Server Memory = Max Server Memory. Principalement pour éviter une brusque vidange de la mémoire allouée à SQL Server en cas de pression mémoire sur la machine (Windows peut inviter SQL Server à réduire sa mémoire allouée jusqu'à Min Server Memory, avec des conséquences désastreuses sur les performances).

[SQLpro]

Le min memory n'a en pratique aucune importance.
Le max mémory est essentiel.
Si votre serveur est dédié, vous pouvez consacrer toutes la RAM, sauf un strict minimum pour l'OS à SQL Server.
Grosso modo si :
RAM < 16 Go => mettez RAM -2 à SQL Server.
RAM > 16 et < 32 => mettez RAM - 3 à SQL Servr
RAM > 32 et < 64 => mettez RAM - 4 à SQL Server
RAM > 64 et < 128 => mettez RAM - 5 à SQL Server
au delà, mettez RAM - 6 Go

Par contre :
1) un antivirus sur un serveur SQL c'est de la connerie pure. Vous allez da$dégrader les performances de façon catastrophiques. Un SGBDR est rarement sensible aux virus et SQL Server pas du tout...
2) un outil pour sauvegarde sur bande est stupide. SQL Server par la commande backup permet de sauvegarder les bases directement sur bande ! Et sauvegarder tous les serveurs ne servira à rien a) vous ne pourrez pas restaurer le serveurs Windows avec cela b) aucune base ne sera sauvegardé par cette méthode !

A +

[mikedavem]

Lorsque j'interviens en clientèle j'applique à peu près les mêmes règles que Benjamin. L'idée étant de s'assurer que SQL Server ne vampirise pas l'ensemble de la mémoire vu par le système d'exploitation il est quand même bon de configurer au moins le max server memory. Globalement je laisse entre 2 Go, 4 Go ou 8 Go en fonction de la mémoire disponible sur le serveur et des applications externes qui pourraient cohabiter avec SQL Server.

Pour le min memory tout dépend les environnements mais en général je le laisse sa valeur par défaut à moins d'être contraint de le changer suite à une pression mémoire détectée mais ici encore cela dépend du contexte. Par exemple pour un instance virtualisée via VMware qui utilise l'overprovisionning le fait de restreindre la restitution de mémoire peut parfois être plus catastrophique que de laisser l'hyperviseur en récupérer et la donner à une machine qui en a besoin. On peut vite se retrouver dans une situation ou l'hyperviseur va swapper et au final on n'y gagne pas grand chose (bien entendu lorsqu'on arrive à ce genre de situation le problème est bien ailleurs ... je vois venir certains me dire que les clients cherchent à virtualiser )

Mais comme le répète benjamin il n'y a pas de formule magique et c'est la raison pour laquelle on voit beaucoup de choses sur internet qui ne sont pas forcément fausses par ailleurs mais il faut bien souvent les contextualiser et c'est bien là la difficulté selon mon humble avis ...

++

[AlternantOracle]

Concernant le Min Memory, toujours à titre personnel, je systématise Min Server Memory = Max Server Memory. Principalement pour éviter une brusque vidange de la mémoire allouée à SQL Server en cas de pression mémoire sur la machine (Windows peut inviter SQL Server à réduire sa mémoire allouée jusqu'à Min Server Memory, avec des conséquences désastreuses sur les performances).

Hello Benjamin,

Concernant la Min memory, si justement le système à besoin de trim la mémoire ne faudrait-il pas justement lui laisser quelques miettes ?
Par exemple un serveur avec 8 Go -> 2 Go Os + 6 Go SQL avec le min à 5 et le max à 6 ?

[AlternantOracle]

Le min memory n'a en pratique aucune importance.
Le max mémory est essentiel.
Si votre serveur est dédié, vous pouvez consacrer toutes la RAM, sauf un strict minimum pour l'OS à SQL Server.
Grosso modo si :
RAM < 16 Go => mettez RAM -2 à SQL Server.
RAM > 16 et < 32 => mettez RAM - 3 à SQL Servr
RAM > 32 et < 64 => mettez RAM - 4 à SQL Server
RAM > 64 et < 128 => mettez RAM - 5 à SQL Server
au delà, mettez RAM - 6 Go

Par contre :
1) un antivirus sur un serveur SQL c'est de la connerie pure. Vous allez da$dégrader les performances de façon catastrophiques. Un SGBDR est rarement sensible aux virus et SQL Server pas du tout...
2) un outil pour sauvegarde sur bande est stupide. SQL Server par la commande backup permet de sauvegarder les bases directement sur bande ! Et sauvegarder tous les serveurs ne servira à rien a) vous ne pourrez pas restaurer le serveurs Windows avec cela b) aucune base ne sera sauvegardé par cette méthode !

A +

Bonjour Frédéric,

Merci pour tes informations .

Et du coup pour 1 To ? ca me semble peut 6 Go au système :o

1) Concernant l'antivirus les binaires et les fichiers sql en général MDF/LDF sont exclus des scans. Personnelement j'ai déja vu des boites avec des serveurs qui sont vérolés donc je ne penses pas que ce soit une hérésie. Si le client fait n'importe quoi et àccède à ses machines par exemple ...
Quoi qu'il en soit ce n'est pas moi qui défini l'architecture windows et je n'ai donc pas le choix .

2) La sauvegarde sur bande était un terme générique on doit avoir une 15 aine de technologies différentes d'outils qui passent récuperer les backups sql (en fonction du client). Ce n'est pas le sujet

[AlternantOracle]

Lorsque j'interviens en clientèle j'applique à peu près les mêmes règles que Benjamin. L'idée étant de s'assurer que SQL Server ne vampirise pas l'ensemble de la mémoire vu par le système d'exploitation il est quand même bon de configurer au moins le max server memory. Globalement je laisse entre 2 Go, 4 Go ou 8 Go en fonction de la mémoire disponible sur le serveur et des applications externes qui pourraient cohabiter avec SQL Server.

Pour le min memory tout dépend les environnements mais en général je le laisse sa valeur par défaut à moins d'être contraint de le changer suite à une pression mémoire détectée mais ici encore cela dépend du contexte. Par exemple pour un instance virtualisée via VMware qui utilise l'overprovisionning le fait de restreindre la restitution de mémoire peut parfois être plus catastrophique que de laisser l'hyperviseur en récupérer et la donner à une machine qui en a besoin. On peut vite se retrouver dans une situation ou l'hyperviseur va swapper et au final on n'y gagne pas grand chose (bien entendu lorsqu'on arrive à ce genre de situation le problème est bien ailleurs ... je vois venir certains me dire que les clients cherchent à virtualiser )

Mais comme le répète benjamin il n'y a pas de formule magique et c'est la raison pour laquelle on voit beaucoup de choses sur internet qui ne sont pas forcément fausses par ailleurs mais il faut bien souvent les contextualiser et c'est bien là la difficulté selon mon humble avis ...

++

Hello, concernant la partie VMWare on en a justement. Mais j'ai vu avec les mec de la virtualisation, normalement les VM sont bien configuré avec 0 paging et balooning si c'est bien de cela que l'on parle.

[AlternantOracle]

En tous cas merci à tous pour vos réponses qui m'ont bien permis d'avancer.

Je marque passe le post en résolut