2

Service Broker を適切に使用して、最大限のパフォーマンスを引き出しているかどうかを判断しようとしています。私たちは SB の会話と処理を微調整しており、3000/分から 8000/分になりましたが、CPU は 100% で一定に保たれています。さらに、SB キューが空のままになる日もありますが、同様のトラフィックの日にキューが 500k バックアップされることがあります。

マシンはクアッド クワッド (16 コア)、HT なし、32 GB RAM、26 GB が SQL Server に割り当てられ、AWE が有効になっています。

SQL Server 2008 SP1 (CU なし)、エンタープライズ エディション。Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) 2009 年 3 月 29 日 10:11:52 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64 ビット) on Windows NT 6.1 (Build 7600: )

メッセージは Service Broker キューに挿入されます。サービス ブローカー キューはメッセージのグループをプルし、CLR を介してそれらを実行します。CLR は XML を解析し (単純な解析ではありません)、テーブルに挿入します。CLR は、T-SQL コードよりもかなり高速です。

スケジューラごとに平均 35 の実行可能なタスクがあります

毎晩統計/インデックスのメンテナンスを実行します。

パフォーマンスを向上させるために、サーバーの MAXDOP = 1 を設定しました。

SGAM の競合を回避するために、tempdb ファイルの数を 64 に増やしました。TF1118 と組み合わせると、TEMPDB の競合が停止したようです。

sys.dm_os_waiting_tasks を見ると、通常、THREADPOOL で待機しているタスクが最大 60 個あり、その他の種類のタスクはほんの一握りです。

シグナル待機は 70% (リソース待機 = 30%) です。

TokenAndUserPermCache が 20 MB 未満にとどまっていることを確認しました。

sys.dm_os_latch_stats を見ると、1 分間に 40 ～ 200k の BUFFER ラッチが見られます。これはほとんどが sysdesend と、ダイアログを処理するために使用するユーザー テーブルにあります。

また、高い SOS_SCHEDULER_WAIT も見られます。これは、CPU の負荷も示しています。しかし、それは CLR が非常にビジーなためか、それとも Service Broker のオーバーヘッドのためでしょうか? 喜んでコードを提供します。ここに投稿する必要があるものを教えてください。

前もって感謝します。

4

1 に答える 1

2
  1. SSB をローカルのキューイング/処理メカニズムとしてのみ使用していますか? それともリモート メッセージ配信 (x-machine 送信) が関係していますか?
  2. キューの数は？
  3. アクティベーションが関係していますか? はい、いくつの max_queue_readers が関係していると思いますか?
  4. 500k スパイクに関連するものはありますか? それらが排出されるのにどれくらい時間がかかりますか？

暗闇でのショット:

16 CPU のマシンでワーカーを待っている最大 60 のタスク ... 通常は問題ないと考えますが、SSB 処理専用のマシンの場合は少し奇妙です。そのようなマシンでは長時間実行されるタスク (アクティブ化されたジョブ) がほとんどない傾向があるためです。多くの実行時間の短いものには、THREADPOOL 待機が表示される傾向がありません。

于 2011-01-06T21:09:06.410 に答える