この待機タイプは以前に見たことがありますね。まあ、それは確かに多くの混乱を引き起こしている待機タイプです。すぐに焦点を当てるのは一般的に「ネットワーク」という言葉ですが、多くの場合、それはネットワークとは何の関係もありません。
ASYNC_NETWORK_IO待機タイプは通常2種類の症状を引き起こします。最初の症状は、対応するクライアントアプリケーションが特定のデータセットを確認/処理するのを待機し、SQLServerにさらにデータを処理/確認する準備ができていることを通知します。 2番目の症状は、アプリケーションとデータベースインスタンス間のネットワークにパフォーマンスの問題がある可能性があることです。バックグラウンドでは、SQL Serverは、データの消費が完了。 ASYNC_NETWORK_IOは、アプリケーションがバックエンドデータベースから必要なデータを読み取る効率が低いことを示す兆候です。基盤となるネットワークにも問題があり、データが処理され、信号がクライアントからサーバーに返送されている間、待機時間が長くなる可能性があります。
この待機の考えられる原因は次のとおりです。
- アプリケーションコードがデータを正しく取得しない
- クライアントから要求されている大規模なデータセット
- クライアント側またはアプリケーション側で発生するデータの過剰なフィルタリング
- カード、スイッチなどの不適切に構成されたネットワークデバイス
大まかに言えば、DBAは次のことを確認する必要があります。
- アプリケーションコードを確認し、アプリケーションがデータを正しく/効率的に読み取っていることを確認します。たとえば、アプリケーションは一度に1つの行を処理するためだけに、多数の行をプルバックしていますか？
- クライアント/アプリケーション側での不要なデータフィルタリング？行を制限します。
上記の項目をチェックアウトしても、ASYNC_NETWORK_IOの問題が残っている場合は、ネットワークが原因である可能性があります。調べることができるものは次のとおりです。
- アプリケーションとバックエンドデータベースインスタンス間のネットワーク通信リンクを調べて、帯域幅を確認します。
- sys.dm_io_virtual_file_statsを使用して、負荷または距離による一般的な遅延についてネットワークをテストします
- データベースサーバーのNIC構成を調べて、障害や設定が欠落していないことを確認します。
ASYNC_NETWORK_IO WAIT TYPEは確かにネットワーク関連の問題である可能性がありますが、多くの場合、データを効率的に処理していないクライアントアプリケーションが原因である可能性があります。後者が実際に当てはまる場合、これはDBASと開発者が協力して、バックエンドデータベースのパフォーマンスの最大の利益のためにアプリケーションが本当に必要とするものを理解する機会です。ほとんどのデータフィルタリングがSQLServer内で実行されるようにすることは、ビューを介して、またはトランザクション構文のより具体的なwhere条件を介して達成できるベストプラクティスです。
SQL Serverでカタログ化されたDMVと拡張イベントを使用してASYNC_NETWORK_IO待機を監視および測定する方法は多数ありますが、SQL Server DBAのコミュニティでは、待機タイプの根本原因を効率的に特定できるQuestのSpotlightCloudを確認することをお勧めします。過去の期間にわたる消費。