Perché si verificano i tipi di attesa async_network_io?

La scorsa settimana è successo qualcosa di strano sul nostro database. All'improvviso, l'applicazione è stata bloccata per i nostri utenti che non sono stati in grado di salvare nuove entità, ecc. Dopo aver esaminato Activity Monitor di SQL Server (2008 con modalità di compatibilità 2005) ho visto le seguenti tre voci:

Dopo qualche tempo, gli utenti hanno avuto un timeout di connessione. Quando ho ucciso il processo 64, hanno potuto salvare di nuovo normalmente.

Il problema è che le entità che hanno tentato di salvare durante il blocco sono state inserite nel DB più di una volta (fino a 3 volte) anche se esiste un codice che dovrebbe impedire che ciò accada (colonna numerica che deve essere unica ma senza vincoli ... il controllo avviene nel codice).

Usiamo Entity Framework 6.0.

• Qualcuno di voi sa perché e quando si verificano questi tipi di attesa ASYNC_NETWORK_IO e come evitarli?
• E cosa significano esattamente?

ASYNC_NETWORK_IOin qualche modo indica che l'applicazione client non sta elaborando i risultati alla stessa velocità con cui SQL Server li alimenta. Ciò potrebbe essere causato da un problema con l'applicazione client o con la connessione di rete tra il server e l'applicazione client.

Si prega di fare riferimento a un post di Thomas LaRock

L'attesa ASYNC_NETWORK_IO indica che si sta verificando uno dei due scenari. Il primo scenario è che la sessione (ovvero SPID) è in attesa che l'applicazione client elabori il set di risultati e invii un segnale a SQL Server che è pronto per elaborare più dati. Il secondo è che potrebbe esserci un problema di prestazioni della rete.

o questo post di Joe Sack

Come forse già saprai, i tipi di attesa ASYNC_NETWORK_IO (visti in SQL 2005) e NETWORKIO (visti in SQL 2000) sono associati a un'applicazione chiamante che non elabora i risultati abbastanza rapidamente da SQL Server o è associata a un problema di prestazioni della rete .

Dal momento che stai usando entity framework questo post di Brent Ozar potrebbe essere utile

Osservando le statistiche di attesa per queste query, ho visto che c'erano molti ASYNC_NETWORK_IO - spesso 1000+ millisecondi. Neanche questo aveva senso! Come può una query con così poco tempo CPU e così poche letture impiegare così tanto tempo per essere completata? Non è come se l'applicazione richiedesse milioni di righe e non potesse consumare i risultati abbastanza velocemente.

Ci sono alcune idee sbagliate riguardo al tipo di attesa ASYNC_NETWORK_IO, principalmente a causa del nome che indica il problema di rete, ma è abbastanza raro il motivo di questo tipo di attesa.

Troppe attese ASYNC_NETWORK_IO potrebbero verificarsi in due scenari:

1. La sessione deve attendere che l'applicazione client elabori i dati ricevuti da SQL Server per inviare il segnale a SQL Server che può accettare nuovi dati per l'elaborazione. Questo è uno scenario comune che potrebbe riflettere una cattiva progettazione dell'applicazione ed è la causa più frequente di valori eccessivi del tipo di attesa ASYNC_NETWORK_IO.

   Ciò implica l'analisi dell'applicazione che causa i valori eccessivi del tipo di attesa ASYNC_NETWORK_IO e spesso il coordinamento con gli sviluppatori dell'applicazione che l'hanno creata.

2. La larghezza di banda della rete è al massimo. Una Ethernet ostruita causerà la lenta trasmissione dei dati avanti e indietro dall'applicazione. Questo, di per sé, degraderà l'efficienza dell'applicazione.

Molti più dettagli sono disponibili in questa pagina