Exchange 2003 メール ストアの物理ディスク キューが高すぎる

Exchange 2003 メール ストアの物理ディスク キューが高すぎる

私は 10 台の 7200 SATA rpm ディスクを備えた RAID 10 アレイを持っています。業務時間中のディスク キューの長さは平均で約 100 です。セットアップは次のようになります。

  1. アレイには 95 個のアクティブなメールボックスを持つ 1 つのメール ストアがあります。(これは唯一のもので、ログやシステム ファイルはありません)
  2. 平均メールボックスサイズは約 400 MB
  3. アレイは、RAIDストライプに整列された1.3 TBの大きなパーティションです。
  4. メールストアは約 48 GB です ( etm ファイルと stm ファイルの両方)
  5. メールストアがデフラグされました
  6. トランザクションログは、平均ディスクキューが1未満の別のアレイにあります。

これは高すぎるように思えますか? もしそうなら、この設定に何か問題があるように見えますか? 他のカウンターも調べたほうがよいでしょうか?

コメント後の更新:

  1. アレイ自体は問題ないようだ。先週は数日間のジェットストレステストで良い結果が得られた。
  2. アレイ上にページファイルはありません :-)
  3. Symantec の AV ソフトウェアがあります。タスク マネージャーで確認すると、IO 読み取りと IO 書き込みの上位 2 つは conduit.exe (Symantec Anti Spam/Virus) と store.exe です。conduit は 1,800 万回の読み取りと 2,500 万回の書き込み、store は 1 億 4,400 万回の読み取りと 900 万回の書き込みです。現時点では、ゲートウェイ サーバーがあるので、バックエンド サーバーから AV を削除することを検討しています。

答え1

それは「かなり高い」というレベルを超えています。非常に、驚くほど高いです。私は、ディスク キューがはるかに低い、古ぼけた 7,200 RPM Ultra160 SCSI ドライブ上の RAID-5 で稼働している、その 2 倍以上のメールボックスを持つボックスを持っています。

Exchange 以外の何かがディスクをスラッシングしています。Perfmon を開いて、各プロセスの「プロセス」オブジェクトの「IO データ操作 / 秒」をグラフ化し、どのプロセスが大量の IO を引き起こしているかを確認します。

編集:

Jim B へのコメントでリンクした記事には、確認する価値のある非常に優れたパフォーマンス カウンターがいくつかあります。また、それらのディスクに仮想メモリ ページファイルを配置して、過剰なページングが発生しているかどうかも気になります。

この記事と Entourage に関するリンク記事を読んで、これらのクライアントに関連する問題が発生しているのではないかという疑念が少しあります。ただし、Outlook Anywhere (別名 RPC over HTTP) では、Entourage と同じ問題は発生しません。これはまったく別の問題です (MAPI over HTTP と、Entourage クライアントが使用する WebDAV の違い)。

質問しなくても実行されますが、イベント ログに何か異常は見られますか?

更新後に編集します:

読み取り/書き込みの合計数は、実際に探しているものではありません。実際に探しているのは、間隔ごとの読み取り/書き込みの差分です。Perfmon を開いて、デフォルトのカウンターをクリアし、次のカウンターをいくつか追加します。

  • 物体:プロセス -カウンター:データ操作数/秒 -実例:コンジット.exe
  • 物体:プロセス -カウンター:データ操作数/秒 -実例:ストア.exe

また、以下もご覧ください。Microsoft Exchange ユーザー モニター(使い方についての素敵な記事がこちらにありますhttp://www.msexchange.org/tutorials/Microsoft-Exchange-Server-User-Monitor.html)。これでは WebDAV セッションは表示されませんが、従来の MAPI ベースのユーザーが何をしているのかがわかるかもしれません。

答え2

うわあ!これは非常に高いですね。平均キューの長さは物理ディスク スピンドルの数と同じかそれ以下である必要があるため、マシンは本来よりも 1 桁ほど多くスラッシングしています。このリンクディスク I/O を引き起こすすべての Exchange 操作のリストがありますので、Sam と Evan の提案に従って、これらのアクティビティ (メール ループなど) が異常に多く発生していないことを確認する必要があります。

答え3

これはかなり高いですね。何か AV ソフトウェアを使っていますか? また、\process*\io データ操作/秒も見てください。これで、IO の原因が store.exe か、それとも他の何かかがわかるはずです。store.exe の場合は、メールボックスをスキャンしている何かがあると思われます。

答え4

こちらもご覧くださいプロセスモニターは、ディスク上の各アクセスを個別に記録します。Exchange 以外の何かがディスクを使用している場合、ProcMon のディスク アクセス リストがすぐにいっぱいになります。

搭載されている RAM の容量については触れられていませんが、記載されている仕様から、おそらく十分な容量が搭載されていることがわかります。2 GB 未満で実行している場合は、マシンがページ ファイルをヒットすることでこのような動作が発生する可能性があります。タスク マネージャーで使用されている RAM の容量が、サーバーにインストールされている物理メモリの容量よりも少ないことを確認してください。

関連情報