Les valeurs de minuterie de SQL Server peuvent être incorrects lorsque vous utilisez des utilitaires ou des technologies qui modifient les fréquences du processeur

Résumé

Microsoft SQL Server 2005 utilise le compteur processeur haute résolution pour fournir des capacités de minutage microsecondes. Une microseconde est la millionième de seconde (ou un millième d’une milliseconde). Toutefois, les valeurs de minuterie de SQL Server peuvent être incorrects si vous utilisez des technologies qui modifient les fréquences du processeur. Par exemple, ce problème peut se produire lorsque vous utilisez une des technologies suivantes :

  • Processeur exécution pas à pas

  • AMD Cool'n'Quiet technologie

  • Divers schémas d’alimentation

Cet article contient des méthodes et des informations supplémentaires pour vous aider à résoudre ce problème.

Symptômes

Lorsque vous utilisez l’instruction SET STATISTICS TIME pour afficher les temps de compilation, l’exécution du serveur et analyse, vous pouvez obtenir des valeurs incorrectes. Par exemple, vous pouvez remarquer que le temps écoulé de la durée d’exécution de SQL Server est beaucoup plus de temps processeur. Ce problème peut affecter la précision du réglage des performances. Ce problème se produit lorsque vous utilisez l’une des technologies qui sont répertoriés dans la section « Résumé » sur le serveur.

Cause

Ce problème se produit parce que les fréquences du processeur sont modifiés lorsque vous utilisez ces technologies. SQL Server 2005 utilise le compteur processeur haute résolution pour fournir des capacités de minutage microsecondes. Si les fréquences du processeur sont modifiées pour économiser de l’énergie et de réduire la chaleur produite, durées calculées peuvent être incorrectes.

Résolution

Informations sur le service pack

Pour résoudre ce problème, procurez-vous le dernier service pack pour SQL Server 2005. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

913089 comment obtenir le dernier service pack pour SQL Server 2005
Remarque Dans SQL Server 2005 Service Pack 3 et service packs ultérieurs, l’horodatage du processeur n’est pas utilisé. Ces versions de SQL Server 2005 utilisent une horloge plus fiable qui a une précision maximale de 1 milliseconde.

État

Ce problème a été corrigé dans le Service Pack 3 de SQL Server 2005.

Solution de contournement

SQL Server 2005 requiert des points de données connus et stable pour effectuer le réglage des performances précises. Si les réglages de fréquence dynamiques du processeur sont activés sur l’ordinateur, vous pouvez les désactiver pour les UC conserver une fréquence régulière avant de commencer à surveiller et optimiser les performances de SQL Server. Pour ce faire, utilisez les méthodes suivantes.

Configurer le mode d’alimentation sur l’ordinateur pour forcer l’UC reste à la fréquence maximale

Pour ce faire, procédez comme suit :

  1. Cliquez sur Démarrer, sur exécuter, tapez Powercfg.cpl, puis cliquez sur OK.

  2. Dans la boîte de dialogue Propriétés de Options d’alimentation , cliquez sur Toujours dans la liste de l’alimentation .

  3. Cliquez sur OK.

Une dérive peut se produire. Une dérive est une divergence entre les valeurs de fréquence du processeur. Pour plus d’informations, consultez la section « Dérive ». Dans ce cas, vous devez redémarrer Microsoft Windows pour resynchroniser les fréquences de toutes les UC après avoir modifié le schéma d’alimentation.

Si vous ne pouvez pas redémarrer l’ordinateur, activer l’affinité du processeur de SQL Server empêcher le déplacement entre unités centrales des threads de travail SQL Server. Lorsque vous effectuez cette opération, vous n’êtes pas obligé de redémarrer l’ordinateur, même si une divergence entre les valeurs de fréquence du processeur se produit. Pour activer l’affinité du processeur de SQL Server pour tous les processeurs sur le serveur, vous devez utiliser un autre masque, selon le nombre de processeurs logiques qui se trouvent sur le serveur.

Le tableau suivant répertorie des exemples de scénarios.

Numéro de l’UC

Instructions à activer l’affinité de processeur

02 UC

EXEC sp_configure « masque d’affinité, « 0 x 00000003
GO
reconfigurer
GO

04 UC

EXEC sp_configure « masque d’affinité », 0x0000000F
GO
reconfigurer
GO

08 UC

EXEC sp_configure « masque d’affinité », 0x000000FF
GO
reconfigurer
GO

16 processeurs

EXEC sp_configure « masque d’affinité,' 0x0000FFFF
GO
reconfigurer
GO

32 processeurs

EXEC sp_configure « masque d’affinité,' 0xFFFFFFFF
GO
reconfigurer
GO

Remarque Il peut être insuffisant pour désactiver les fonctionnalités de variation de fréquence du processeur au niveau du BIOS. Divers utilitaires de tiers peuvent modifier les fréquences du processeur. Certaines implémentations activer l’ajustement de la fréquence même lorsque les processeurs sont sous paramètres de régime de puissance maximale. Dans ce cas, vous devez désactiver ces utilitaires tiers lorsque vous effectuez le réglage des performances dans SQL Server 2005.

Permet de synchroniser les fréquences du processeur et des compteurs d’horloge du processeur les pilotes et les utilitaires tiers

Dans de rares occasions, un système peut nécessiter une mise à jour auprès du fabricant pour corriger des problèmes de fréquence du processeur. Il est recommandé de vérifier le système pour les dernières mises à jour du BIOS et du firmware du microcode si vous pensez que le système peut avoir un problème.

Plus d'informations

Microsoft SQL Server 2000 et les versions antérieures de SQL Server utilisent les mécanismes de synchronisation de Windows. Les mécanismes de synchronisation utilisent des valeurs de précision à la milliseconde. En général, cette précision est toutefois les 10 à 15 ms., la précision peut être aussi grande que ms 55. Les requêtes SQL Server s’effectue généralement à un seul chiffre de la milliseconde ou périodes de microsecondes. Cette précision nécessite un timer haute résolution. Par conséquent, ces versions de rapport de SQL Server la durée de certaines requêtes sous la forme 0 Mme donc, il est difficile de contrôler les performances et d’optimiser les performances de SQL Server dans les versions antérieures de SQL Server.

SQL Server 2005 améliore la précision à l’aide du compteur processeur haute résolution pour fournir des capacités de minutage microsecondes. Lorsque vous utilisez les technologies qui sont répertoriés dans la section » Résumé", les valeurs de temporisation signalée peuvent être incorrects.

Ce problème peut affecter les objets et fonctions suivants :

  • Événements de trace :

    • L’événement Attention

    • Événements dans le nœud procédures stockées

    • Événements dans le nœud TSQL

    • Événements dans le nœud objets de

    • Événements dans le nœud de Transactions

  • Vues de gestion dynamiques :

    • sys.dm_exec_query_stats

    • sys.dm_exec_requests

    • sys.dm_exec_sessions

    • sys.dm_io_pending_io_requests


    • sys.dm_os_ring_buffers

    • sys.dm_os_sys_info

    • sys.dm_io_virtual_file_stats

    • sys.dm_os_wait_stats

  • L’instruction SET STATISTICS TIME

  • La table système sysprocesses

Après avoir installé SQL Server 2005 Service Pack 2 (SP2), SQL Server enregistre un message d’erreur dans le journal des erreurs lorsque SQL Server détecte que les horloges haute résolution ne sont pas synchronisés entre les processeurs. Le message d’erreur indique que minutage des performances peut ne pas être précise, et les utilisateurs doivent utiliser les données de performance avec précaution.

Le texte du message d’erreur semblable à l’un des messages d’erreur suivants :

Message d'erreur 1

Le compteur de cachet de temps de l’UC sur l’id du planificateur 2 n’est pas synchronisé avec les autres processeurs.

Message d'erreur 2

Fréquence de cachet de temps UC a été modifié à partir de 191469 à 1794177 de graduations par milliseconde. La nouvelle fréquence sera utilisée

SQL Server utilise l’instruction en temps réel cachet compteur (RDTSC) pour obtenir le nombre de cycles de processeur 64 bits. Vous pouvez diviser cette valeur par la fréquence du processeur pour convertir la valeur de milliseconde. Les variations de minutage peuvent se produire lorsque les modifications de fréquence du processeur ou de la dérive se produit.

Processeur exécution pas à pas

CPU stepping est définie comme une modification délibérée de la fréquence du processeur. CPU stepping est aussi connu comme la technologie Enhanced Intel SpeedStep ou AMD PowerNow ! technologie. Lors de la CPU stepping se produit, la vitesse du processeur peut augmenter ou diminuer par incréments aussi petits que 50 MHz pour économiser de l’énergie et de réduire la chaleur produite. Les processeurs qui se trouvent dans le même nœud de mémoire non uniforme (NUMA) d’accès ne s’ajustent pas indépendamment les fréquences.

Le tableau suivant illustre comment les modifications d’exécution pas à pas UC peuvent affecter les calculs de temporisation.

Action

Écart RDTSC graduations

Battements par milliseconde (fréquence)

Heure de l’horloge murale

Démarrer le traitement par lots

1

200

0

Étape de fréquence vers le bas

200

100

1ms

Lot de fin

500

3ms

TOTAUX

500

4ms

SQL Server capture les graduations de l’écart RDTSC à des battements d’écart RDTSC le début et la fin. Puis, SQL Server répartit les graduations par la valeur de la fréquence.

Dans cet exemple, les calculs suivants de temporisation se produisent lorsque vous utilisez une valeur de fréquence de 200 ou 100 :

  • Fréquence de 200 : 500/200 = 2,5 ms

  • Fréquence de 100 : 500/100 = 5 ms

Aucun des calculs de temps correspond à l’horloge murale réel de 4 ms.

Si ce calcul est utilisé dans un RPC : terminé colonnes de données événement, la durée et l’heure de fin de trace sont rapportées de façon incorrecte. Le RPC : terminé événement capture le départ du temps et de nombre de cycles processeur. Pour obtenir le temps de résolution plus élevée que Windows fournit dans les colonnes de données de SQL Server 2005, la durée et l’heure de fin dans un SQL Server trace sont calculés à l’aide du nombre de cycles UC écoulé. La colonne heure de fin est calculée en ajoutant la colonne durée dans la colonne heure de début . Dans cet exemple, la colonne heure de fin est calculée en ajoutant incorrectement des 2,5 ms, soit 5 ms à l’heure de début.

Dérive

La dérive est une divergence dans les valeurs d’horloge du processeur. Les systèmes dotés de plusieurs processeurs peuvent produire différentes valeurs d’horloge du processeur pour le même point dans le temps. Bien qu’il n’est pas courant, processeurs peuvent rencontrer séparation d’horloge au fil du temps.

L’exemple suivant montre comment les modifications de la dérive peuvent affecter le résultat de la colonne durée dans une trace SQL Server. L’exemple suppose que la fréquence du processeur reste stable à 200 graduations par milliseconde. Le tableau suivant répertorie les événements dans ce scénario.

Action

Processeur planifiée de Windows

ÉCART RDTSC DE PROCESSEUR 1

ÉCART RDTSC DU PROCESSEUR 2

Heure de l’horloge murale

Démarrer le traitement par lots

1

100

1100

0

Lot de fin

2

900

1900

4 ms

TOTAUX

4 ms

SQL Server capture les graduations de l’écart RDTSC à la fois les points de départ et les points d’extrémité. Ensuite, SQL Server divise les graduations écart RDTSC par la valeur de la fréquence. Dans cet exemple, Windows planifié le thread de travail de SQL Server sur les deux processeurs différents. Tout d’abord, le thread de travail SQL Server qui traite le lot exécuté sur le premier processeur (CPU 1).

Toutefois, l’exécution du traitement par lots a été interrompue à un moment donné, et SQL Server envoyé l’exécution du traitement par lots à la file d’attente. Lorsque SQL Server envoyés à la thread de travail SQL Server servant à nouveau ce traitement par lots à la file d’attente exécutable, Windows distribué au thread de s’exécuter sur le second processeur (UC 2). Le thread de travail SQL Server exécuté sur le processeur 2. En raison de la dérive de l’UC, la valeur de graduation de fin qui ont été capturée à partir de l’UC 2, a été 1900 au lieu de 900. Vous pouvez éviter ce comportement si vous activez l’affinité du processeur de SQL Server.

Les calculs de synchronisation suivants sont utilisés dans cet exemple :

  • Le mais incorrect signalées valeur : (1900 – 100 = 1800) / 200 = 9 ms

  • Corriger la valeur : (900 – 100 = 800) / 200 = 4 ms

La valeur de la colonne durée de la RPC : terminé événement serait signalé comme 9 ms au lieu de 4 Mme ce résultat est plus de deux fois la valeur correcte de 4 ms.

Dérive des messages d’avertissement sont ajoutés à SQL Server 2005 pour indiquer que les sorties de performances mentionnés plus haut n’est peut-être pas fiables. Dans certains cas non couverts, SQL Server 2005 SP2 peut signaler des messages d’avertissement sur les éléments suivants :

  • Messages d’avertissement dérive false

  • DÉRIVES peuvent devenir des dizaines de millisecondes sans provoquer un effet de système

Vous devez être prudent lorsque vous évaluez les sorties liées aux performances, et lorsque vous comparez les sorties liées aux performances de fréquences d’horloge murale. S’il n’y a aucun signe d’autres problèmes de performances, vous pouvez généralement ignorer les messages d’avertissement dérive. Par exemple, vous pouvez généralement ignorer les messages d’avertissement dérive dans les situations suivantes :

  • Les processus sont exécutent comme prévu.

  • Les requêtes SQL Server ne s’exécutent pas dans les modèles durational étranges.

  • Vous ne voyez pas de signes d’autres goulots d’étranglement.

Toutefois, avant de vous ignorez la dérive du message, nous vous conseillons de contacter votre fabricant pour vous assurer qu’aucun écart RDTSC problèmes connus existent.

Vous pouvez utiliser l’indicateur de trace 8033 (-T8033) pour retourner au comportement de reporting dans la version d’origine de SQL Server 2005 et dans SQL Server 2005 SP1. La version d’origine de SQL Server 2005 et SQL Server 2005 SP1 ne pas signaler les messages d’avertissement dérive. Si vous exécutez la version d’origine de SQL Server 2005 ou SQL Server 2005 SP1 sans problème, vous pouvez généralement ignorer les messages.

Pourquoi l’instruction WAITFOR DELAY fonctionne-t-il correctement ? Qu’en est-il des processus périodiques du système ?

Mécanismes de délai d’attente ne sont pas concernés par la conception de haute résolution. SQL Server n’utilise pas l’horloge haute résolution pour les activités basées sur timer. Certaines activités de délai d’attente sont basées sur l’horloge de résolution réduite qui utilise la fonction GetTickCount . Ces activités de délai d’attente incluent le délai de verrouillage, l’instruction WAITFOR DELAY et détection des verrous mortels.

Pour plus d’informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :

938448 serveur A Windows Server 2003 peut rencontrer dérive du compteur d’horodatage si le serveur utilise la technologie double cœur AMD Opteron ou des processeurs AMD Opteron multiprocesseurs

895980 les programmes qui utilisent la fonction QueryPerformanceCounter peuvent médiocres dans Windows Server 2003 et Windows XP

Les produits tiers dont traite cet article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute forme de garantie, expresse ou implicite, concernant les performances ou la fiabilité de ces produits.

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×