[2K5 - cluster] capacity planning

Bonjour,

Je suis à la recherche de comment mettre en place un capacity planning sur mon cluster SQL 2005 SP2. le but est de savoir par exemple combien de base peu encore accueillir mon cluster sans écrouler les performances.

J'ai l'idée de mettre en place une base de reference en faisant un revelé des moyennes de CPU consommées, de moyenne des I/O disque et de la RAM consommée périodiquement.

Quel serait d'apres vous le bon compteur mémoire à prendre en compte et si cela est bien pertinent vu que SQL Serveur fonctionne en permanence avec toute la RAM dont il a de disponible ?

Dans le perfmon, je trouve par instance sur le cluster un Memory Manager avec le compteur "Connection Memory" : Total amount of dynamic memory the server is using for maintaining connections / ce qui pourrait correspondre à l'utilisation de la mémoire pour maintenir les connections SQL Serveur, au plus j'ai de connections actives, au plus ce compteur va grossir ...

Merci de vos conseils ou vos idées sur le sujet.

Bonjour Ducati,

Plutôt que rapprocher la mémoire des connexions utilisateurs, qui ne réprésente pas la cause principale des chutes de performances, je te propose de regarder l'activité de la mémoire en relation avec le sous-système disque. Il semble que SQL Server, lorsqu'il manque mémoire, en raison d'un trop grand nombre de pages en mémoire, travaille avec le disque en complément, ce qui entraine un ralentissement conséquent.

Je cite rudi bruchez : "Memory\Pages/sec : Indique le nombre de pages de mémoire ( dans le sens windows du terme ) qui sont écrites sur le disque, ou lues sur le disque. Un nombre élevé ( par exemple, plus de 2500 pages par secondes, de façon consistante sur un serveur de puissance moyenne, peut indiquer un manque de mémoire. A corréler avec les compteurs de cache de SQL Server, et l'activité disque."

Ce n'est pas le compteur le plus important, il y a le buffer cache hit ratio par exemple qui est plus critique mais moins orienté "mémoire" que le compteur que je te cite.

Commencez par le commencement :le taux de mise en cache (cahc hit ratio du buffer manager) est un bon indicateur.
à plus de 98% c'est excellent
à plus de 95% c'est correct
à moins de 95% c'est pas terrible
à 90% c'est pas bon.
En dessous, c'est catastrophique !

Ensuite auditez la file d'attente des disques. Ne pas dépasser 1 objet par disque physique.

A +

De manière générale, pour voir si un des composants principaux stature (CPU, RAM, Disques, SQL Buffer cache hit ratio), et pour prendre la tension globale du serveur, je relève ces compteurs sur une période assez longue et reflétant l'activité normale.

Memory: Pages/sec
Voir l'explication ci-dessus, je ne vais pas la redire.

Memory: Available Bytes
Quantité de mémoire disponible (à corréler avec la RAM adressée en mode kernel et en mode user)

Physical Disk: % Disk time
Taux d'activité générale du disque (choisir celui ou ceux des mdf, ndf et ldf)

Physical Disk: Avg. Disk Queue Length
Nombre d'opérations d'E/S qui attendent que le disque dur soit disponible. Ne doit pas être supérieur au (nombre de piles + 2).

Processor: % Processor Time
Je ne te fais pas l'affront de t'expliquer celui-là...

System: Processor Queue Length
Nombre de threads existant dans la file d'attente du processeur. Doit être inférieur à 2 x nbr de processeurs.

SQL Server Buffer: Buffer Cache Hit Ratio
Expliqué ci-dessus par SQLpro

SQL Server General: User Connections
La traduction parle d'elle-même...

Merci à tous les trois pour ces réponses,
Pensez vous que je puisse facilement mettre en place cette collecte d'information en renseignant une table SQL Serveur qui pourrait par la suite me donner les informations sous forme de rapport dans Reporting Services ?
kuzco, tu procèdes comment toi ?

Tu peux utiliser le perfmon de Windows, et spécifier que les données collectées doivent être insérées dans une base SQL Server. Par défaut c'est un fichier binaire qui est généré.

Moi j'utilise le fichier binaire. Libre à toi de choisir.