MSMQのメッセージ受信が非常に遅い


8

かなり大規模なMSMQ環境のセットアップがあり、今日停止することにしました。

(すべてがvSphere 4.0 Update 1のVMです)

ネット上のクライアントからデータを受信する8つのWebサーバーがあります。これらのマシンにはすべてMSMQがインストールされており、MSMQメッセージをメインのMSMQサーバーに送信するだけです。メッセージは現在、送信キューに蓄積されています。これらのマシンは、2 GBのRAMと2つのvCPUを搭載したWindows 2008 Web Editionです。

8つのWebサーバーからメッセージを取得するクラスター化されたMSMQサーバー(Windows Cluster Server)があります。キューに入れることができるデータの量に制限はありません。ハードドライブは50 GBで、空き領域は46 GBです。これらのマシンは、8ギガのRAMと4つのvCPUを備えたWindows 2008 Enterprise Editionです。クラスターには2つのvCPUがありましたが、CPU負荷が100%に達していたため、Windowsクラスターの両方のノードを4つのvCPUに増やしました。

キューからメッセージを読み取って処理する4つのアプリサーバーがあります。

通常、これはすべて完全に機能しますが、今日は機能しません。

今朝はすべてが非常にゆっくりと実行されています。現在、8つのWebサーバーは、最大30万のメッセージを送信キューに保持しています。クラスター化されたサーバーは現在、キューに100万を超えるメッセージを表示します(一部は200kと低い)。

8つのWebサーバーでperfmonを見ると、平均して1秒あたり2つのメッセージが送信されていることがわかります。クラスターのperfmonを見ると、1秒あたり〜7のメッセージがクラスターに入ってくることがわかります。

読み取りを行っているマシンは、それぞれ多くのメッセージを受け取っていません。最速のサービスは毎秒10〜12通のメッセージを受け取り、最も遅いサービスは0または1を示します。

最近の唯一の変更は、フロントエンドWebサーバーの数を4から8に変更したことです。約2週間前に問題なくこれを実行しました。火曜日に、残りの4人がどのように負荷を処理できるかを確認するために、電源を切りました。水曜日に、4台の新しいマシンをオンに戻しました。

クラスター上のディスクのIOが非常に低く、キューイングがない。

安全のために、PowerPathを最新バージョンに更新しましたが、それでも効果はありません。

8つのWebサーバーは1つのvLAN上にあり、クラスター化されたサーバーとアプリサーバーは2つ目のvLAN上にあります。vLAN間にファイアウォールはありません。

また、どのマシンでも、アプリケーションまたはシステムのログには何も役に立ちません。


2
MSMQの読み取りが遅い原因は、実際にはアプリケーションの問題であることがわかりました。キューから読み取ったサービスは、ファイル共有上のものに移動します。ファイル共有に時間がかかるようになり、サービスの実行が遅くなり、キューがバックアップされるようになり、混乱が生じました。どうやら私たちのユーザーベースは計画よりはるかに速く成長し、ファイル共有をホストするSAN上のRAIDグループの1つを使い果たしています。月曜日には、ベンダーとより多くのSANスペースを急いで注文します。
mrdenny、2010

2
監視サーバーがWindows 2003サーバーであり、Windows 2003マシンはクラスター化されたWindows 2008 MSMQキューをリモートで監視できないため、このキューの増加を事前に確認できませんでした。監視サーバーは、3月にアップグレードする予定です。<ため息>
mrdenny、2010

回答:


4

誰かが100万を超えるメッセージを持っていると言うときはいつでも、警報クラクソンが鳴ります!メッセージを管理するには、カーネル(ページプール)メモリが必要です。このような膨大な数のメッセージがある場合、クラスター化されたサーバーで利用可能なものを使い果たしている可能性があります。キュー内のメッセージ数の最適な数はゼロです-基本的に、メッセージが到着するよりも速く処理できることを確認してください。

メッセージを再びオンラインに戻す前に、Webサーバーをシャットダウンしてメッセージのバックログを完全に処理することをお勧めします。

このブログ投稿の参照項目4:http : //blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

乾杯ジョンブレイクウェル(MSFT)


この時点でPSSに電話をかけました。今、彼らからの電話を待っています。メッセージがWebサーバーのキューに流れ込むのを止めました。この時点で、Webサーバー上の送信キューはすべて1ギガの情報で満杯です。クラスタ化されたキューには、それぞれ合計約450万のメッセージがあります。通常、データを非常に迅速に処理するため、非常に少ない数のメッセージをキューに保持します。何かが起こって(何が起こっているのかわからない)、それはすべて地獄に行きました。
mrdenny、2010

ジョン、私をのぞいてくれてありがとう。tmqからの出力に基づいて、それが私の問題だと思います。プールの制限(概算、KBで計算)ページ:制限307,200が397%使用非ページ:制限262,144が49%使用PSSからのコールバックを待つ間、キューのドレインが遅くなります。MVPサミット中にレドモンドにいる場合は、ビールを飲んでください。
mrdenny、2010

@ user34024私たちは最初の問題を見つけました、それは私が上のコメントに入れました。助けてくれてありがとう。
mrdenny、2010

1

私のシステム管理者の1人に聞いたところ、私たちの魔法のポイントは、仮想マシンで最大4台のWebサーバーがMSMQボックスに到達することでした。その後、ハードウェアボックスに移動して解決しました。また、パケットキャプチャを試して、何が起こっているかを確認してください。ADに行く認証にもたくさんありますか?MSMQの雑談では、ネットワークパスと認証パスを制限する必要があります。

HTH、チャック。


単一のMSMQサーバーと通信しているWebサーバーが4台以上ある場合、スローダウンの原因を正確に突き止めることができましたか?ストレージはiSCSI経由の直接SANストレージであるため、言うまでもなくストレージの問題ではありません。8台のWebサーバーのうち4台の電源を切り、何ができるか見てみましょう。上司に新しいハードウェアを購入するように指示する必要がある場合、いまいましい理由が必要になります。
mrdenny、2010

メッセージの雑談。また、認証ミスの構成もいくつか見つかりました。
SQLGuyChuck 2010

私はwiresharkをダウンロードしてMSMQサーバーに配置し、それが何を表示するかを確認すると思います。Webサーバーに配置できません。ネットワークトラフィックの負荷のため、約30秒後にクラッシュします。
mrdenny、2010

そのため、マシンでWireSharkを起動しました。監視している1つのWebサーバーからのメッセージの間隔が約3秒です。言うまでもなく、それは良く見えません。
mrdenny、2010

私たちは最初の問題を見つけました。それは上のコメントに入れました。助けてくれてありがとう。
mrdenny、2010

1

リモート管理の欠如についてのコメントを参照してください。そうです、MSMQとパフォーマンスカウンターを使用するのは素晴らしい話ではありません。スレッドをフォローしていて、OSの組み合わせがどのように機能するかを知りたい場合は、Motley Queueブログをご覧ください。

MSMQ 4.0パフォーマンスカウンターとNetNameForPerfCountersレジストリキー http://blogs.msdn.com/motleyqueue/archive/2007/12/14/msmq-4-0-performance-counters-and-the-netnameforperfcounters-registry-key.aspx

乾杯ジョンブレイクウェル(MSFT)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.