Tempdb lent après une migration vers 2008 R2 [Résolu]

[Philippe Robert]

Je suis confronté à un phénomère de lenteur lors de l'écriture dans la base de données Tempdb après avoir migré vers SQL Server 2008 R2. La migration s'est faite sur une autre machine dont le hardware est identique à la première.

Le serveur a la configuration suivante :

OS Windows 2008 R2 SP1
12 processeurs
Mémoire 72 GB dont 50 GB réservé à SQL
1 seule instance SQL
Microsoft SQL Server Enterprise Edition (64-bit)
La base de données Tempdb est localisée seule sur un disque SSD de 100 GB
La taille minimale de Tempdb est de 8 GB

Sur la machine originale (un SQL 2005 SP3),
- le temps moyen de lecture était de 1,2 ms
- le temps moyen d'écriture était de 3,9 ms

Sur la nouvelle machine (même hardware mais SQL 2008 R2)
- le temps moyen de lecture était de 1,7 ms
- le temps moyen d'écriture était de 320,8 ms

Je ne comprends pas comment la vitesse d'écriture est devenue aussi faible. Nous avons fait des tests de transfert de fichier sur ce disque SSD et pourtant la vitesse d'écriture est la même qu'auparavant. Pourquoi SQL Serveur écrit si lentement dans sa base Tempdb ?

J'ai changé la vérification de page de CHECKSUM à NONE mais cela n'améliore pas le temps d'écriture

Quelques idées ?
D'avance, merci.

[mikedavem]

Pas d'antivirus activé ?

++

[Philippe Robert]

Non. Il n'y a pas d'antivirus installé.

[Philippe Robert]

J'ai rectifié mon message initial : le disque SSD fait 100 GB au lieu de 10 GB.

[mikedavem]

Juste pour bien comprendre :

Est ce SQL Server qui écrit lentement ou même la copie d'un fichier autre est lente sur ce disque ? En d'autres terme est ce que c'est le disque qui est en cause ?

++

[Sergejack]

Quel était votre ancien "Recovery model" et quel est l'actuel ?

[Philippe Robert]

C'est l'écriture par SQL Server qui est lente dans TempDB. Par contre, l'écriture par l'OS est rapide quand ont teste des copies de fichiers.

Les mesures de temps d'accès par SQL sont fournies par la DMV sys.dm_io_virtual_file_stats, les temps de lecture/écriture moyen me sont fournies par le calcul suivant :

Code :

1
2
CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms]

Je sauvegarde ces valeurs toutes les heures, ce qui m'a permis de déceler ce problème. Les requêtes faisant usage de la base de données Tempdb sont plus lentes depuis la migration.

[Philippe Robert]

Le Recovery Model est en mode "simple" avant et après migration.

[mikedavem]

Pas d'option qui trainerait comme autoshrink ou auto close ? Des fois que ...

++

[Sergejack]

Envoyé par mikedavem

Pas d'option qui trainerait comme autoshrink ou auto close ? Des fois que ...

++

Dans le même ordre de considération, vérifiez que vous avez pour les fichiers data et logs des tailles initiales et des delta pour les croissances des fichiers pertinentes.
Il vaut mieux que le fichier reste un peu trop gros longtemps, que trop léger souvent.

[Philippe Robert]

On est en train de vérifier l'alignement des partitions avec l'aide du document
"Disk Partition Alignment Best Practices for SQL Server" trouvé chez Microsoft.

[mikedavem]

Si tu es en 2008 tu n'auras pas de souci d'alignement de partition. L'offset est par défaut à 1024 (contrairement à 2003)

++

[Philippe Robert]

Envoyé par Sergejack

Dans le même ordre de considération, vérifiez que vous avez pour les fichiers data et logs des tailles initiales et des delta pour les croissances des fichiers pertinentes.
Il vaut mieux que le fichier reste un peu trop gros longtemps, que trop léger souvent.

La taille allouée est de 8 GB pour le fichier data et aussi de 8 GB pour le fichier log. La croissance est par pas de 10%, illimitée. La réduction automatique est désactivée. Le fichier data a augmenté à 14 GB, suite à un calcul complet des statistiques effectué après la migration.

[mikedavem]

Etrange ton souci vu de loin.

Tu as fais un benchmark de ton disque SSD avec sqlio pour voir.

A tout hasard et si tu en as la possibilité est ce que le fait de redémarrer ton instance "règle" ton souci ?

++

[Glouferu]

L'allocation unit size de la partoche est-il différent entre les 2 machines?

[Philippe Robert]

Envoyé par mikedavem

A tout hasard et si tu en as la possibilité est ce que le fait de redémarrer ton instance "règle" ton souci ?

C'est ce que l'on prévois de faire : arrêter le service, formatter le disque SSD, et relancer le service. Mais on doit attendre le soir pour cela. Je vous tiendrai informé des résultats obtenus.

Je ne connais pas SQLIO, mais cela ne semble pas être supporté par Windows 2008.

http://www.microsoft.com/download/en....aspx?id=20163

Je vais aussi essayer le SQL Server 2008 R2 Best practice Analyser aussi.

[Philippe Robert]

Envoyé par Glouferu

L'allocation unit size de la partoche est-il différent entre les 2 machines?

Non, c'est le même. En fait, c'est la même carte SSD que l'on a débranché de l'ancienne machine vers la nouvelle. L'ancienne machine était aussi en Windows 2008 R2 SP1

[Glouferu]

Envoyé par Philippe Robert

C'est ce que l'on prévois de faire : arrêter le service, formatter le disque SSD, et relancer le service. Mais on doit attendre le soir pour cela. Je vous tiendrai informé des résultats obtenus.

Je ne connais pas SQLIO, mais cela ne semble pas être supporté par Windows 2008.

http://www.microsoft.com/download/en....aspx?id=20163

Je vais aussi essayer le SQL Server 2008 R2 Best practice Analyser aussi.

Moi j'utilise SQLIOsim qui se trouve dans le répertoire d'install de SQL SERVER.
Il va simuler l'activité SQL Server sur les disques et donner les IO et temps de latence Disk.

[mikedavem]

Envoyé par Philippe Robert

Je ne connais pas SQLIO, mais cela ne semble pas être supporté par Windows 2008.

http://www.microsoft.com/download/en....aspx?id=20163

C'est effectivement pas notifié sur la page de téléchargement mais il fonctionne sans problème sur 2008 (pour l'avoir déjà utilisé sur cet Os)

++

[mikedavem]

Envoyé par Glouferu

Moi j'utilise SQLIOsim qui se trouve dans le répertoire d'install de SQL SERVER.
Il va simuler l'activité SQL Server sur les disques et donner les IO et temps de latence Disk.

Attention SQLIOSim n'a pas du tout la même finalité que SQLIO. SQLIO Sim permet de tester la stabilité du sous système disque alors que SQLIO permet de tester les performances du sous système disque.

++