WinDevで開発された社内アプリケーションがあり、Windows Server 2008R2で実行されているMicrosoft SQL Server 2012 SP2(ビルド11.0.5058)データベースを使用しています。
パフォーマンスの問題が発生しています。同時に、アクティビティモニターは「ネットワークI/O」タイプの膨大な数の待機を表示します。この場合、「巨大」は、稼働時間が6日未満のサーバーの累積待機時間700万秒です。
ネットワーク接続自体は問題なく、サーバーは10Gで接続されていますが、クライアントは1Gbで接続された物理デスクトップまたは10Gでリモートデスクトップサーバーのいずれかです。ネットワーク監視では、リンクの飽和やその他のネットワークの問題は示されていません。 CPU、RAMおよびディスクI/Oも問題ありません。
私がネットワークI/O待機について読んだことから、それはクライアントによって消費されないクエリによって返されたレコードに関連しています。だから私は問題がアプリケーションにあると思う傾向がありますが、開発者にこれを調査させるのに苦労します(彼らがそれを行うことを望んでいないというわけではありませんが、彼らは非常に忙しく、根本についての手掛かりがないようです)原因とそれを解決する方法)
だから質問:
パフォーマンスの問題はそれらのネットワークI/O待機に関連していると私は正しく考えていますか?
原因を特定するために、開発チームにどのような手掛かりを提供できますか?
アプリケーションの修正とは別に、SQL Server自体で問題を緩和するために実行できる微調整はありますか?
それはバックアップである可能性があります ある場合、あなたができることの全体ではありません ハードウェアのアップグレードを含まない(おそらく1 Gb iSCSIはそれほど素晴らしいアイデアではなかったかもしれません...)
クライアント側のコードがデータRBARを消費する(入ってくるすべての行のforeachループを考える)か、またはたくさんの行を要求する一度に( ページングクエリ が役立ちます)。
それは完全に別のものである可能性があります!
サーバーが最も待機しているものを知るには、 firstresponderkit.org -完全な開示、私はこのオープンソースプロジェクトに貢献しますsp_BlitzFirst
(または、一体すべてをつかむ)。
このコマンドを実行して、起動後の全体の待機統計を確認できます。
EXEC sp_BlitzFirst @SinceStartup = 1
または、スローダウン中の待機統計のサンプルを取得します。
EXEC sp_BlitzFirst @Seconds = 30, @ExpertMode = 1
お役に立てれば!
待機を含め、アプリケーションからのクエリを監視し(拡張イベントでこれを行うことができます)、sqlcmdまたはSSMSから同じクエリを実行して(グリッドへの結果ではありません)、比較します。これは、結果を十分に速く消費できないアプリケーションと、データを十分に速く送信できないネットワークを区別するのに役立ちます。
アクティビティモニターの「ネットワークI/O」がASYNC_NETWORK_IOにのみマップされているかどうかはわかりませんが、あなたのようなネットワークでは、待機はクライアントの消費の遅延によってのみ引き起こされます。