Discussion :

[ApprentiOracle]

Bonjour,

J'ai 3 instances SQL 2008 R2 sur une même machine avec 4 processeurs et 20 Go de RAM (on atteint 18Go de RAM utilisée). Le SQLserver est sur une VM.

Nous avons choisi de créer autant d'instances que de client/produit.

Les utilisateurs se plaignent de lenteurs. Comment puis je savoir d'où vient le problème ?

La VM n'a pas l'air surchargée en terme de temps UC. Les procs oscille entre 0 et 10% d'utilisation.

Au niveau du moniteur d'activité, quand je regarde les attentes de ressources, rien ne me saute au yeux. Sur une des instances, Le "buffer I/O" est le plus gros consommateur en temps d'attente cumulé (16040 s) suivi du "backup" (8289s). Il m'est arrivé de constater un temps d'attente sur le buffer I/O de 4200 ms/s sur un temps extrêmement court. (la date du redemarrage du serveur est le 17/10.)

La seconde instance, qui est la plus volumineuse (60 Go de données) a des temps d'attentes cumulés bien différent. Le backup arrive en tete avec 61798s puis le buffer I/O avec 21146 et enfin le network I/O avec 7284s.

Est ce que vous trouvez ces "nombres classiques" ? Avez un conseil à me donner ?

merci

Apprentioracle

[SQLpro]

1) 32 ou 64 bits ?
2) chaque instance est-elle limité en RAM et combien ?
(sp_configure 'max server memory')
3) quelle est la taille des bases de données ?
4) Quelle raison logique ou technique vous à poussé à faire 3 instances ?
5) comment s'effectue le stockage ? Disque virtuel ou Pass Through ???, SAN partagé ou SAN dédié à SQL Server ?
6) avez-vous isolé les CPU/cœurs utilisée pas les différentes instances (masques d'affinité)
7) quel est l'archi CPU/NUMA de votre VM ?

Enfin, sachez qu'en VM, la plupart des compteurs sont faussé par le fait que ces compteurs utilisent l'horloge hardware comme étalon de temps alors que l'hyperviseur passe son temps à commuter d'une machine à l'autre. Pour que les métriques soient correcte il faudrait retirer de ces compteurs les temps absorbés par les autres machines....

En tout état de cause, la VM c'est pas le top (perte de 12 à 15 % de puissance) et diagnostic difficile. À me lire http://blog.developpez.com/sqlpro/p8...virtualisation
Mais le plus merdique c'est toujours le SAN mutualisé (certains l'appelle the silent killer... et je partage entièrement leurs avis)...
À me lire : http://blog.developpez.com/sqlpro/p8...et_le_stocakge
Sachez qu'il n'est pas rare en remaniant la partie stockage avec un SAN dédié de faire un x10 en terme de performances....

Par exemple, voyez si vous n'avez pas dans les journaux de SQL Server le message d'erreur 833 dont le texte est :
SQL Server a rencontré ... occurrence(s) de requêtes d'E/S mettant plus de ...*secondes à s'effectuer dans le fichier ... de la base de données ...
Symptomatique de ce genre de situation !

A +


PS : je viens de terminer le chapitre consacré au stockage de mon livre sur SQL Server à paraître chez Eyrolles... Peut être pourrais-je vous envoyez de la matière !

[ApprentiOracle]

Bonjour SQLpro,

Déjà, merci pour votre retour.
1) 64 Bits
2) Chaque instance est limitée. Une a 8 Go, 1 à 2 et la derniere à 4 Go.
3) Les bases de l'intance n°1 (8Go) fait une 50 Go. Les bases de l'instance n°2 (2Go) font 8 Go et la derniere (4 Go) font 8 Go aussi.
4) Ce sont des applications différentes pour plusieurs clients. on voulait surtout que tout soit étanche.
5) le stockage : disque virtuel en SAN partagé.
6)Les coeurs ne sont pas isolés.
7) 3 serveurs monoproc à 4 coeurs avec utilisation de l'hyperthreading soit un équivalent de 24 processeurs.

Je vais jeter un oeil à vos articles sur la virtualisation.

merci

1) 32 ou 64 bits ?
2) chaque instance est-elle limité en RAM et combien ?
(sp_configure 'max server memory')
3) quelle est la taille des bases de données ?
4) Quelle raison logique ou technique vous à poussé à faire 3 instances ?
5) comment s'effectue le stockage ? Disque virtuel ou Pass Through ???, SAN partagé ou SAN dédié à SQL Server ?
6) avez-vous isolé les CPU/cœurs utilisée pas les différentes instances (masques d'affinité)
7) quel est l'archi CPU/NUMA de votre VM ?

Enfin, sachez qu'en VM, la plupart des compteurs sont faussé par le fait que ces compteurs utilisent l'horloge hardware comme étalon de temps alors que l'hyperviseur passe son temps à commuter d'une machine à l'autre. Pour que les métriques soient correcte il faudrait retirer de ces compteurs les temps absorbés par les autres machines....

En tout état de cause, la VM c'est pas le top (perte de 12 à 15 % de puissance) et diagnostic difficile. À me lire http://blog.developpez.com/sqlpro/p8...virtualisation
Mais le plus merdique c'est toujours le SAN mutualisé (certains l'appelle the silent killer... et je partage entièrement leurs avis)...
À me lire : http://blog.developpez.com/sqlpro/p8...et_le_stocakge
Sachez qu'il n'est pas rare en remaniant la partie stockage avec un SAN dédié de faire un x10 en terme de performances....

Par exemple, voyez si vous n'avez pas dans les journaux de SQL Server le message d'erreur 833 dont le texte est :
SQL Server a rencontré ... occurrence(s) de requêtes d'E/S mettant plus de ...*secondes à s'effectuer dans le fichier ... de la base de données ...
Symptomatique de ce genre de situation !

A +


PS : je viens de terminer le chapitre consacré au stockage de mon livre sur SQL Server à paraître chez Eyrolles... Peut être pourrais-je vous envoyez de la matière !

[SQLpro]

Apparemment vous venez du monde Oracle ou une instance = une base. Ce n'est pas le cas de SQL Server ou les serveurs sont multi base et multi schéma (Oracle va d'ailleurs enfin sortir une version multi base !!!)... Et mieux vaut qu'il n'y ais jamais qu'une seule instance, sauf à surdimensionner notablement votre serveur et cloisonner les ressources (CPU, RAM et disques...)

Bonjour SQLpro,

Déjà, merci pour votre retour.
1) 64 Bits
2) Chaque instance est limitée. Une a 8 Go, 1 à 2 et la derniere à 4 Go.
3) Les bases de l'intance n°1 (8Go) fait une 50 Go. Les bases de l'instance n°2 (2Go) font 8 Go et la derniere (4 Go) font 8 Go aussi.
4) Ce sont des applications différentes pour plusieurs clients. on voulait surtout que tout soit étanche.

Certes ce sera étanche... Mais cela aurait été aussi étanche si vous aviez mis toutes les bases dans la même et unique instance et joué sur les comptes de connexion les utilisateurs SQL et les privilèges et cela à moindre coût à tous les niveaux :
- moindre coût des ressources
- moindre coût d'administration
- meilleures performances
- plus grande facilité d'investigation en cas de problèmes
etc...

5) le stockage : disque virtuel en SAN partagé.

Bingo !
Cherchez pas, c'est la plus grosse partie de votre problème !

6)Les coeurs ne sont pas isolés.

re bingo !

7) 3 serveurs monoproc à 4 coeurs avec utilisation de l'hyperthreading soit un équivalent de 24 processeurs.

Je vais jeter un oeil à vos articles sur la virtualisation.

merci

A +

[ApprentiOracle]

Bonjour SqlPro.

Déjà merci pour vos réponses.

Je vais voir pour tout mettre dans une seule instance. Par contre au niveau memoire allouée à l'unique instance, est qu'il est bon de faire la somme de mmeoire de toutes les instances ?

merci.

Certes ce sera étanche... Mais cela aurait été aussi étanche si vous aviez mis toutes les bases dans la même et unique instance et joué sur les comptes de connexion les utilisateurs SQL et les privilèges et cela à moindre coût à tous les niveaux :
- moindre coût des ressources
- moindre coût d'administration
- meilleures performances
- plus grande facilité d'investigation en cas de problèmes
etc...

A +

[SQLpro]

Prenez toute la RAM moins 2 Go.
Interdisez le ballooning de mémoire au niveau de la VM.

A +