Tomcat上Webアプリで徐々にレスポンス低下

質問

現在、Tomcat上のWebアプリケーションの負荷試験を実施しておりますが、
レスポンスが徐々に遅くなる事象が発生しています。

遅くなる事象が発生すると単独のリクエストに対するレスポンスも遅くなりますが、
Tomcatの再起動およびJConsoleのGCにてフルGCを実施するとレスポンスは復活します。
（数時間の間隔をあけても、自動復活の確認はできていません。）

JVMの基本的なメモリチューニングをいくつか試みましたが、徐々に遅くなる事象の解消には至ることができていません。

原因調査のポイントがありましたら、ご教授お願いいたします。

回答No.2

Takami Torao（@koiroha） · ベストアンサー

フル GC を実行してレスポンスが回復するのであればマイナー GC が頻発しているのではないでしょうか。
Java 7 以降であれば G1GC を使うと改善するかもしれませんが、根本的に負荷に対して CPU コア数と処理速度、メモリ量が不足していると思います。

お礼

ご回答有難うございました。
Java7を利用していますので、G1GCの利用を検証していきたいと思います。

一時的な負荷増大に対するレスポンス悪化は許容範囲と認識しておりますが、その後の軽量アクセスに対してもレスポンス悪化が継続されてしまう点が課題となっております。
フルGC（Jconsoleから手動で実施）で解放されるメモリ（レスポンス悪化の要因）に対して、自動解放の方法が見いだせればと思っています。

補足

＊解決いたしました。
Spring3.1.1からSpring3.2.11にバージョンUP（関連ライブラリ含め）したところ、レスポンス悪化を解消することができました。
対象のWebアプリケーションはDI/AOPを多用しており、aspectjweaverのバージョンUPによりパフォーマンス改善したと判断しています。

回答No.3

root139

フルGCで改善されるという事を考えると、メモリリークではなさそうですね・・・。
参照は外れてまだGCされていないオブジェクトが何か悪さをしているとは考えられないでしょうか？
例えば、メモリ以外の何らかのリソースを使用するオブジェクトが頻繁に作られているなど。

いずれにせよ、GCログなど、実行時の状況に関するデータを出来るだけ集めることが先決かと。
下記の記事なども参考になるかと思います。
http://www.atmarkit.co.jp/ait/articles/0703/22/news138.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20061102/252525/

早急に対策が必要な場合は、応急措置として一定のリクエスト数毎に java.lang.System.gc を実行するようなServletフィルタ等を作成するのも手かも知れません。
かなり場当たり的ですが・・・。

お礼

ご回答ありがとうございました。
状況の情報収集で参考にさせて頂きます。

補足

Tomcat7のStuckThreadDetectionValveを仕掛けたところ、
レスポンスが遅くなるタイミングで下記のトレース情報を取得することができました。
DI/AOP回りの設定等の不備を想定して見直しを進めておりますが、
その他の情報がご教授頂ければと思い、発信させていただきました。

Webアプリの構成
・Tomcat7.0.47
・Struts2.3.16.2
・Spring3.1.1
---
2 13, 2015 1:01:19 午後 org.apache.catalina.valves.StuckThreadDetectionValve notifyStuckThreadDetected
警告: Thread "http-bio-8080-exec-13" (id=45) has been active for 17,359 milliseconds (since 15/02/13 13:01) to serve the same request for http://localhost:8080/SyanaiShinseiWorkflow/ql/qlo005 and may be stuck (configured threshold for this StuckThreadDetectionValve is 5 seconds). There is/are 14 thread(s) in total that are monitored by this Valve and may be stuck.
java.lang.Throwable
at org.aspectj.weaver.ReferenceType.addDependentType(ReferenceType.java:117)
at org.aspectj.weaver.ReferenceType.<init>(ReferenceType.java:97)
at org.aspectj.weaver.TypeFactory.createParameterizedType(TypeFactory.java:43)
at org.aspectj.weaver.ResolvedType.parameterize(ResolvedType.java:2439)
at org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:925)
at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:83)
at org.aspectj.weaver.patterns.TypePattern.matchesSubtypes(TypePattern.java:178)
at org.aspectj.weaver.patterns.ExactTypePattern.matchesSubtypes(ExactTypePattern.java:74)
at org.aspectj.weaver.patterns.TypePattern.matchesStatically(TypePattern.java:130)
at org.aspectj.weaver.patterns.KindedPointcut.fastMatch(KindedPointcut.java:130)
at org.aspectj.weaver.patterns.NotPointcut.fastMatch(NotPointcut.java:52)
at org.aspectj.weaver.patterns.AndPointcut.fastMatch(AndPointcut.java:47)
at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.couldMatchJoinPointsInType(PointcutExpressionImpl.java:84)
at org.springframework.aop.aspectj.AspectJExpressionPointcut.matches(AspectJExpressionPointcut.java:249)
at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:209)
at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:263)
at org.springframework.aop.support.AopUtils.findAdvisorsThatCanApply(AopUtils.java:295)
at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findAdvisorsThatCanApply(AbstractAdvisorAutoProxyCreator.java:117)
at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findEligibleAdvisors(AbstractAdvisorAutoProxyCreator.java:87)
at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.getAdvicesAndAdvisorsForBean(AbstractAdvisorAutoProxyCreator.java:68)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:359)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:322)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:407)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1461)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:313)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.resolvedCachedArgument(AutowiredAnnotationBeanPostProcessor.java:442)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.access$0(AutowiredAnnotationBeanPostProcessor.java:435)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredField
---

回答No.1

Taiyonoshizuku

何かメモリリーク起こしてるとか、
何らかのオブジェクトの解放漏れとか
オープンしたけど閉じてないとかね

お礼

早速の回答をありがとうございました。
おっしゃる通り、アプリケーションのメモリリークを疑ってみてはみましたが、
待ち時間発生箇所がリクエスト送信からTomcatがアプリケーション（Struts2のAction）を呼び出すまでの間であることが判明しています。
アプリケーションのメモリリークやオブジェクト解放漏れの場合でも、このような事象が発生するのあれば、アプリケーションのメモリリークを疑って調査を進めたいと思います。