[SQL2008] problème lenteurs disque

[castorameur]

Bonjour,

dans la suite de mes problèmes d'infra voici le dernier :
- la Bdd fait 80 Go et le serveur a 32 Go de ram, sql serveur ayant 24 Go de ram
-serveur virtuel OSX wmware

L'opération consiste en une migration de structure :
on prend les données, on les stock en temp et on les écrit dans la nouvelle structure.

=> je constate des perfs pas terribles au niveau du disque:
le % d'inactivité est entre 10 et 30 %
le taux d'écriture est inférieur à 1 Mo/s

=>en ce qui concerne la ram on a
% de hit du cache proche de 100%
durée vie d une page 18 000 secondes

=> et quand je regarde dans le moniteur sql j'ai 9000 secondes d'attente sur le buffer i/o depuis le lancement de la tache hier (la tache dure 40 heures en tout)

cela me donne l'impression d'avoir perdu presque 3h en I/O
Qu'est ce qui ne va pas ??

merci

[SQLpro]

Vous êtes en VM et je suppose en disque virtuel.....
Si en plus vous gestion de RAM est en ballooning...

A lire : http://blog.developpez.com/sqlpro/p8...irtualisation/

A +

[castorameur]

Merci de votre réponse mais ce n'est pas rassurant pour l'avenir.

cela va aussi répondre à mon autre post http://www.developpez.net/forums/d11...-cumules-lock/

[castorameur]

Envoyé par castorameur

Merci de votre réponse mais ce n'est pas rassurant pour l'avenir.

cela va aussi répondre à mon autre post http://www.developpez.net/forums/d11...-cumules-lock/

Par contre je pensais qu'en mettant plus de RAM dans la machine virtuelle je pouvais compenser un peu cette baisse de perf.

La machine physique qui a été remplacé avait 16 Go de ram (10 pur sql) alors que maintenant la VM en a 32 et 24 pour SQL.
D'apres les compteurs mem il y a pas mal de pages en mémoire mais cela ne compense pas la perte de perf ?

[SQLpro]

Un SGBDR fait des écritures sur les disques. Notamment pour les transactions qui constituent un point d’étranglement.
Lisez ceci : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

A +

[mikedavem]

Comment est structuré votre architecture disque sur votre nouvelle machine virtuelle ? Au niveau VMWARE (datastores) et stockage (LUNS, HBA, FC etc ...) ?

Avez-vous des métriques de performances de votre sous système disque ?

Physical Disk :
-% Disk Time
- Avg. Disk Queue Length
- Avg. Disk sec/Read
- Avg. Disk sec/Writes
- Avg. Disk sec/Transfer
- Disk Reads/sec
- Disk Writes/sec

++

[castorameur]

Bonjour

@Sqlpro : J'ai lu l'article mais cela n'a pas répondu complètement à ma question. Dans son fonctionnement est ce qu'SQL est capable de faire des mises à jour dans son cache (update/delete/...) avant de les transférer au fichier journal sur le disque? Ou est ce qu'il y a trop de risque à mettre à jour le cache en cas de plantage ?

@mikedavem: je n'ai pas la main sur le système physique qui est à la charge du technicien système.

Pour les compteurs, vous voulez ceux du sys physique ou de l'image ?

[SQLpro]

Dans tous les bons SGBDR (oracle; SQL Server, DB2...) tout est fait en mémoire et les écritures disques sont minimales et optimales à condition d'utiliser des disques physiques et des agrégats permettant de savoir physiquement ou se trouvent les pages sur le disque.

A +

[castorameur]

Si j'essaie de comprendre :

->En serveur physique cela sert d'avoir "plus" de mémoire car SQL server est capable de savoir où se situe les pages sur le disque
Mais
->Sur dans une virtualisation l'ajout de mémoire n'augmente pas les perfs car SQL server effectue de mauvais choix car il ne voit pas les disques physiques.

Est ce cela?

[SQLpro]

Non, ce n'est pas relatif à la RAM, sauf si "ballooning", mais relatif aux accès disques. Plus l'accès disque est lents, plus longtemps les verrous sont maintenus dans les transactions et donc plus les utilisateurs se bloquent, donc plus il y a de temps d'attente et plus le SGBDR devient globalement lent.

A +