4 votes

Temps disque élevé sur SQL Server

Nous disposons d'un serveur SQL Server 2008 R2 Enterprise Edition dédié.

La configuration est la suivante :

  • D : (fichiers de données) - stocké sur des disques ssd locaux (pas les mêmes disques que les fichiers de log) (raid 10)
  • E : (fichiers journaux) - stockés sur des disques ssd locaux (pas les mêmes disques que les fichiers de données) (raid 1)
  • F : (sauvegarde du journal des transactions) - stocké à distance sur un SAN

Aujourd'hui, nous avons déplacé nos fichiers journaux sur de nouveaux disques (de F : à E :). D'un volume partagé (F :(SAN)) vers des disques locaux dédiés (E :).

Ce qui s'est passé ensuite, c'est que le "disk time", le "avg. transfer time" et le "avg disk write queue length" ont augmenté sur le volume où se trouvent les fichiers de données (D :) (pas sur le volume où se trouvent les fichiers journaux).

Le volume de données et le volume de journalisation ne partagent pas de disques, mais ils partagent la même carte de contrôleur.

Le "temps d'inactivité du disque" est faible pour tous les volumes.

On peut bien sûr penser que la carte contrôleur est peut-être surchargée. Mais, nous avons besoin de plus d'idées sur l'origine du problème.

UPDATE :

Le contrôleur RAID est un DELL PERC H700 (512 Mo de cache). Le serveur est un DELL R910 .

Nous avons environ 2500 transactions / sec pendant les heures de pointe.

Le compteur de "temps disque" est à 100% depuis que nous avons déplacé les fichiers journaux (même pendant les périodes de faible trafic).

Le "temps d'inactivité du disque" est cependant d'environ 98-99% pour D : (fichiers de données) et E : (fichiers journaux).

Nous avons activé le cache en écriture pour les disques de données et les disques d'enregistrement.

Les statistiques d'attente ressemblent à ceci :

wait_type                     wait_time_s
---------                     ----------- 
BROKER_TASK_STOP               1283336.21 
FT_IFTS_SCHEDULER_IDLE_WAIT     101357.47 
PAGELATCH_EX                     89712.72 
BROKER_TRANSMITTER               75894.76
XE_TIMER_EVENT                   38778.35
REQUEST_FOR_DEADLOCK_SEARCH      38770.35
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 38767.03 
FT_IFTSHC_MUTEX                  38759.14
LOGMGR_QUEUE                     38632.87
CHECKPOINT_QUEUE                 38382.63
BROKER_EVENTHANDLER              35082.42   
XE_DISPATCHER_WAIT               34396.31  
DISPATCHER_QUEUE_SEMAPHORE       33578.68

1voto

Patrik Points 51

Après quelques recherches supplémentaires (en vérifiant les temps d'attente et en faisant fonctionner le site avec un pic de trafic), le "problème" décrit ci-dessus n'en était en fait pas un.

Le problème est apparu lorsque nous avons supprimé un goulot d'étranglement (l'ancien stockage des journaux). Ainsi, lorsque nous avons obtenu des disques plus rapides pour les journaux des transactions, les disques de données ont pu gérer plus de transactions par seconde et la longueur de la file d'attente a donc augmenté.

Cela explique aussi pourquoi le temps d'inactivité du disque était bon.

Le compteur de "temps disque" semble être plutôt inutile pour un système de disque rapide (utilisant le cache, etc.).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X