Tomcat高負荷時の設定について

現在、JMeterを使用してTomcat上で動作するAPに負荷を掛けた際のパフォーマンスを測定しております。
負荷を掛けずにブラウザで処理を実行した際には1秒程度でレスポンスが返却されてくるのですが、
以下の条件で負荷を掛けるとレスポンス速度が段々と遅く(8秒～500秒程度)なって行ってしまいます。
また、かなりの頻度でConnectionタイムアウトが返却されてしまいます。

[負荷条件]
スレッド数：1000
Ramp-Up期間：60秒
ループ回数 ：無限ループ
※ スレッド数を500くらいにするとConnectionタイムアウトは発生しないのですが、
処理時間はやはりかなり遅くなってしまいます。

最初はJVMのFullGCの頻発が原因かと思い、GCの状況を確認しましたが、
パフォーマンスに影響を与えそうなFullGCは特に発生していませんでした。
[JVM オプション]
"-server -Xmx1024m -Xms1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:+PrintGCDetails -Xloggc:/usr/local/tomcat/logs/gc.txt"

次にTomcatのserver.xmlでの最大thread数がデフォルトの状態だったので、
maxthreadsの値をとりあえず「2000」まで増やしてみたのですが状況は変わらずでした。
[server.xml]
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8123" maxHttpHeaderSize="8192" minProcessors="5" maxProcessors="1000"
maxThreads="2000" minSpareThreads="25" maxSpareThreads="1000"
enableLookups="false" acceptCount="100" debug="0" connectionTimeout="60000"
useURIValidationHack="false" disableUploadTimeout="false" />

また、topを確認してもロードアベレージが高くなっているのが少し気になりますが(5.0～7.0程度を推移)、
Swap領域等は使用されている訳でもありませんでした。
Tomcatの経験もほとんど無いため何がボトルネックとなっているのかが分からずに困っております。
皆さまの経験から、推奨される設定、どこを調査した方が良いか、または参考となるサイト等が御座いましたらご教授願えないでしょうか。

[環境]
CentOS release 4.7
　メモリ：4G
　CPU　 ：Intel(R) Xeon(R) CPU 2.00GHz X 2
jdk1.5.0_14
Tomcat 5.5

No.6 回答者： mibusys 回答日時： 2009/04/10 11:29

とりあえずthread数について。

Tomcatのthread数は簡単に言えば瞬間的に同時に処理する数です。
これはレスポンスを返し終わった直後に使いまわし可能になります。
JMeterのスレッド数が1000ならば最大でも1000アクセスしかないわけで
それ以上を設定しても無意味です。
通常なら同時アクセスユーザ数の1/10もあれば十分です。

コネクションプーリングの数もボトルネックになりやすいのですが
CPUが100近いのであれば今回は関係ないでしょう。


定数スループットタイマで1分当たりに1000リクエストに設定し
かつ1000スレッドだと1分当たり100万リクエストを発行しようと
していることになります。凶悪すぎます。単純に負荷をかけすぎです。
DoS攻撃耐久テストなどでなければやめたほうがいいでしょう。


JMeterを使ってテストをするときの一般的(だと思う)な方法を書いておきます。
1)一般的な操作のシナリオを1人分作ります。このときありそうな操作・遷移
を考えることが重要です。で、各画面間の遷移の間にガウス定数タイマなどを使って
現実的な待ち時間を設定します。
例：ログイン画面を表示→ログイン→初期画面表示→検索(各画面間の平均待ち時間3秒)
2)スレッド数を100、200、400…などと増やしてテストをする。
これだけです。

こうすることによってターゲットとする人数が同時間帯にアクセスした場合の
一般的な負荷をかけることが可能になります。


結論を言うと設定・チューニング云々の前にテスト方法に問題がある可能性のほうが高いのではと思いました。

この回答へのお礼

mibusysさん

回答ありがとうございます。
ご指摘頂いた通り、今回のテストではスレッド数が1000件なので2000は必要ないですね。。。
目標値が1分当たりに2000件を捌く事だったので一応2000を設定してしまっておりました。

定数スループットタイマに設定する値は1スレッド当りの値だったのですね(>_<;)
1分当たりの総リクエスト数になるものだとばかり思ってしまっていました、すみません勉強不足ですね。

JMeterの一般的な試験の仕方につきましてもご教授ありがとうございます。ただ、今回のAPでは画面遷移等は無く、様々な検索条件に合わせて結果を返すAPのため、複雑なシナリオは特にございませんでした。
別の機会で再度JMeterを使用する際にはぜひぜひ参考にさせて頂きます。

もっとテスト方法を見直さないといけないですね。
ご指摘頂いた内容を受けて再度試験を実施したいと思います。

お礼日時：2009/04/13 01:07

No.5 回答者： yuji 回答日時： 2009/04/09 23:47

うちの会社では、

Yourkit Java Profiler
という製品を購入して、プロファイリングを行って、
チューニングしました。

私は直接使っていませんが、使ったメンバーによると、
使いやすかったそうです。

参考URL：http://www.yourkit.com/

この回答へのお礼

yujiさん

回答ありがとうございます。
プロファイラはNetBeansを使おうと思っていたのですが、
Yourkitも使い易いのですね。

参考URL等からぜひ検討させて頂きたいと思います。
情報ありがとうございました。

お礼日時：2009/04/13 00:47

No.4 回答者： askaaska 回答日時： 2009/04/09 11:31

> サーバ側のチューニング

案外コードに無駄が多いと言う可能性も

メモリだけじゃなくCPU負荷も確認してね。
メモリに余裕あるかもしれないけど
CPUに余裕がないのかもしれないわ。
あとデータ転送量も要注意ね。
途中のルータやケーブルもボトルネックになりうるわ。

この回答へのお礼

askaaskaさん

回答ありがとうございます。
ご指摘頂いた点を踏まえて、Linux自身から負荷を掛けてみましたが
やはり処理速度は遅くなって行ってしまったのでネットワーク関係ではなさそうな気がします。
また、負荷を掛けている際のスレッドダンプ等も取得してみましたがブロックされていそうな箇所は無さそうでした。

ただ、CPU使用率が95%くらいと高くなっているのとロードアベレージが高い事からコードに無駄があるのか、
検索処理のファイルIOの辺りで遅延が発生しているのかもしれません。

もう少し調べてみます。
もし理由が分かりましたらまた書き込ませて頂きます。

色々とご指摘ありがとうございました、色々と勉強になりましたっ！

お礼日時：2009/04/10 00:07

No.3 回答者： askaaska 回答日時： 2009/04/09 09:16

> Response message: Non HTTP response message: Connection timed out: connect

これはね
JMeterが想定している時間内に
レスポンスが得られないときに発生するのよ。

> スレッド数：1000
> Ramp-Up期間：60秒
> ループ回数 ：無限ループ
単純に処理しきれないのね。
TomcatじゃなくてJMeterの方よ。

この回答へのお礼

askaaskaさん

回答ありがとうございます。
JMeter側で判断しているタイムアウトだったのですね。勉強不足で申し訳ございませんでした。
ただ、JMeterの負荷を下げた場合（例：スレッド500、繰り返し1回）には

> Response message: Non HTTP response message: Connection timed out: connect

の応答は返って来ないのですが、処理速度はかなり劣化（20秒～60秒）してしまいます。
こちらは何かしらサーバ側のチューニングで回避出来ないかと考えております。
何かしら注意する点や、参考となるサイト等をご存知でしたらご教授頂ければ幸いです。

お礼日時：2009/04/09 11:04

No.2 回答者： mibusys 回答日時： 2009/04/08 23:59

ぱっと見た感じではTomcat云々の前にJMeterのシナリオが怪しい気がします。

タイマに何を使っていますか？
タイマの待ち時間をどの程度にしていますか？

もしかしたらタイマの待ち時間が小さすぎることが原因かもしれません。
何のタイマも使っていないのだとしたらそれが間違いなく原因です。
普通の運用を想定した負荷検証ならガウス定数タイマなどを使って
適切に待ち時間を設定しましょう。

万が一それが原因ならまずはもう少しJMetertを勉強されたほうがいいと思います。

この回答へのお礼

mibusysさん

回答ありがとうございます。
タイマには「定数スループットタイマ」を使っています。
1分当たりに1000リクエストを想定して設定しておりました。

ご指摘頂いた通り、JMeterにつきましても勉強中でして理解が乏しいと思います。
上記の1分間当たりに1000リクエストは高い値を設定しすぎてしまっているのでしょうか。

お礼日時：2009/04/09 10:41

No.1 回答者： askaaska 回答日時： 2009/04/08 19:32

1)

どんなアプリケーションなのか判らないわ。

2)
Connectionタイムアウトって何のConnection？

最低でもこの２つが判らないと話が進まないわ。

この回答へのお礼

askaaskaさん

回答ありがとうございます。
説明不足ですみませんでした。

1)どんなアプリケーションなのか判らないわ。
クライアントから送られてくる検索キーワードを含むXMLファイルを検索し、そのXMLファイルの内容をクライアントへ返却するアプリケーションです。
DB等は使用しておらず、Tomcatのコネクションプール等も使用しておりません。

2)Connectionタイムアウトって何のConnection？
JMeterのアサーションの結果に「Response message: Non HTTP response message: Connection timed out: connect」と言うメッセージが返却されて来てしまいます。
このメッセージを見てTomcatからConnectionタイムアウト（maxThreadsやacceptCount等の設定値によってTomcatへ接続が出来ない？）が返却されて来たものだと思っていました。

上記の内容から何かしら確認した方が良いポイント等が分かりましたらご教授頂ければ幸いです。

お礼日時：2009/04/08 23:30