web-dev-qa-db-fra.com

Pourquoi ma base de données Azure SQL (SQL Server) est-elle surchargée de données IO pour des périodes à la fois?

J'exécute une base de données Azure SQL sous l'édition S2 (50 DTU). L'utilisation normale du serveur se bloque généralement autour de 10% DTU. Cependant, ce serveur entre régulièrement dans un état où il enverra l'utilisation DTU de la base de données à 85-90% pendant des heures. Puis tout d'un coup, cela revient à l'utilisation normale de 10%.

enter image description here

Les requêtes sur le serveur à partir de l'application semblent toujours fonctionner rapidement pendant cet état surchargé.

Je peux faire évoluer le serveur à partir de S2 => n'importe quoi (S3 par exemple) => S2 et il semble effacer tout état dans lequel il est suspendu. Mais quelques heures plus tard, il répétera à nouveau le même cycle d'état surchargé. Une autre chose étrange que j'ai remarquée est que si j'exécute ce serveur sur un plan S3 (100 DTU) 24/7, je n'ai pas observé ce comportement. Cela ne semble se produire que lorsque j'ai réduit la base de données à un plan S2 (50 DTU). Sur le plan S3, je suis toujours assis à une utilisation de DTU de 5 à 10%. Manifestement sous-utilisé.

J'ai vérifié dans les rapports de requêtes Azure SQL à la recherche de requêtes non fiables, mais je ne vois vraiment rien d'inhabituel et cela montre mes requêtes en utilisant les ressources comme je m'y attendais.

enter image description here

Comme nous pouvons le voir ici cependant, l'utilisation provient entièrement de Data IO. Si je modifie le rapport de performances ici pour afficher les meilleures données IO requêtes par MAX, nous voyons ceci:

enter image description here

L'examen de ces exigences de longue date semble indiquer des mises à jour des statistiques. Pas vraiment quoi que ce soit à partir de mon application. Par exemple, la requête 16302 montre:

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

Mais là encore, le rapport montre également que ces requêtes n'utilisent qu'un faible pourcentage de l'utilisation des données IO sur le serveur (<4%). J'exécute également des mises à jour de statistiques (et des reconstructions d'index) sur l'ensemble de la base de données sur une base hebdomadaire dans le cadre de sa maintenance régulière.

Voici un autre rapport qui affiche les données MAX IO requêtes pour un intervalle de temps qui couvre plusieurs heures uniquement pendant l'incident à forte utilisation des ressources.

enter image description here

Comme nous pouvons le voir, pas vraiment de requêtes rapportant des données importantes IO usage.

J'ai également couru sp_who2 et sp_whoisacive sur la base de données et je ne vois vraiment rien me sauter dessus (même si je dois admettre que je ne suis pas un expert de ces outils).

Comment savoir ce qui se passe ici? Je ne pense pas qu'aucune de mes requêtes d'application soit à blâmer pour cette utilisation des ressources et j'ai l'impression qu'il y a un processus interne en cours d'exécution en arrière-plan sur le serveur qui le tue.

sql-serverazure-sql-databasestatistics
9
kspearrin

Étant donné que pendant les pics, votre activité de journal est minimale, nous pouvons supposer qu'il n'y a pas (ou beaucoup) de DUI en cours.

Vous mentionnez à un moment donné que la pointe n'affecte pas les performances, et à un autre point, elle le fait. Lequel est-ce?

Vous mentionnez également que cela disparaît après une opération de pesage. Cela a du sens car il est analogue à un redémarrage sur site qui tuera efficacement tous les processus, etc.

Dois-je supposer correctement en supposant que cette base de données est accessible à partir du niveau application? Si oui, je soupçonne que votre les connexions ne sont pas fermées correctement. Le garbage collector est censé s'en occuper éventuellement (ce à quoi il ne faut pas se fier), mais j'ai vu cette situation exacte se produire en raison de connexions non fermées du niveau application. Dans notre cas, l'application était tellement occupée que nous avons finalement reçu des erreurs de connexion simultanées, ce qui nous a conduit au problème.

Essayez la requête suivante pendant le pic:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.Host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

Si je ne me trompe pas, vous trouverez tout un tas d'enregistrements renvoyés avec le statut Sleeping, ou pire Running. Si tel est le cas, vous avez des problèmes encore plus importants au niveau de l'application.

Nous pouvons poursuivre le débogage en copiant la base de données, en utilisant la requête suivante (en utilisant le niveau de base pour éviter des coûts excessifs) et en surveillant ce comportement.

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );
1
pimbrouwers