[KSUG 문의] PermGen OutOfMemory 문제에 대한 근본적인 해결방법 아시는분?

[고종봉]

안녕하세요? 오랜만에 질문을 드립니다.

본론으로 들어가서,,

GlassFish에 WebApp WAR를 여러번 deploy (redeploy) 해야하는 상황에서

PermGen (Permanent Generation) Out Of Memory 에러가 발생합니다.

현재까지 파악한 원인은, WAS에서 redeploy 시 기존의 ClassLoader에서 사용한 PermGen 자원들이 해지가 되지 않아서 인데요.

-XX:MaxPermSize= 를 사용하여 redeploy 가능 횟수는 늘였지만, 영원한(?) 해결책은 되지 않는 군요.

WAR를 지속적으로 redeploy 해야하는 요구사항이 있는데, 이렇게 PermGen 에러가 해결되지 않으면 문제가 될 것 같습니다.

혹시, PermGen 에러를 해결하신 분(MaxPermSize 방식이 아닌, 완전한 해결..) 계시면

(서버 전문가님~ JVM 전문가님~)

도움 부탁드립니다 ~!

p.s : 지금까지 작업해본 내용 및 제약조건들을 기술해봅니다.

1. PermGen 메모리 GC관련 옵션들인

-XX:+CMSClassUnloadingEnabled

-XX:+CMSPermGenSweepingEnabled

-XX:+UseConcMarkSweepGC

등도 적용해보았으나 해결되지 않았습니다.

2. 메모리 릭이 발생하는 위치가 JVM(Sun HotSpot) -> WAS(GlassFish) -> WebApp (불특정) 의 과정 중에 있을 것으로 추정되는데

WAS의 update나 patch 에 의존하여 해결하거나, WebApp의 메모리 릭을 추적하는 방식으로는 완전한 해결이 어려운 상황입니다.

(WebApp는 어떤 것이든지 올 수 있기 때문입니다.)

다시 말해, 옵션이나 장치를 추가하여 어떠한 WAS나 WebApp를 사용하더라도 문제를 해결할 수 있는 근원적인 해결방안이 필요한 상황입니다.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Sewon Ann]

2년전에 저도 고생을 했었어요.
spring forum에서 봤을 땐 spring 문제는 아니고 quartz 등의 third party 문제라는 식으로 얘기했었고, 그 밑엔 '서드파티던 세컨파티던 하여간 해결이 되어야 할 거 아니냐!' 는 원성어린 리플들이 달렸었지요.

전... 그냥 새벽에 서버 매번 restart 해 버렸습니다. 너무 어려운 문제더라구요.
GlassFish 가 시동시간이 얼마나 걸리는 지 모르겠지만, 아주 길지 않다면 아얘 deploy 할 때 마다 restart 해 버리는 것은 어떨런지요.

2010/5/4 고종봉 <mercu...@gmail.com>

[고종봉]

네, 감사합니다.

아무래도, 근원적인 해결책을 발견하지 못하면 그렇게라도 해야할 것으로 보입니다.

물론,,, 윗분들이 싫어하겠지요..ㅎㅎ

다른 분들도 말씀해주세요~

2010년 5월 4일 오전 11:01, Sewon Ann <kin...@gmail.com>님의 말:

[kuwon Kang]

안녕하세요?

강구원입니다.

종봉님께서 대부분 정리는 잘 하신 것 같네요.

말씀하신 것처럼 아래와 같이 2가지 문제로 볼 수 있을 것 같습니다.

1. GlassFish에서 Redeploy시에 기존 Classloader에 의하여 생성된 메모리 영역에서 leak이 있을 수 있습니다.

2. 사용하고 계신 WebApp상의 라이브러리나 오픈소스등에서 ClassLoader를 핸들링 또는 Class 정보를 어떤곳에 기록 함에 있어 메모리 릭이 있을 수 있습니다(저장은 했지만 Redeploy, Unload시 해제가 안되는 상황이 발생하는 거죠).

결론적으로 1번의 경우는 patch밖에는 방법이 없어 보이구요 2번의 경우라면 사용하고 계신 기술들을에 대한 

리서치가 필요하지 않나 생각이 듭니다.

WebLogic같은 상용 프로그램은 문제가 생기면 SR로 기술지원이 되지만 GlassFish같으면 ..

쉽게 풀리기 어려운 상황으로 보이지만 고생하시면 답도 있지 않을 까 생각이 듭니다.

도움이 별로 되지 않았네요.ㅠㅠ

그럼 고생하십시요.

2010/5/4 고종봉 <mercu...@gmail.com>

--
Blessings.
Kuwon Kang
............................................................
IT specialist and architect.
Java technology engineer.
JavaEE architect/developer.
Solution developer.

- Model Driven Architecture.
- Test Driven Development.
- Test Driven Software Design.
- Refactoring Oriented Development.
- Practical design and modeling.
- Robust  Software Design and Engineering.
............................................................
Prever
http://www.prever.co.kr
Blog:
http://www.prever.co.kr/josh
............................................................

[kuwon Kang]

아 한가지 빠졌네요.

테스트는 해 보실 수 있을 것 같습니다.

GlassFish가 문제가 없을 수 있으니 다른 라이브러리들 첨부하지 마시고 아주 간단한 Servlet 하나 만들고

WAR로 만들어 계속 redeploy를 한번 해 보시면 문제를 좁혀갈 수 있겠네요.

2010/5/4 kuwon Kang <preve...@gmail.com>

[Sanghyuk Jung]

Spring DM server를 local에서 개발할 때 사용해도 됩니다.

 

작은 내부 시스템에 운영서버로도 1년째 쓰고 있는데, 아직까지 배포하고 수동 재시작 안 해도 문제없는거보면 Local에서는 더 안심하고 써도 되는거 같습니다.

 

Plugin 깔면 Tomcat쓰는 것처럼 WTP안에서 자연스럽게 연동됩니다..

OSGi 프로젝트가 아닌 일반 web project도 띄울수가 있죠.

 

단점은.. jsp파일 수정할 때 반영시간이 일반 Tomcat보다 조금 더 걸린다는 점이 있습니다..

 

 개인적으로는 java파일은 WAS 안 띄우고 test 코드로 다 실행시켜보고 JSP만 WAS띄우고 수정을 하니, 오히려 JSP반영 속도가 더 중요해져서 지금은 Spring DM 서버로 개발은 하지 않고 있기는합니다.

 

 

2010년 5월 4일 오전 11:14, kuwon Kang <preve...@gmail.com>님의 말:

[Young Gyu Park]

스프링 dm 서버와 tc 서버의 차이점이 뭐죠?

전 지금 tc서버를 사용하고 있는데, 저도 가끔 이 문제로 고생하고 있죠.

maven으로 관련 라이브러리를 죄다 다운 받아서 사용하고 있는데 디펜든시를 고려해서 수십게 정도를 알아서 다운받아줘서 편하긴 한데, 이 문제 해결하기 위해서 그 관련 라이브러리를 다 찾아다니는게 엄두가 않나서 그냥 포기하고 redeploy하면서 작업하고 있죠.^.^;;

그리고 insight/applications/traces 이거 사용법 아시는 분 계신가요?

어플리케이션 모니터링 해 주는것 같긴 한데 어떻게 설정해서 사용하죠?

관련 메뉴얼이나 참고 사이트나 있다면 좀 알려 주세요.

2010/5/4 Sanghyuk Jung <ben...@gmail.com>

[Sanghyuk Jung]

DM서버는 OSGi 서버이고, TC서버는 Tomcat에다 모니터링 기능을 확장한 것입니다. DM서버 위에도 tomcat이 OSGi 번들형태로 올라가 있죠.

 

tc서버의 모니터링 기능은 , 저는 local에서는 Eclipse 안에서 servers에 module 설정에 insight.war 파일을 web module로 추가해서 사용해봤었습니다. 물론 STS에서 제공하는 TC server용 WTP plugin은 깔려있어야겠죠.

 

 

2010년 5월 4일 오후 2:01, Young Gyu Park <ygp...@gmail.com>님의 말:

[Young Gyu Park]

음 그렇군요. tomcat이 OSGi번들 형태로 올라가면 glassfish나 jetty같은 것도 다 번들 형태로 올라갈 수 있겠군요.

OSGi의 번들 형태로 올리고 내린다고 해도 결국 근본적인 해결책은 되지 않겠군요.

OSGi서버에서 번들 형태의 어플리케이션 또는 관련 의존 라이브러리에서 메모리 릭이 발생하면, OSGi서버가 죽나요?

아님 번들 어플리케이션만 죽나요?

만약 OSGi서버가 죽는다면 차라리 tomcat에서 올리고 내리고 하는게 낮겠군요.

2010/5/4 Sanghyuk Jung <ben...@gmail.com>

[Sanghyuk Jung]

메모리릭이 배포 때 reload로 인한 것 때문에 발생하는 것이라면 Spring DM서버에서는 그 종류의 메모리릭은 현재 쓰고 있는 동안에는 발생하지 않았습니다. (어려운 조건을 주면서 테스트한 것은 아니라서 언제나 안정한 건지는 모르곘습니다만;)

 

 특정 라이브러리의 문제로 배포가 없어도 시간이 증가하면서 leak이 발생하는 것이라면 OSGi도 해결책은 안 되겠죠.

 

메모릭 때 어떤 동작을 하게 될지는 아직 시험을 안 해봐서 모르겠네요

 

2010년 5월 4일 오후 2:37, Young Gyu Park <ygp...@gmail.com>님의 말:

[Young Gyu Park]

혹시 실험 하게 되면 결과 공유 부탁드립니다.

참 흥미로울거 같네요.

dm이 얼마나 안정적인가에 관한 결과 레포트 정도 되겠군요. ^.^

2010/5/4 Sanghyuk Jung <ben...@gmail.com>

[KwonNam Son]

WAS 를 껐다켜지 않고 웹 애플리케이션을 reload 하면  PermGen  space 에 메모리릭이 발생하는 것은 이미 많이 알려진 사실 같습니다.
톰캣 7 과 6.x 대 현재 최신 버전에서는 일부 써드파티 라이브러리에 의학 메모리 누수문제까지도 해결했다고 하네요.

참조 : http://java.dzone.com/articles/memory-leak-protection-tomcat

하지만 실제 운영시에는 그냥 JVM을 재시작 하는게 안정적인 배포 방식으로 보입니다. 개발시에만 reload 기능 사용하구요.

저희는 WAS를 두 대 띄우고 Apache에서 서블릿 요청을 WAS에 라우팅하게 하고(물론 죽었을 때는 잠시 라우팅 못하게 하고) 한쪽 restart할 때 다른쪽에서 서비스하고, 한쪽 리스타트가 끝나면 다른쪽을 리스타트 하는 식으로 하고 있습니다. 그러면 대부분의 사용자는 서버 재시작을 못 느낍니다. 오히려 서버 하나로 reload 하면 reload 시간동안 죽어 있는거처럼 느껴져서 더 안좋죠. 물론 완전 재시작보다는 그 시간이 짧겠지만.

WAS 인스턴스는 포트만 바꿔서 서버 한대에 두대를 띄우는 것도 좋습니다. 어차피 요즘 서버 장비들 메모리와 CPU는 대분분의 경우 WAS 두 세대 돌려도 무리 없을 만큼 되거든요. 서버 자원을 모두다 사용하기엔 이런 방식이 나아보입니다.

2010년 5월 4일 오후 5:29, Young Gyu Park <ygp...@gmail.com>님의 말:

--
* 까먹지말자! http://kwon37xi.egloos.com

[Kuwon Kang]

J2ee시스템 구축시 고객의 입장에서 늘 Hot Issue인중 하나는 Hot Deployment입니다.

Main Frame은 되는데 Java도 되야 하는거 아니냐? 그런데 사실 이 문제에 대해서 누구도 100%확실히 된다고 

아무도 말을 못하죠. 이유는 여러 가지가 있겠죠.

즉 Server재기동 없이 트랜젝션 처리에 큰 무리없이 deployment를 할 수 있느냐 하는 거죠.

그런데 사실 이렇게 사용하는 경우는 거의 없다고 봐야 합니다.

실제 지금 하고 있는 곳에서도 Hot Deployment를 WAS벤더가 지원하지만 여러가지 제약사항이 따르죠.

가령 글로벌 트랜젝션을 쓰면 안된다던지 하는 문제들이 있습니다.

다만 어떤식으로든 메모리 누수가 있는지를 확인하고 가능 하다면 그 문제를 해결하는 것이 소프트웨어를 Delivery하는 입장에서 첫번째 해야할 일이라고 생각합니다.

결국 일반적으로 Deploy하는 방식인 Graceful Restart를 하는것이 바람직하다고 할 수 있을 것 같습니다.

2010/5/4 KwonNam Son <kwon...@gmail.com>

[JUNG-LAE JO]

이렇다 저렇다 해도, 고객은 용납하지 못하죠.

무조건적으로 해 놔라 하는 식이라면 메모리 릭을 잡으려 하기 보단, dm 에 번들 버전 관리 하는 방법으로 풀어나가야 할 것 같습니다. 물론 WAS 를 바꾸지 못하는 상황이라면 새벽에 내렸다 올려야 겠죠..

[Sanghyuk Jung]

 이 주제가 되게 반복적으로 많이 나오는 이야기인데, 그때마다 다른 분들의 경험을 많이 들을 수 있다면 괜찮을 것 같습니다.

 

 잘 아시듯이 여러대의 서버의 WAS farm 구성할 수 있는 환경이라면 사용자가 의식할 수 없게 재시작할 수 있는 구성이 어렵지는 않습니다.. Teracotta 같은거 이용해서 cache farm 같은거 구성해서 session clustering해결한 사례도 보이구요.  

 서버가 2대라도 부하적은 시간대 골라서 순서대로 내렸다올리면 해결되는 문제라서 배포정책이 잘 되어 있는 시스템이라면 크게 이 문제를 걱정하지는 않는듯합니다..

 

 오히려 개발환경에서 계속 내렸다 올리는 것이 생산성 저해가 크므로 JRebel이든지, Dm server든지, 테스트코드를 최대한 활용하던지 하는 사례를 좀 정리해서 각 방법의 한계와 장단점 등을 발표해보면 괜찮을듯도 하네요.다음 KSUG 세미나 때 누가 발표해주세요~ ^^

2010년 5월 4일 오후 7:01, JUNG-LAE JO <uberme...@gmail.com>님의 말:

[고종봉]

다들,, 좋은 경험과 관련된 노하우를 알려주셔서,, 감사합니다~!!

즐거운 어린이날 되세요~!!

(이제, 윗분들 설득하는 일만 남았네요.ㅎㅎ)

2010년 5월 4일 오후 7:18, Sanghyuk Jung <ben...@gmail.com>님의 말: