[SQL2008] Ratio mémoire vive [VS] taille base

[castorameur]

Bonjour tout le monde

Existe il un tableau, même approximatif, entre
- la taille de la mémoire donnée à SQL
- la taille de la bbd à gérer

Ce tabelau n'étant pas à suivre à la lettre mais permettant d'aller vers de meilleures performances. Je me doute qu'il n'est pas linéaire, mais pourrait il ressembler à cela :

Ram installée/pour SQL/Bdd
4Go/ 2Go / 20 Go
8 Go / 5Go / 50 Go
16 Go / 13 Go / 100 Go
32 Go / 29Go / 500 Go
64 Go / 61 Go / 1 To et +

Si ce tableau n'existe pas, pourrait on mettre en post it, différentes install en cours et construire ce tableau.
Merci de vos retours.

[dbaffaleuf]

Hélas pas de règle. Il faut observer, corriger, observer, corriger, etc... On peut avoir une base de 20Gb et avoir besoin de 90% des données en mémoire sur les 20Gb, et on peut avoir une base de 100Gb et n'utiliser que le mois en cours qui représente 2 Gb de données. Quant à la relation RAM installée / Pour SQL, c'est SQL Server qui décide sauf conditions particulières (64bits, AWE).

[castorameur]

Je donne mon install pour les stats


Serveur :
Win 2008 64 bits en VM Vsphere
24 Go dont 16 Go pour SQL Server
2 services sur le serveur (SQL + ERP)

Base
SQL 2008 64 bits AWE non activé
100 Go (80 Go + 20 Go log) utilisée par un ERP

[dbaffaleuf]

- La machine est-elle dédiée ?
- 64 bits ? 32 bits + AWE ?
- Quelle version / édition de Windows / SQL Server ?
- La sortie de dbcc memorystatus
- La variation de page life expectancy sur 24 heures (min/max/avg) ?
- La valeur de \Memory\Available Mbytes sur 24 heures (min/max/avg) ?

[castorameur]

J'ai mis à jour mon message.

Mais je n'ai pas répondu aux 2 dernières questions : est ce que ce sont des compteurs de perfs? Je ne les connais pas.

Sinon il s'agit plus de réunir des expériences que de parler uniquement de mon cas

[dbaffaleuf]

Envoyé par castorameur

Sinon il s'agit plus de réunir des expériences que de parler uniquement de mon cas

Je vois bien ce que tu voulais obtenir comme réponse, mais il y a rarement des cas universels, sur lesquels on peut faire des généralités. Le besoin guide le choix de la ressource, et il est différent pour chaque environnement.

[mikedavem]

D'accord avec David. Le dimmensionnement des ressources se fait souvent de façon spécifique selon le contexte ... Dans votre cas peut être que 16Go sera suffisant ou peut être pas ... Il faudra comme l'explique David mesurer et corriger en conséquence

++

[castorameur]

Loin de chercher une normalité, le fait de voir des moyennes permet de savoir si on est loin des clous ou pas.

[dbaffaleuf]

Envoyé par castorameur

Loin de chercher une normalité, le fait de voir des moyennes permet de savoir si on est loin des clous ou pas.

Mesurer la consommation permet de voir si on est dans les clous. Après les guidelines sont souvent mal interprétées. Par exemple, on dit qu'il faut toujours que le compteur Page Life Expectancy soit au dessus de 300 secondes. Mais une valeur de page life expectancy de 600 secondes sur un buffer pool de 24 Gb par exemple ne me rassurerait pas beaucoup (une page traverserait 24 Gb de cache en 10 minutes avant d'être éjectée). Il faut regarder les variations plutôt que la valeur brute. Si pendant toute une journée la valeur est à 30000 secondes et que d'un coup elle tombe à 2000 par exemple, là il y a un problème (par exemple un table ou un index scan).

[mikedavem]

Il y a certaines documents qui stipulaient qu'il fallait 20% de la volumétrie totale des bases comme valeur de RAM. Mais cela dépend bien de la nature de la charge appliquée sur le serveur de bases de données. Il se peut que l'on est besoin de moins de RAM comme le contraire.

Je suis plutôt du même avis que David ... il n'y a pas vraiment de valeur ou de règles ... la mesure reste quand même le meilleur moyen de dimensionner ... Un autre facteur à prendre en compte est la volumétrie qui change au cours du temps .. il faudra de toute façon surveiller la quantité de mémoire utilisée et adapter au fur et à mesure

++

[SQLpro]

De même sur le ratio théorique RAM/taille de base, ceci suppose une base de données PARFAITEMENT MODÉLISÉE et parfaitement indexées pour l'usage que l'on en fait.
En effet, un mauvais modèle et une bases sous indexées consomment beaucoup de RAM !!!

A +

[elsuket]

Bonjour,

Donc en supposant que la base de données soit proprement modélisée et indexée, existe-t-il un moyen de connaître la quantité de pages (?) totales lues par une instance SQL Server sur une plage de temps ?

@++

[mikedavem]

Quel est le but derrière cela ?

Je pose la question car avoir un nombre de pages lues sur une période donnée (par exemple une semaine) ne donnerait pas forcéement d'indication sur la quantité de mémoire nécessaire (du moins je ne vois pas pour le moment )

Personnellement je mettrais en place des sondes de type perfmon comme SQL Server : Buffer cache hit Ratio et SQL Server : Page Life Expectancy qui me permettent de voir comment évolue le cache dans un intervalle de temps.

A+

[castorameur]

Bonjour
De retour après un peu de vacances

@mikedavem
Je vais mettre en place les compteurs perfmon mais j'aimerai une confirmation.
Je les prends dans MSSQL$X3:memory Manager ou dans MSSQL$X3 : Plan Cache ?
Pour le moment j'ai pris "Taux d'accès au cache" et "Pages du cache".
J'ai une version française et je sais que les traductions des compteurs ne sont pas toujours évidente.

En cherchant un peu j'ai trouvé ici http://blog.developpez.com/zinzineti...ation-memoire/ que c'était dans "Buffer Manager"

Pour le moment j'ai une espérance de vie d'une page à 2600 sec et un taux de 99,4 %