Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Cosa pensare del tipo di attesa ASYNC NETWORK IO?

Hai già visto questo tipo di attesa, vero? Bene, è sicuramente un tipo di attesa che ha causato molta confusione. L'attenzione immediata è generalmente data alla parola "RETE" ma il più delle volte non ha nulla a che fare con la rete!
Il tipo di attesa ASYNC_NETWORK_IO genererà due tipi di sintomi, il primo è che il carico di lavoro della sessione è in attesa che l'applicazione client corrispondente riconosca/elabora un determinato set di dati e fa sapere a SQL Server che è pronto per elaborare/riconoscere più dati. Il secondo sintomo è che potrebbe esserci un problema di prestazioni nella rete tra l'applicazione e l'istanza del database. Dietro le quinte, SQL Server mantiene i dati contenuti in un buffer di output finché non viene ricevuto un riconoscimento dal client che determina se il consumo di dati è completare. ASYNC_NETWORK_IO è un segno rivelatore che l'applicazione non ha efficienza nella lettura dei dati richiesti dal suo database back-end. La rete sottostante potrebbe anche presentare problemi che possono produrre attese più lunghe durante l'elaborazione dei dati e i segnali vengono inviati dal client al server.

Le possibili cause di questa attesa includono:

  • Il codice dell'applicazione non recupera correttamente i dati
  • Grandi set di dati richiesti dal cliente
  • Filtraggio eccessivo dei dati che si verifica sul lato client o applicazione
  • Dispositivi di rete mal configurati come schede, switch, ecc.

Ad alto livello, un DBA potrebbe voler controllare queste cose:

  • Rivedi il codice dell'applicazione e assicurati che l'applicazione legga i dati in modo corretto/efficiente. Ad esempio, la tua applicazione sta ritirando un numero elevato di righe solo per elaborare una riga alla volta?
  • Filtraggio dati non necessario lato client/applicazione? Limita le righe.

Se gli elementi precedenti vengono verificati, ma i problemi con ASYNC_NETWORK_IO rimangono, ciò potrebbe essere dovuto alla rete. Ecco alcune cose che puoi esaminare:

  • Ispeziona il collegamento di comunicazione di rete tra l'applicazione e l'istanza del database back-end e verifica la larghezza di banda.
  • Utilizza sys.dm_io_virtual_file_stats per testare la latenza generale della rete dovuta al carico o alla distanza
  • Esaminare la configurazione della scheda di rete sul server del database per assicurarsi che non manchino errori e/o impostazioni.

Il ASYNC_NETWORK_IO WAIT TYPE potrebbe effettivamente essere un problema relativo alla rete, ma spesso potrebbe essere dovuto a un'applicazione client che non elabora i suoi dati in modo efficiente. Se quest'ultimo è davvero il caso, allora questa è un'opportunità per DBAS e sviluppatori di lavorare insieme per capire di cosa ha veramente bisogno l'applicazione nel migliore interesse delle prestazioni del database back-end. Garantire che la maggior parte del filtraggio dei dati venga eseguito all'interno di SQL Server è una procedura consigliata che può essere ottenuta tramite viste o condizioni più specifiche nella sintassi della transazione.

Sebbene ci siano molti modi per monitorare e misurare l'attesa ASYNC_NETWORK_IO attraverso l'uso di DMV catalogati ed eventi estesi in SQL Server, incoraggiamo la nostra community di DBA di SQL Server a esaminare Spotlight Cloud di Quest che fornisce efficienza nel determinare la causa principale del tipo di attesa consumo in un arco di tempo storico.