web-dev-qa-db-ja.com

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

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

async_network_io wait types

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

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

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

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

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時間がほとんどなく、読み取りが少ないクエリは、完了するまでに長い時間がかかるのはなぜですか。アプリケーションが何百万行も要求していて、結果を十分に速く消費できなかったわけではありません。

12
Tom V - try topanswers.xyz

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

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

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

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

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

詳細については、 このページ を参照してください

6
Monte Chavis