TECHBLOGスキルブログ

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

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/

ユニトラストでは共に成長できるメンバーを募集しています!
「一緒に働いてみたい!」と思った方はこちらからどうぞ!

              

OTHER CONTENTSその他のコンテンツ

UNITRUST会社を知る

  • 私たちについて

  • 企業情報

SERVICE事業内容

  • システム開発

  • 自社サービス

CONTACT
お問い合わせ

あなたの「想い」に挑戦します。

どうぞお気軽にお問い合わせください。

受付時間:平日9:00〜18:00 日・祝日・弊社指定休業日は除く

お問い合わせ