Résumé
Microsoft SQL Server 2005 utilise le compteur UC haute résolution pour fournir des fonctionnalités de minutage de microsecondes. Une microsecondes est le millionième d’une seconde (ou un millième de milliseconde). Toutefois, les valeurs de temporisation SQL Server risquent de ne pas être correctes si vous utilisez des technologies qui changent les fréquences d’UC. Par exemple, ce problème se produit lorsque vous utilisez l’une des technologies suivantes :
-
Exécution pas à pas UC
-
Technologie AMD Cool’n’Quiet
-
Différentes configurations 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 heures d’exécution, de parse et de compilation du serveur, il est possible que vous obteniez des valeurs incorrectes. Par exemple, vous remarquerez peut-être que le temps écoulé de la durée d’exécution de SQL Server est bien supérieur au temps processeur. Ce problème risque d’affecter la précision de l’optimisation des performances. Ce problème survient lorsque vous utilisez l’une des technologies répertoriées dans la section « Résumé » du serveur.
Cause
Ce problème survient en raison du changement de fréquence UC lorsque vous utilisez ces technologies. SQL Server 2005 utilise le compteur UC haute résolution pour fournir des fonctionnalités de minutage de microsecondes. Si les fréquences d’UC sont modifiées pour économiser l’énergie et réduire la puissance thermique, les 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 consulter l’article de la base de connaissances Microsoft :
913089 Comment obtenir le dernier Service Pack pour SQL Server 2005Remarques Dans SQL Server 2005 Service Pack 3 et dans les service packs ultérieurs, le datage du processeur n’est pas utilisé. Ces versions de SQL Server 2005 utilisent une minuterie plus fiable dont la précision maximale est de 1 milliseconde.
Statut
Ce problème a été corrigé pour la première fois dans SQL Server 2005 Service Pack 3.
Solution de contournement
SQL Server 2005 nécessite des points de données connus et stables pour optimiser les performances. Si l’ajustement dynamique de la fréquence de l’UC est activé sur l’ordinateur, vous pouvez les désactiver de sorte que les processeurs maintiennent un taux de fréquence fixe avant de commencer à surveiller et à optimiser les performances de SQL Server. Pour cela, procédez comme suit.
Configurer le schéma d’alimentation de l’ordinateur pour obliger les processeurs à rester à la fréquence maximale
Pour cela, procédez comme suit :
-
Cliquez sur Démarrer, sur exécuter, tapez powercfg. cpl, puis cliquez sur OK.
-
Dans la boîte de dialogue Propriétés de Power Options , cliquez sur toujours activé dans la liste modèles d’alimentation .
-
Cliquez sur OK.
Une dérive est susceptible de se produire. Une dérivation est une divergence entre les valeurs de fréquence UC. Pour plus d’informations, reportez-vous à la section « dérivation ». Dans ce cas, vous devez redémarrer Microsoft Windows pour resynchroniser les fréquences de tous les processeurs une fois que vous avez modifié le schéma d’alimentation. Si vous ne parvenez pas à redémarrer l’ordinateur, activez l’affinité du processeur SQL Server pour empêcher les threads de travail SQL Server de se déplacer entre les UC. Dans ce cas, vous n’avez pas besoin de redémarrer l’ordinateur même en cas de divergence entre les valeurs de fréquence de l’UC. Pour activer l’affinité du processeur SQL Server pour tous les processeurs du serveur, vous devez utiliser un masque différent, en fonction du nombre de processeurs logiques du serveur. Le tableau suivant répertorie des exemples de scénarios.
|
Numéro de l’UC |
Instructions pour activer l’affinité du processeur |
|---|---|
|
02 UC |
exec sp_configure’Affinity Mask', 0x00000003GOreconfigureGO |
|
04 UC |
exec sp_configure’Affinity Mask', 0x0000000FGOreconfigureGO |
|
08 UC |
exec sp_configure’Affinity Mask', 0x000000FFGOreconfigureGO |
|
16 UC |
exec sp_configure’Affinity Mask', 0x0000FFFFGOreconfigureGO |
|
UC 32 |
exec sp_configure’Affinity Mask', 0xFFFFFFFFGOreconfigureGO |
Remarque Il est possible qu’il soit insuffisant de désactiver les fonctionnalités de variante de fréquence de l’UC au niveau du BIOS. Plusieurs utilitaires tiers peuvent modifier les fréquences processeur. Certaines implémentations permettent de régler la fréquence même lorsque les UC sont sous les paramètres de schéma d’alimentation maximum. Dans ce cas, vous devez désactiver ces utilitaires tiers lorsque vous effectuez un ajustement des performances dans SQL Server 2005.
Utiliser des utilitaires et pilotes tiers pour synchroniser les fréquences processeur et les compteurs d’horloge de l’UC
Dans de rares cas, un système risque de nécessiter une mise à jour du fabricant pour résoudre les problèmes de fréquence de l’UC. Il est recommandé de vérifier le système pour obtenir les dernières mises à jour de BIOS, de microcode et de microprogramme si vous soupçonnez que le système peut rencontrer un problème.
Informations supplémentaires
Microsoft SQL Server 2000 et les versions antérieures de SQL Server utilisent les mécanismes de synchronisation Windows. Les mécanismes de minutage utilisent les valeurs de milliseconde-précision. En règle générale, cette précision est de 10 à 15 ms. Toutefois, la précision doit être aussi importante qu' 55 ms. Les requêtes SQL Server sont fréquemment exécutées au sein de millisecondes ou de microsecondes à un chiffre. Cette précision nécessite une temporisation de haute résolution. Par conséquent, ces versions de SQL Server indiquent la durée de certaines requêtes sous la forme 0 ms. Par conséquent, il est difficile de surveiller 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 en utilisant le compteur UC haute résolution pour fournir des fonctionnalités de minutage microsecondes. Lorsque vous utilisez les technologies répertoriées dans la section « Résumé », les valeurs de temporisation indiquées peuvent être incorrectes. Ce problème risque d’affecter les objets et fonctionnalités suivants :
-
Suivi des événements :
-
É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
-
Événements dans le nœud transactions
-
-
Affichages de gestion dynamique :
-
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
-
-
Instruction SET Statistic TIME
-
Table système sysprocesses
Après l’installation de 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 minuteurs à haute résolution ne sont pas synchronisés entre les UC. Le message d’erreur indique que les minutages de performance peuvent être imprécis et qu’ils doivent utiliser des données de performances avec prudence. Le texte du message d’erreur ressemble à l’un des messages d’erreur suivants :
Message d’erreur 1
Le compteur d’horodatage de l’UC de l’ID 2 du planificateur n’est pas synchronisé avec d’autres UC.
Message d’erreur 2
La fréquence d’horodatage de l’UC a changé de 191469 à 1794177 par milliseconde. La nouvelle fréquence est utilisée.
SQL Server utilise l’instruction RDTSC) pour obtenir le nombre de graduations de l’UC 64 bits. Vous pouvez diviser cette valeur par la fréquence UC pour convertir la valeur en valeurs en millisecondes. Des variations de minutage peuvent se produire lorsque le changement de fréquence de l’UC se produit.
Exécution pas à pas UC
L’exécution du processeur est définie comme un changement délibéré de la fréquence de l’UC. La technologie Intel SpeedStep est également connue sous le nom de technologie Intel SpeedStep ou AMD PowerNow !. technologie. Lorsque le niveau d’alimentation processeur se produit, la vitesse du processeur peut augmenter ou diminuer par incréments de 50 MHz pour économiser l’énergie et réduire la sortie thermique. Les processeurs qui se trouvent dans le même nœud de NUMA (non-Uniform Memory Access) ne s’ajustent pas indépendamment des fréquences. Le tableau suivant illustre la manière dont les changements d’exécution de l’UC peuvent affecter les calculs de minutage.
|
Procédure |
RDTSC |
Graduations par milliseconde (fréquence) |
Horloge du mur |
|---|---|---|---|
|
Lot de démarrage |
1 |
200 |
0 |
|
Échelon inférieur |
200 |
100 |
1ms |
|
Mettre fin au lot |
500 |
3ms |
|
|
TOTAUX |
500 |
4ms |
SQL Server capture les graduations RDTSC à la fois sur les RDTSC de début et de fin. Ensuite, SQL Server divise les graduations par la valeur de fréquence. Dans cet exemple, les calculs de minutage suivants se produisent lorsque vous utilisez une valeur de fréquence de 200 ou 100 :
-
Fréquence 200 : 500/200 = 2,5 ms
-
Fréquence 100 : 500/100 = 5 ms
Aucun des calculs de minutage ne correspond au temps réel de l’horloge de 4 ms. Si ce calcul est utilisé dans un événement de suivi complet , les colonnes de données durée et heure de fin sont signalées incorrectement. L’événement RPC : Completed capture le temps d’horloge du mur de début et le nombre de graduations de la CPU. Pour obtenir un délai de résolution supérieur aux informations fournies par Windows dans SQL Server 2005, les colonnes de données durée et heure de fin d’une trace SQL Server sont calculées à l’aide du nombre de graduations UC écoulées. La colonne heure de fin est calculée en ajoutant la colonne durée à la colonne heure de début . Dans cet exemple, la colonne heure de fin est calculée d’une manière incorrecte en ajoutant 2,5 ms ou 5 ms à l’heure de début.
Rive
La dérive est une divergence dans les valeurs d’horloge de l’UC. Les systèmes dotés de plusieurs UC peuvent produire des valeurs d’horloge d’UC différentes pour le même moment. Même si ce n’est pas la plupart du temps, les UC risquent de bénéficier d’une séparation d’horloge au fil du temps. L’exemple suivant montre comment les modifications dérivent peuvent affecter le résultat de la colonne de données Duration dans une trace SQL Server. L’exemple part du principe que la fréquence processeur reste stable aux graduations 200 par milliseconde. Le tableau suivant illustre les événements de ce scénario.
|
Procédure |
PROCESSEUR Windows planifié |
CPU 1 RDTSC |
PROCESSEUR 2 RDTSC |
Horloge du mur |
|---|---|---|---|---|
|
Lot de démarrage |
1 |
100 |
1100 |
0 |
|
Mettre fin au lot |
deuxième |
900 |
1900 |
4 ms |
|
TOTAUX |
4 ms |
SQL Server capture les graduations RDTSC à la fois aux points de départ et aux points de terminaison. Ensuite, SQL Server divise les graduations de RDTSC par la valeur de fréquence. Dans cet exemple, Windows a programmé le thread de travail SQL Server sur deux UC différentes. Le thread de travail SQL Server sur lequel service le lot s’est d’abord exécuté sur le premier processeur (UC 1). Toutefois, l’exécution du lot a été interrompue à un certain point et SQL Server a envoyé l’exécution du lot à la file d’attente en attente. Lorsque SQL Server a envoyé le thread de travail SQL Server qui services ce lot à la file d’attente exécutable, Windows a distribué le thread à exécuter sur la seconde UC (UC 2). Le thread de travail SQL Server exécuté sur le processeur 2. En raison de la dérive du processeur, la valeur end Tick qui a été capturée à partir de l’UC 2 était 1900 au lieu d' 900. Vous pouvez éviter ce comportement si vous activez l’affinité du processeur SQL Server. Les calculs de minutage suivants sont utilisés dans cet exemple :
-
Valeur incorrecte mais signalée : (1900 – 100 = 1800)/200 = 9 ms
-
Valeur correcte : (900 – 100 = 800)/200 = 4 ms
La valeur de la colonne Duration pour l’événement RPC : Completed est signalée par 9 ms au lieu de 4 ms. Ce résultat est supérieur à deux fois la valeur correcte de 4 ms. Les messages d’avertissement dérivant sont ajoutés à SQL Server 2005 pour indiquer que les sorties de performance mentionnées précédemment risquent de ne pas être fiables. Dans certaines situations incouvertes, SQL Server 2005 SP2 risque de signaler des messages d’avertissement concernant ce qui suit :
-
Messages d’avertissement de dérive du faux
-
La dérive peut prendre des dizaines de millisecondes sans provoquer d’effet notable sur le système.
Vous devez être prudent lorsque vous évaluez les sorties relatives aux performances et lorsque vous comparez les sorties relatives aux performances au minutage des horloges murales. S’il n’y a pas de signes d’autres problèmes de performances, vous pouvez généralement ignorer les messages d’avertissement. Par exemple, vous pouvez généralement ignorer les messages d’avertissement dérivant dans les situations suivantes :
-
Les processus s’exécutent comme prévu.
-
Les requêtes SQL Server ne sont pas exécutées en modèles à durée étranges.
-
Vous ne voyez pas de signes d’autres goulets d’étranglement.
Néanmoins, nous vous recommandons de contacter votre fabricant pour vous assurer qu’aucun problème de RDTSC connu n’existe. Vous pouvez utiliser l’indicateur de suivi 8033 (– T8033) pour revenir au comportement de création de rapports dans la version d’origine de SQL Server 2005 et SQL Server 2005 SP1. La version d’origine de SQL Server 2005 et de SQL Server 2005 SP1 ne signale aucun message d’avertissement de dérive. Si vous exécutez la version Release 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-elle correctement ? À propos des processus système périodiques
Les mécanismes de délai d’expiration ne sont pas affectés par la conception haute résolution. SQL Server n’utilise pas le minuteur haute résolution pour les activités basées sur le minuteur. Certaines activités de temporisation sont basées sur le minuteur de résolution réduite qui utilise la fonction GetTickCount . Ces activités de temporisation incluent le délai de verrouillage, l’instruction de TEMPORISation WAITFOR et la détection de blocage.
Pour plus d’informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
938448 Un serveur Windows Server 2003 risque de faire défiler les compteurs d’horodatage si le serveur utilise les processeurs AMD Opteron double cœur ou les processeurs AMD Opteron multiprocesseurs
895980 Les programmes utilisant la fonction QueryPerformanceCounter risquent de fonctionner mal dans Windows Server 2003 et Windows XPLes produits tiers abordés dans cet article sont développés par des sociétés indépendantes de Microsoft. Microsoft ne fournit aucune garantie, implicite ou autre, relative aux performances et à la fiabilité de ces produits.
