なぜasync_network_ioの待機タイプが発生するのですか？

先週、データベースで奇妙なことが起こりました。新しいエンティティなどを保存できなかったユーザーに対して、アプリケーションが突然ブロックされました。SQLServerのアクティビティモニター（2008と互換モード2005）を確認した後、次の3つのエントリが表示されました。

しばらくすると、ユーザーは接続タイムアウトを取得しました。プロセス64を強制終了したとき、彼らは再び正常に保存できました。

問題は、ブロック中に保存しようとしたエンティティがDBに複数回（最大3回）挿入されたことですが、これを防ぐためのコード（数値列は一意でなければならないが制約なし）があるはずです...チェックはコードで行われます）。

Entity Framework 6.0を使用しています。

• これらのASYNC_NETWORK_IO待機タイプが発生する理由とタイミング、およびそれらを回避する方法を知っている人はいますか？
• そして、それらは正確にはどういう意味ですか？

ASYNC_NETWORK_IOどういうわけか、クライアントアプリケーションがSQL Serverにフィードするほど速く結果を処理していないことを示しています。これは、クライアントアプリケーションの問題、またはサーバーとクライアントアプリケーション間のネットワーク接続の問題が原因である可能性があります。

Thomas LaRockの投稿を参照してください

ASYNC_NETWORK_IO待機は、2つのシナリオのいずれかが発生していることを示します。最初のシナリオは、セッション（つまりSPID）がクライアントアプリケーションが結果セットを処理し、さらにデータを処理する準備ができていることを示す信号をSQL Serverに送信するのを待っていることです。2つ目は、ネットワークのパフォーマンスに問題がある可能性があることです。

またはJoe Sackによるこの投稿

すでにお気づきかもしれませんが、ASYNC_NETWORK_IO（SQL 2005に表示されます）およびNETWORKIO（SQL 2000に表示されます）の待機タイプは、SQL Serverからの結果を十分に迅速に処理していないか、ネットワークパフォーマンスの問題に関連付けられている呼び出し側アプリケーションに関連付けられています。

entity framework Brent Ozarのこの投稿を使用しているので、役に立つかもしれません。

これらのクエリの待機統計を見ると、ASYNC_NETWORK_IOがたくさんあることがわかりました。多くの場合、1000ミリ秒以上です。それも意味がありませんでした！CPU時間と読み取りがほとんどないクエリで、完了までに長い時間がかかるのはなぜですか。アプリケーションが何百万もの行を要求していて、結果を十分に速く消費できなかったわけではありません。

ASYNC_NETWORK_IO待機タイプについては、主にネットワークの問題を示す名前が原因で誤解されていますが、この待機タイプの理由はまれです。

次の2つのシナリオでは、過度のASYNC_NETWORK_IO待機が発生する可能性があります。

1. セッションは、クライアントアプリケーションがSQL Serverから受信したデータを処理して、処理のために新しいデータを受け入れることができるという信号をSQL Serverに送信するのを待つ必要があります。これは、不適切なアプリケーション設計を反映している可能性のある一般的なシナリオであり、ASYNC_NETWORK_IOの待機タイプの値が過剰になる最も一般的な原因です。

   これには、過剰なASYNC_NETWORK_IO待機タイプの値を引き起こしているアプリケーションを調査し、それを作成したアプリケーション開発者と調整することが含まれます。

2. ネットワーク帯域幅が限界に達しました。イーサネットが詰まっていると、アプリケーションとの間のデータ転送が遅くなります。これ自体は、アプリケーションの効率を低下させます。

より多くの詳細はこのページで見つけることができます