Pourquoi les requêtes SQL Server n'utilisent-elles pas plus de 7 Mo / s d'E / S disque

11

J'ai un SSD qui, à l'aide du test IOmeter, affiche des performances supérieures à 200 Mo / s. Cependant, lorsque j'exécute une requête SQL à partir d'une machine locale, le moniteur de ressources Windows n'affiche jamais les E / S de disque au-dessus de 7 Mo / s. Cela est vrai même pour les requêtes qui prennent plus de 2 minutes à s'exécuter. Quel pourrait être le goulot d'étranglement du fait qu'il n'utilise que 7 Mo / s du SSD?

Je suis entrain de courir:

  • Windows Server 2012 Standard
  • SQL Server 2008 R2
  • Intel i7 3820
  • 32 Go de RAM
  • sandisk SSD
sql-server sql-server-2008-r2 hardware Dean MacGregor
la source
2
Peut-être que les données sont déjà dans la RAM et qu'aucun accès au disque n'est nécessaire?
gbn
1
@DeanMacGregor - Comment consommez-vous les résultats? Si dans SSMS, si vous essayez l'option de rejeter les résultats. Cela change-t-il quelque chose? Vous pouvez également essayer de regarder sys.dm_os_waiting_taskspendant l'exécution de la requête pour voir s'il existe d'autres types d'attente.
Martin Smith
1
Est-ce que les 200 Mo / s pour les lectures à accès aléatoire (lectures aléatoires pour les blocs de 4 Ko)? Je suppose que c'est ce que ferait généralement une base de données. La requête écrit-elle sur le disque (fichier temporaire, jeu de résultats temporaire ou table)?
2
@DeanMacGregor - Donc, pour retirer cela de l'équation, vous pouvez affecter le résultat à des variables scalaires (exemple de requête). DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. Aucun résultat n'est donc renvoyé au client, mais le plan et les E / S seront toujours les mêmes.
Martin Smith
4
Supposons que vous interprétez ASYNC_NETWORK_IO attend pour signifier que le problème est lié au réseau? Ce n'est généralement pas le cas. Il est très probable que @MartinSmith a suggéré (deux fois) que SSMS ou l'application que vous utilisez ne consomment pas les résultats aussi rapidement que SQL les sert. Suivez l'une des méthodes suggérées pour omettre la consommation des lignes et vous obtiendrez une image vraie (r) du débit d'E / S maximal.
Mark Storey-Smith

Réponses:

7

De la chaîne des commentaires, il semble que vous interprétiez les ASYNC_NETWORK_IOattentes pour signifier que le problème est lié au réseau. Ce n'est généralement pas le cas.

Comme @MartinSmith a laissé entendre (deux fois) que l'explication la plus probable est SSMS ou l'application que vous utilisez ne consomme pas les résultats aussi rapidement que SQL Server les sert. Suivez l'une des méthodes suggérées pour supprimer la consommation des lignes de votre mesure et vous obtiendrez une image vraie (r) du débit d'E / S maximal:

Au cas où vous ne l'auriez pas déjà fait, vous devrez évidemment vous DBCC DROPCLEANBUFFERSassurer que les données sont réellement lues à partir du disque plutôt que du cache de tampon. Les mises en garde habituelles de "sur test uniquement, ne le faites pas dans un environnement actif", etc. s'appliquent.

Mettant l'accent sur quelques-uns de vos autres commentaires:

Lors de l'exécution d'une requête qui renvoie 9 millions de lignes, l'utilisation du processeur restera autour de 13%, dont 9% attribuables à sqlserver ... ne retournerait-il pas les résultats plus rapidement que 3 minutes si toutes les données étaient en RAM?

Que testons-nous exactement ici, comment et pourquoi? Si votre requête de 9 millions de lignes est autre chose qu'un, SELECT * FROM dbo.SomeTablealors il y a 1001 facteurs qui entrent en jeu, autre que le débit d'E / S brut.

Votre Intel I7-3820 est un processeur à 4 cœurs. Si votre requête de test ne génère pas de plan parallèle, je serais surpris si vous pouviez supprimer plus de 20% d'utilisation du processeur du système.

Les 3 minutes pour renvoyer 9 millions de lignes sont très suspectes et suggèrent que nous n'obtenons pas une image complète de vos tests. Je suppose que c'est un cas de plan de requête sous-optimal (non parallèle), bourré d'opérateurs de boucle imbriquée tirant des millions de lignes, c'est-à-dire pas seulement une seule table SELECTpour vérifier la consommation d'E / S.

Je suggère:

  1. SELECT *pour tester uniquement IO via SQL Server.
  2. Nouvelle question avec le plan d'exécution de votre requête si vous voulez savoir pourquoi cela ne sature pas les IO.
Mark Storey-Smith
la source
En fait, il suffit de sélectionner * dans dbo.sometable. Désolé de ne pas l'avoir mentionné plus tôt; ce que je voulais dire, c'est que je pouvais exécuter cette requête sur n'importe quelle table. La genèse de ma question était que j'ai remarqué que mon E / S sur disque était bien inférieure à ce que j'attendais même à partir d'une simple requête «donnez-moi beaucoup de données». Ma principale préoccupation était que si les E / S sur disque étaient si faibles, les performances pourraient être améliorées si la cause première de la faible E / S sur disque était éliminée.
Dean MacGregor