ASYNC_NETWORK_IO wait type è qualcosa di cui preoccuparsi?

Esaminando l'elenco delle procedure memorizzate che richiedono molto tempo per essere eseguite, ci si distingue come causa della maggior attesa. Tuttavia, la maggior parte dell'attesa (81%) è ASYNC_NETWORK_IO e so perché: la procedura memorizzata trasferisce circa 400 MB di informazioni.

Nella documentazione, afferma che la causa di ASYNC_NETWORK_IO è che il client non può tenere il passo con il flusso di dati e questo è probabilmente vero. Non sono sicuro di come tenere il client al passo con tutto ciò che fa è chiamare la procedura memorizzata tramite un ADO.NET e quindi elabora solo il set di dati.

Quindi, date queste informazioni, dovrei preoccuparmi del tipo di attesa ASYNC_NETWORK_IO per questa procedura? Ha effettivamente un effetto sulle prestazioni del server?

Ulteriori informazioni:

Sono sul service pack 2 di SQL Server 2005.
L'app client si trova sulla stessa scatola di SQL Server (lo so, lo so ... ma non posso farci nulla).

— AngryHacker
fonte

Il modo migliore per pensare a questo tipo di attesa è che non ci sia nulla nella tua query che lo causi: restituisce i dati al client. Vedrai anche che molti di voi hanno tabelle collegate in Access. Una possibilità a seconda dell'app client è quella di suddividere i dati in blocchi più piccoli o restituire solo meno dati. Se questa non è un'opzione, probabilmente sarai limitato a ciò che puoi fare per ridurla.

— JNK,

L'app client si sta connettendo utilizzando la memoria condivisa o TCP / IP? L'app client e SQL Server condividono lo stesso set di core del processore o stai usando una tecnica di mascheramento di affinità per separarli?

— Jon Seigel,

È il tipo di connessione predefinito, niente di speciale, quindi utilizza la memoria condivisa. Entrambe le app usano lo stesso set di core: non c'è affinità.

— AngryHacker,

La tua memoria è SAN o locale?

— Eric Higgins,

@EricHiggins Solo un set locale di dischi rigidi RAID.

— AngryHacker,

Come hai detto, questo tipo di attesa indica che l'applicazione non è al passo con SQL Server. Ciò che significa veramente è che SQL Server non è in grado di inviare i dati sulla rete più velocemente che vorrebbe.

Ci possono essere due cause sottostanti:

L'app è scritta in modo inefficiente e non elabora le righe abbastanza velocemente.
La rete è al massimo.

Se l'applicazione stessa è troppo lenta, non vi sarà alcun impatto significativo o nullo sulle prestazioni di altre query. Se d'altra parte la pipe è troppo piccola, anche altre query non possono inviare i loro risultati e devono aspettare.

In quest'ultimo caso, tuttavia, avresti tutte le connessioni in attesa su ASYNC_NETWORK_IO. Dovresti essere in grado di vedere chiaramente quell'impatto.

— Sebastian Meine
fonte

Per il punto elenco 1. Il recupero dei dati avviene tramite ADO.NET utilizzando il codice standard: var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); quindi non sono sicuro di cosa potrebbe essere esattamente lento.

— AngryHacker

Per punto elenco 2. L'applicazione si trova nella stessa casella di SQL e la connessione avviene tramite il metodo della memoria condivisa. Quindi teoricamente dovrebbe essere super veloce.

— AngryHacker