極端に重くなる状態について

3,045 views
Skip to first unread message

technopb

unread,
Jun 30, 2011, 10:08:20 AM6/30/11
to jenkin...@googlegroups.com
皆様お世話になっております。
technopb と申します。
Jenkins にもお世話になっております。
 
現在 Jenkins が非常に重くなって困っております。
これが非常に極端でして、Jenkins のページを開く度に10分程度待たされます。
ジョブの設定ページを開いた場合などは20分以上待っても操作できる状態になりません。
何らかの拍子で急にこのような状態になりました。
 
心当たりといえば、JRE Version 6 Update 26 にバージョンを上げたことぐらいです。
しかし、それが原因かと思ってすべてのノードを以前の Update 25 に戻したのですが重いままです。
 
このような現象に心当たりがある方はいらっしゃいますか?
原因が不明で、どうしたら元に戻るのか色々試してみましたが、解決には至っておりません。
 
マスター、スレーブともに WindowsXP です。
スレーブは6台使用しています。
マスターのタスクマネージャでは java.exe が常に高い CPU 使用率(1コア分がほぼ100%)を示しています。
再起動直後は比較的軽い状態ですが、すぐに重くなります。
すべてのスレーブをオフラインにしておくと軽い状態を維持できるようなので、そこに原因がありそうではあります。
ログには OurOfMemory や heap がなんとか、という出力があります。
(これが以前から出ていたものかどうか明日調べてみます。)
ヒープが足りないのかと思い、-Xms1024m -Xmx1024m として起動してみましたが変化ありません。
ヒープの問題の発生源はPerforce プラグインのような気がしますが、特定はできていません。
この問題は職場で発生していますので、今詳細を書くことができませんが、
役に立ちそうであればさらに詳細な情報を記述します。
 
実は以前にも一度このような状態になったことがあるのですが、
そのときは設定を色々いじっている間に元に戻りました。
(ただし、設定を変更したせいで元に戻ったというより、いつの間にか戻ったという感じでした。)
 
この件に関して何かお気づきの点があればご意見ください。
よろしくお願いします。

末広 尚義 / H Suehiro

unread,
Jun 30, 2011, 12:44:45 PM6/30/11
to jenkin...@googlegroups.com
はじめまして

bols-blueと申します。
私も重くなる現象にあったことがあります。

その時はサーバーの移行中で
SVNのポーリングを設定しているタスクで
ポーリング対象のサーバがダウンしていて起こったような記憶があります。
ポーリング間隔は5-10分程度にしていたと思います。

設定画面かどこかでポーリングタスクが一杯です。という感じのメッセージがでていました。

サーバ移行後に起こったことは無いので可能性としてあげておきます。

あやふやな情報ですいません。


2011年6月30日23:08 technopb <tech...@gmail.com>:

--
- 末広 尚義
- twitter @bols_blue
- mail bols...@lnc.jp
- blog

Kohsuke Kawaguchi

unread,
Jul 1, 2011, 1:14:42 AM7/1/11
to jenkin...@googlegroups.com, technopb

同時実行スレッド数が極端に増えている可能性と、メモリが逼迫してGCを延々と
繰り返す状態に陥っている可能性と二つ可能性が考えられますが、
OutOfMemoryErrorがコンソールに出ているとのことですから、後者の可能性が高
そうです。

可能であれば、jmapやjconsoleなどを利用してヒープの様子をみてメモリ使用状
況を確認し、もしメモリがいっぱいになっているようであれば、ヒープダンプを
とってお送りいただければ、こちらで何がメモリを食い潰しているのか確認でき
ます。


--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

technopb

unread,
Jul 1, 2011, 1:12:59 PM7/1/11
to jenkin...@googlegroups.com
technopb です。
そういえば、初めて投稿したんでした。
みなさん、はじめまして。
 
 
bols-blueさん、情報ありがとうございます。

SVNのポーリングを設定しているタスクで
ポーリング対象のサーバがダウンしていて起こったような記憶があります。
 
やはり SCM に原因があるのでしょうか。
と思いましたが、今日の検証(後述)では今回の問題は SCM とは関係なさそうです。
 
設定画面かどこかでポーリングタスクが一杯です。という感じのメッセージがでていました。
 
これは実は私もよく見ますが、特に動作に大きな影響はなさそうなのでそんなに気にしていません。
朝出社すると出ていることがあり、可能な場合のみ再起動している程度です。
システム設定の「ポーリング数」も調整したほうがいいのかもしれませんが、
どのぐらいに設定したらよいのかよくわからないのでとりあえずデフォルトのままで運用しています。
 
 
川口さんありがとうございます。
 
可能であれば、jmapやjconsoleなどを利用してヒープの様子をみてメモリ使用状
況を確認し、もしメモリがいっぱいになっているようであれば、ヒープダンプを
とってお送りいただければ、こちらで何がメモリを食い潰しているのか確認でき
ます。
 
ダンプの件は社の情報ということもありますので検討させてください。
もしかすると珍しい現象かもしれませんので、個人的にはぜひ提供したいところです。
 
 
不具合が修正されるのを待っているわけにもいかないので、
私は私にできることをしようと思います。
そのようなわけで、とりあえず本日の進展を報告します。
 
ログを確認したところ、やはり OutOfMemory は動作が遅くなった時から発生し始めたようでした。
昨日までは極端に遅くなるだけでしたが、今日動かしてみると
起動後数分で OutOfMemory によって完全にマスターが停止するようになっていました。
全ジョブを無効にしてさらに起動後すぐにシャットダウン状態にしても数分程度で停止状態になりました。
別の PC に Jenkins ディレクトリをコピーして動かしても同様でした。
この環境でさらに調べた結果、どうやら特定のジョブが存在するだけで停止状態に陥るらしいことが判明しました。
Jenkins ディレクトリからそのジョブのディレクトリを削除すると、普通に動くようになったようです。
 
上記のようなわけで、この特定のジョブのデータにメモリの問題を引き起こす何らかの変化があったようです。
ダンプがあればすぐに原因まで辿り着けるのだと思いますが、
それまではこのジョブの代わりのジョブを作成してみたりして、なんとかしのいでみます。
 

technopb

unread,
Jul 6, 2011, 11:37:04 AM7/6/11
to jenkin...@googlegroups.com
technopb です。
進展がありましたので報告させていただきます。
 
色々復旧のための試行錯誤をしているうちに、おおよその原因がつかめました。
どうやら Perforce において大量の Changelog が存在すると Jenkins が(起動するだけで)ヒープを使い果たすようです。
Perforce プラグイン設定の First Changelist to Track のヘルプにメモリを使い果たす可能性の記述があります。
今回の件では数万の数のファイルが一気に変更されたため、メモリを使い果たして急に動作が重くなったようです。
 
別の SCM プラグインで大量の Changelog が存在する場合はどのように振る舞うのか未確認ですが、
Jenkins 上で大量の変更を見ようとする人は少ないと思うので、
メモリを使い果たす前に適当に処理を打ち切ったりするのが望ましいように思います。
(そう実装されるのを願って…)
 
 
川口さんへ
 
遅くなりましたが、ヒープダンプを用意いたしました。
23MB ぐらいあるのですが、どこに送ればよいでしょうか。
 

Kohsuke Kawaguchi

unread,
Jul 6, 2011, 8:00:52 PM7/6/11
to jenkin...@googlegroups.com, technopb

Dropboxなどを経由して僕個人あてにお送りいただければ結構です。

ご指摘の原因で多分正解なのではないかと思います。そうであれば、当該のビル
ドをディスクから削除して再起動すればよいと思います。

メモリを使い果たす前に処理を打ち切る、というのはJavaアプリケーションに
とっては結構難しい問題です。

technopb

unread,
Jul 10, 2011, 2:29:44 PM7/10/11
to jenkin...@googlegroups.com
川口さんにヒープダンプをお渡ししました

technopb

unread,
Jul 10, 2011, 2:49:12 PM7/10/11
to jenkin...@googlegroups.com
申し訳ありません。
途中で送信してしまいました。
再度送信します。

川口さんにヒープダンプをお渡ししました。
ご調査よろしくお願いいたします。
 
ご指摘の原因で多分正解なのではないかと思います。そうであれば、当該のビル
ドをディスクから削除して再起動すればよいと思います。
 
現在はそのように対処して運用しています。
やはりこれが原因だったようで、その後は何の問題もなく動いています。
ご指摘ありがとうございました。
 
メモリを使い果たす前に処理を打ち切る、というのはJavaアプリケーションに
とっては結構難しい問題です。
 
これに関しては、それっぽい処理ができれば実用上問題ないように思います。
たとえば、Changelog のファイル数が1万を超えるようであれば処理を切り替える、など、
なんらかの閾値を設定すればどうでしょうか
(何らかの理由でその動作が望ましくない場合はオプションにするのがよいかもしれません)。
 
(ところでこれは素朴な疑問なのですが、なぜ起動直後に Changelog のメモリを確保するのでしょうか。
誰かが Changelog を見たときにそういった処理がされると思っていたので、Changelog が原因だとは予想もしませんでした。)
 
本来は私が修正に挑戦すべきですが、私にはそのようなスキルがないので、
申し訳ないのですが今回は報告のみさせていただきました。
 
では今後ともよろしくお願いいたします。
 
Reply all
Reply to author
Forward
0 new messages