pourquoi io_stall_writes_ms est-il tellement plus élevé pour tempdb?

Nous avons les fichiers de données utilisateur et système sur le même lecteur de disque. Le (io_stall_write_ms / (1.0 + num_of_writes)) est inférieur à 2 pour les fichiers utilisateur mais les fichiers tempdb sont généralement plus de 400. Je vois cela sur quelques serveurs et je suis curieux de savoir s'il y a une raison pour laquelle il faut plus de temps pour écrire dans tempdb qu'un fichier de données de base de données ordinaire.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Merci,

Réponse courte: Voir des décrochages d'E / S plus élevés peut ou non être un problème en soi. Vous devez consulter plus d'informations pour savoir si vous avez un problème. Cela semble un peu élevé, oui, mais souffrez-vous? Si c'est le cas, c'est probablement parce que votre système d'E / S ne gère pas la charge correctement (parce qu'il ne le peut pas, parce que vous avez tout sur un lecteur ou pour une autre raison) ou que vous en faites trop dans TempDB (changer le premier problème - les performances d'E / S - est probablement une solution plus simple et plus efficace, mais déterminez d'abord si vous avez un problème)

La discussion / réponse plus longue:

Il y a deux questions en jeu ici -

1.) Que dois-je faire lorsque je vois des décrochages d'E / S élevés?

Tout d'abord, "haut" est dans l'œil du spectateur. Si vous deviez demander à 10 DBA ce qu'est "trop ​​élevé" pour les décrochages d'E / S, vous obtiendriez probablement 2-3 réponses différentes avec des nombres, 5-6 réponses "Ça dépend" et un regard vide. Mon hypothèse est qu'une moyenne de 400 ms est potentiellement trop élevée ici, surtout lorsque les autres DB sont de 2 ms ou moins pour le temps de décrochage moyen.

Quelle que soit la base de données qui voit les stalles élevées, vous devez l'approcher de la même manière. Un décrochage IO est ce que cela ressemble ... Une demande IO prend plus de temps que prévu .. Décrochage. Cela arrive. Ils se produisent tout le temps dans un système avec des ressources partagées et des ressources finies (vraiment tous nos systèmes). Ils deviennent un problème lorsque les étals deviennent des problèmes de performances ou y conduisent. J'espère donc que vous regardez ici comme une partie proactive de la surveillance ou parce que vous rencontriez des problèmes de performances que vous dépannez. Nous ne voulons pas non plus nous perdre dans les stalles IO. Nous regardons une pièce du puzzle et non une vue d'ensemble. Il peut être gênant de simplement regarder les statistiques d'attente ou les statistiques de fichier depuis le dernier redémarrage de SQL car vous regardez en tout temps et une fenêtre de maintenance ou une fenêtre de charge élevée peut fausser les compteurs. Assurez-vous donc de regarder l'image complète.

Mais lorsque je soupçonne que j'ai un problème de performances de disque ou que je vois quelque chose de différent dans une requête comme celle-ci, je suis normalement un processus qui ressemble à ceci:

1. Regardez les statistiques d'attente sur le serveur. @swasheck a partagé un excellent lien en tant que commentaire dans une réponse ci-dessous. Cela vous amène au post de Paul Randal sur la consultation et l'analyse des statistiques d'attente dans SQL Server. Va là-bas. Quel genre d'attente voyez-vous? Voyez - vous attend liés à la performance IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, etc.?). Si vous faites cela, cela indique que vous avez des problèmes de performances liés aux E / S, tout comme les blocages d'E / S. Mais cela vous donne ici une autre forme d'accord.
2. Regardez les performances d'E / S. En particulier, regardez à l'intérieur de perfmon aux compteurs Physical Disk:Avg Disk Sec/Readet Avg Sec Disk Sec/Write. Ceux-ci mesurent votre latence. Regardez ces compteurs sur une période de temps enregistrée dans un fichier journal de performances. Qu'avez-vous vu pour les moyennes? Si vous voyez des nombres supérieurs à 0,020 seconde (20 ms), cela pourrait être un problème. Si vous voyez des nombres supérieurs à 40-50 ms en moyenne ou plus, c'est une indication plus ferme d'un problème. Regardez aussi vos pointes? Jusqu'où vont-ils et combien de temps durent-ils? Si vous voyez des pics dans les centaines de ms et qu'ils durent des dizaines ou des dizaines de secondes ou plus et / ou se produisent fréquemment, vous êtes plus susceptible d'avoir un problème avec vos performances d'E / S pour votre charge de travail.
3. Regardez votre configuration d'E / S. Qu'Est-ce que c'est? Disques locaux? SAN? Baie de stockage? Quel genre de tout au long et IOP devriez-vous voir de cela? Est-ce suffisant pour ce que vous essayez de faire? Vous avez peut-être sous-dimensionné votre E / S pour votre charge de travail. Ne vous contentez pas de regarder vos broches physiques, vos paramètres RAID, etc. Regardez vos chemins d'accès à vos disques. Poussez-vous tout à travers un seul lien de 1 Go que vous partagez avec beaucoup d'autres trafics? Pouvez-vous examiner les mesures de performances du disque du point de vue du stockage.

( Remarque: pour cette analyse des statistiques d'attente et l'analyse des performances - examinez les différentes périodes et types d'utilisation. Avez-vous des statistiques d'utilisation différentes la nuit que pendant la journée? Fenêtres de traitement par lots? Fenêtres de maintenance où vous reconstruisez un grand nombre d'index? Regardez ces outils pendant chacune de ces périodes et comprenez ce que vous voyez pour chacun)

Une autre considération de performance IO ici -

• Vous avez dit que les bases de données système et les bases de données utilisateur sont partagées. C'est cette production? Si c'est le cas, ce n'est pas toujours le meilleur scénario. Partagez-vous également des fichiers journaux et des fichiers de données sur les mêmes disques? Ce n'est pas non plus le meilleur scénario. Quoi d'autre partage ce stockage? Dans un monde où vous vous inquiétez des broches et des groupes de raid et des disques et devez décider qui obtient les disques les plus performants, j'ai tendance à (en règle générale .. ce qui n'est pas génial d'avoir dans le monde DB mais celui-ci a tendance à rester vrai) allez avec mon plus rapide et le plus dédié à TempDB (plus sur cela ci-dessous), puis les fichiers journaux, puis les fichiers de données. Dans un monde où vous avez une grande pile de disques sur un appareil comme NetApp, Dell Equal Logic ou EMC VNX, etc.

2.) Quelles sont les raisons pour lesquelles TempDB pourrait être plus élevé?

Donc TempDB est une base de données et il peut avoir des décrochages d'E / S comme toute autre base de données comme je viens de le dire. Mais quelles sont les raisons pour lesquelles TempDB peut avoir des lectures plus élevées? (non exhaustif, je me réjouis des ajouts ou des réflexions dans les modifications, autres réponses ou commentaires) -

1. À cause de votre code - Utilisez-vous beaucoup TempDB dans votre code à dessein? Beaucoup de tables temporaires et de variables de table créées et détruites? Faire beaucoup de choses dans TempDB comme ça? Ce n'est pas nécessairement mauvais ou bon, mais vous pouvez regarder cela et comprendre votre modèle d'utilisation intentionnelle de TempDB.
2. TempDB est un cheval de bataille partagé - TempDB est une base de données qui est utilisée comme un espace temporaire pour les objets temporaires définis par l'utilisateur et diverses tables de travail et opérations utilisées par l'ensemble de votre instance SQL. Combien de DB d'utilisateurs existe-t-il? Quel type de charge de travail voyez-vous en général? TempDB est une ressource pour toutes choses à partager.
3. Requêtes inefficaces et mémoire insuffisante - Peut-être y a-t-il des requêtes qui n'utilisent pas suffisamment les index ou effectuent de grandes opérations de numérisation et de tri. Opérations de hachage volumineuses et la mémoire sur le serveur n'est pas suffisante pour celles-ci. Ces opérations "se répandront" sur TempDB en tant que tables de travail en arrière-plan. Parfois, cela peut être évité en consultant vos plans de requête et l'indexation ou le réglage des requêtes. Parfois, cela arrive (plus encore sur les charges de travail de l'entrepôt, je trouve). Si vous disposez de suffisamment de mémoire, cela peut vous aider, mais ces requêtes peuvent parfois se répandre. Regardez ça aussi.
4. Utilisez-vous le niveau d'isolement de lecture instantanée avec un bon nombre de mises à jour dans votre système? Cela peut également entraîner une augmentation de l'activité TempDB.

Le fait est que TempDB est utilisé de nombreuses façons, et cela ne me surprend pas du tout de le voir comme l'une de vos bases de données les plus occupées, sinon la plus occupée. Cela ne me surprend pas non plus quand je le considère comme ayant le plus grand nombre de stands et la moyenne la plus élevée de toutes les bases de données sur le site d'un client. C'est parfois la nature de sa charge de travail. L'examen de certaines des choses que j'ai mentionnées ici peut certainement vous aider à déterminer si ces chiffres indiquent un problème et, dans l'affirmative, comment approfondir la solution.

TempDB est partagé entre toutes les bases de données de l'instance. Il peut donc parfois y avoir des conflits au sein de TempDB pour certaines pages: SGAM , GAM et PFS . En un mot, ces pages gardent une trace de ce qui a été utilisé dans TempDB jusqu'à présent, et où l'espace est disponible pour une nouvelle utilisation.

En règle générale, cela est traité en ajoutant plusieurs fichiers de données à TempDB. Il existe plusieurs philosophies différentes quant au nombre correct, mais tous conviennent que vous devriez en avoir plusieurs.

Voici quelques requêtes à exécuter ...

Celui-ci vous montrera combien de fichiers TempDB possède et où ils se trouvent.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Celui-ci vous montrera combien de processeurs et de cœurs vous avez.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Celui-ci vous montrera combien de nœuds NUMA et de cœurs par nœud NUMA vous avez.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Celui-ci vous montrera quelles pages connaissent des attentes dans TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Voici un article qui approfondit un peu plus le problème de contention des pages.

OK, alors maintenant la partie philosophie ... :-)

Pour moi, si je suis sur un système SMP , je veux seulement autant de fichiers que la moitié du nombre total de cœurs .

Si je suis sur un système NUMA , je veux seulement autant de fichiers que de cœurs par nœud NUMA .

Cependant, je vois rarement une amélioration pour avoir plus de quatre fichiers pour TempDB. Donc, je commence généralement par quatre et surveille les conflits comme expliqué dans l'article auquel j'ai lié.

Si je continue de voir des problèmes, j'en ajouterais deux autres. Vérifiez à nouveau, ajoutez-en plus et répétez jusqu'à ce que le conflit disparaisse.