検証機のスローダウンと解決アプローチ

2014.11.25

こんにちは、ユニトラストの久賀です。
以前に発生したスローダウンとその解決アプローチについて
遠い記憶たどりながら会話形式で紹介いたします。

【システム概要】

帳票出力システム

■環境

▼CentOS6.x, Java1.7(HotSpot), Apache2.x, Tomcat7.x, PostgreSQL9.x
▼F/W:= Seasar2 + SAStruts + Doma + POI3.x

■経緯

※Aさんと私は全く別のチームです。


Aさん「帳票のDLで滅茶苦茶時間かかります！」
私「Excelのファイルサイズが大きすぎるんじゃない？」
Aさん「300KB位なのに数分かかります！」
私「じゃぁ、ちょっと調べます。。。」→検証機にログイン


CPUチェック

$ top -d 1

…ほぼ100％張り付き、メモリもusedが98％くらい（2GB中）


私「Tomcatのアプリケーションって複数？」
Aさん「そうです」→実際7つくらい
Aさん「でも、今まで動いていたのに今日急に遅くなりました」
私「アプリケーション数は関係ないかぁ。。あとはVMだな」
私「リモートでGCログ監視したいけど、設定してある？」
Aさん「？？？」
私「OK.調べます。」


まずはTomcatの設定ファイルを検索

$ find ./ -type f -name setenv.sh
/usr/path/to/tomcat7/bin/setenv.sh

$ less /usr/path/to/tomcat7/bin/setenv.sh
#JAVA_OPTS="-Xms2048M -Xmx2048M -XX:MaxPermSize=256m -XX:PermSize=256m"
JAVA_OPTS="-Xms2048M -Xmx2048M -XX:MaxPermSize=2048m -XX:PermSize=2048m"


私「・・・」
私「Permanentが2GBって、、、（大きすぎるだろ？）」
というか、サーバの物理メモリと同じ。


そもそも端緒となったことを思い出すと、
Full GCが頻発していることが先ず考えられる。
というのも、Full GC中は他のスレッドが全てとまるため、
Web画面上ではレスポンスが著しく低下しているように見えてしまうから。

確かに、Permanentが大きすぎるため、Heap（特にOld領域）が枯渇し、
頻繁にFull GCが走っていると想像できる。

本来は、GCログを取得して検証するところだが、
テスト中かつ明らかな設定ミスということもあり、
JVMの起動パラメータを変更してTomcatを再起動することに。

JAVA_OPTS="-Xms1024M -Xmx1024M -XX:PermSize=256m -XX:MaxPermSize=256m"


Aさん「早くなりました！」
私「じゃぁ、後は経過観察が必要だな。」
私「数日テストして問題があればまた言ってね。」


以降何も連絡がないので大丈夫だったんでしょう。

総括

JVMの設定は理解している人がやる！←当たり前
リモートで監視できる設定をしておく（jconsoleとか）←当たり前

おまけ

Java1.8のHotSpotからPermanentがなくなったらしい
c.f.)http://equj65.net/tech/java8hotspot/