web-dev-qa-db-fra.com

Pourquoi une simple boucle entraîne-t-elle des attentes ASYNC_NETWORK_IO?

Le T-SQL suivant prend environ 25 secondes sur ma machine avec SSMS v17.9:

DECLARE @outer_loop INT = 0,
@big_string_for_u VARCHAR(8000);

SET NOCOUNT ON;

WHILE @outer_loop < 50000000
BEGIN
    SET @big_string_for_u = 'ZZZZZZZZZZ';
    SET @outer_loop = @outer_loop + 1;
END;

Il cumule 532 ms d'attente de ASYNC_NETWORK_IO Selon sys.dm_exec_session_wait_stats Et sys.dm_os_wait_stats. Le temps d'attente total augmente à mesure que le nombre d'itérations de boucle augmente. En utilisant l'événement étendu wait_completed, Je peux voir que l'attente se produit environ toutes les 43 ms à quelques exceptions près:

wait table

De plus, je peux obtenir les piles d'appels qui se produisent juste avant l'attente de ASYNC_NETWORK_IO:

sqldk.dll!SOS_DispatcherBase::GetTrack+0x7f6c
sqldk.dll!SOS_Scheduler::PromotePendingTask+0x204
sqldk.dll!SOS_Task::PostWait+0x5f
sqldk.dll!SOS_Scheduler::Suspend+0xb15
sqllang.dll!CSECCNGProvider::GetBCryptHandleFromAlgID+0xf6af
sqllang.dll!CSECCNGProvider::GetBCryptHandleFromAlgID+0xf44c
sqllang.dll!SNIPacketRelease+0xd63
sqllang.dll!SNIPacketRelease+0x2097
sqllang.dll!SNIPacketRelease+0x1f99
sqllang.dll!SNIPacketRelease+0x18fe
sqllang.dll!CAutoExecuteAsContext::Restore+0x52d
sqllang.dll!CSQLSource::Execute+0x151b
sqllang.dll!CSQLSource::Execute+0xe13
sqllang.dll!CSQLSource::Execute+0x474
sqllang.dll!SNIPacketRelease+0x165d
sqllang.dll!CValOdsRow::CValOdsRow+0xa92
sqllang.dll!CValOdsRow::CValOdsRow+0x883
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x15d
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x638
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x2ad
sqldk.dll!SystemThread::MakeMiniSOSThread+0xdf8
sqldk.dll!SystemThread::MakeMiniSOSThread+0xf00
sqldk.dll!SystemThread::MakeMiniSOSThread+0x667
sqldk.dll!SystemThread::MakeMiniSOSThread+0xbb9

Enfin, j'ai remarqué que SSMS utilise une quantité surprenante de CPU pendant la boucle (environ la moitié d'un cœur en moyenne). Je ne peux pas comprendre ce que SSMS fait pendant ce temps.

Pourquoi une simple boucle provoque-t-elle que ASYNC_NETWORK_IO Attend lorsqu'elle est exécutée via SSMS? La seule sortie que je semble obtenir du client à partir de cette exécution de requête est la "Commande terminée avec succès". message.

sql-serverssms
19
Joe Obbish

documentation pour SET NOCOUNT dit:

SET NOCOUNT ON empêche l'envoi de DONE_IN_PROC messages au client pour chaque instruction d'une procédure stockée. Pour les procédures stockées qui contiennent plusieurs instructions qui ne renvoient pas beaucoup de données réelles, ou pour les procédures qui contiennent des boucles Transact-SQL, définissez SET NOCOUNT à ON peut améliorer considérablement les performances, car le trafic réseau est considérablement réduit.

Vous n'exécutez pas les instructions dans une procédure stockée, donc SQL Server envoie DONE jetons (code 0xFD) pour indiquer l'état d'achèvement de chaque instruction SQL. Ces messages sont différés et envoyés de manière asynchrone lorsque le paquet réseau est plein. Lorsque le client ne consomme pas assez rapidement les paquets réseau, les tampons se remplissent finalement et l'opération devient bloquante pour SQL Server, générant le ASYNC_NETWORK_IO attend.

Notez que les jetons DONE sont différents de DONEINPROC (code 0xFF) comme le note la documentation:

  • Un jeton DONE est renvoyé pour chaque instruction SQL du lot SQL, à l'exception des déclarations de variables.

  • Pour l'exécution des instructions SQL dans les procédures stockées, les jetons DONEPROC et DONEINPROC sont utilisés à la place des jetons DONE.

Vous verrez une réduction spectaculaire de ASYNC_NETWORK_IO attend en utilisant:

CREATE PROCEDURE #P AS
SET NOCOUNT ON;

DECLARE
    @outer_loop integer = 0,
    @big_string_for_u varchar(8000);


WHILE @outer_loop < 5000000
BEGIN
    SET @big_string_for_u = 'ZZZZZZZZZZ';
    SET @outer_loop = @outer_loop + 1;
END;
GO
EXECUTE dbo.#P;

Vous pouvez également utiliser sys.sp_executesql pour obtenir le même résultat.

Exemple de trace de pile capturée comme un ASYNC_NETWORK_IO l'attente commence:

sending a packet

Un exemple de paquet TDS comme vu dans la fonction en ligne sqllang!srv_completioncode_ex<1> avait les 13 octets suivants:

fd 01 00 c1 00 01 00 00 00 00 00 00 00

Qui décode pour:

  • TokenType = 0xfd DONE_TOKEN
  • État = 0x0001 DONE_MORE
  • CurCmd = 0x00c1 (193)
  • DoneRowCount = 0x00000001 (1)

En fin de compte, le nombre de ASYNC_NETWORK_IO les attentes dépendent du client et du pilote, et de ce qu'il fait, le cas échéant, avec tous les messages DONE. Test avec une boucle 1/10 de la taille donnée dans la question (5 000 000 itérations de boucle) J'ai trouvé que SSMS fonctionnait pendant environ 4 secondes avec 200-300 ms d'attente. sqlcmd a fonctionné pendant 2-3 secondes avec des attentes de ms à un chiffre; osql environ le même temps d'exécution avec environ 10 ms d'attente.

Le pire client de loin pour ce test était Azure Data Studio. Il a fonctionné pendant près de 6 heures:

ADS

31
Paul White 9