행복한디벨로퍼

  안녕하세요. 오늘은 아파치 권장 설정인 ServerTokens에 대해 알아보도록 하겠습니다. 최근 이슈중에 보안팀에서 저희가 서비스하는 서버의 정보가 다 노출되고 있다는 메일을 받았습니다. 메일을 받고 실제로 curl --head URL주소를 처서 보니 서버정보가 다 노출되고 있는 것을 확인 할 수 있었습니다. 그럼 어떻게 서버정보가 노출이 되고 있었는지, 해결책은 무엇인지에 대해서 알아보도록 하겠습니다.

[ 문제상황 ] 

위의 그림을 보시면 curl --head UR을 통해 요청에 의한 reponse의 head값을 받아 오는 것을 확인할 수 있습니다. 문제는 SERVER의 정보가 모두 노출되고 있다는 점입니다. 이로인해 클라이언트는 해당 서버의 정보(웹 서버 종류, 운영체제의 종류, 설치된 모듈, 마이너버전, 메이저 버전 등)가 다 노출되게 됩니다. 이렇게 서버 정보가 필요 이상으로 노출 될 경우 악의적으로 이용될 수 있음에 꼭 기본적인 내용만을 노출하도록 할 필요가 있습니다.

[ 해결책 ]

위와 같은 문제점을 해결하기 위해 필요한 것이 ServerTokens 입니다. 보통 아파치 설정파일인 httpd.conf내에서 정의합니다. ServerTokens의 역할은 클라이언트 웹브라우저에게 서버의 정보를 얼마나 알려주냐를 설정하는 것입니다. 따라서 아래와 같은 순서로 서버 정보 노출을 예방하도록 해야합니다.

1. 자신의 서버의 정보가 노출되고 있는지 확인한다.

2. 확인이 되고 있다면 Apache의 httpd.conf에 ServerTokens가 설정되어 있는지 확인한다. (아파치 내에서 http-default.conf를 Include 하고 있다면 해당 부분에 설정이 되어 있는지 확인한다 꼭!!!)

3. 설정된 곳을 찾아 ServerTokens 옵션을 Prod로 변경해준다. 이 때 ServerSignature도 On에서 Off로 변경해준다.(보통 함께 붙어 있다. On에서 Off로 변경시 브라우저 상에서 아파치 서버 정보를 노출하지 않겠다는 의미)

#ServerTokens의 설정 값은 Prod, Major, Minor, Min, OS, FULL이 있다.

4. 설정을 변경한 후 아파치를 재시작 해준다.

이렇게 ServerTokens를  Prod로 설정을 마치고 다시 재시작한 결과는 다음과 같다.

서버정보에 웹 서버의 이름만 표시된 걸 확인할 수 있다.

이렇게 간단한 설정으로 인해 우리의 중요한 서버정보가 노출됨을 막을 수 있다. 지금 당장 확인해보고 필요 이상의 서버정보가 노출되고 있다면 요렇게 변경해 주길 바란다. 참고로 ServerTokens 지시어는 디폴트로 설정되어 있지 않고 ServerTokens 지시어 설정을 안했을 경우 Full 설정 처럼 모든 정보를 노출하게 된다! 지금 당장 확인 고고씽~!!!

 안녕하세요. 오늘은 최근 겪었던 문제 상황에 대해 포스팅 하도록 하겠습니다. 최근 담당하고 있는 프로젝트 중 고객의 문의가 들어오면 해당 문의가 상담원들에게 배분이 되도록 작동하는 배치성 프로젝트에 문제가 발생했습니다. 특정 시간이 되면 미처리 문의들이 배분이 되어 웹 화면에서 조회가 되어야 정상이지만 어찌된 일인지 아무리 테스트 문의를 넣어보아도 문의가 제대로 배분이 되지 않았습니다. 이 문제를 해결하면서 겪었던 에피소드에 대해 지금부터 포스팅 하도록 하겠습니다. 

# 해당 문제는 알파 환경(정식 사용자들에게 서비스 되지 않는 환경)에서 발생한 상황입니다. 

문제 상황 

:: 고객들의 문의가 상담원들에게 분배가 되지 않는 현상. 고객들이 문의를 넣게 되면 배치성 프로젝트를 통해 미처리 문의들을 상담원들에게 배분해주는 프로젝트가 정상 작동하지 않음

원인 파악

:: 위와 같은 문제상황이 발생하고 일단 서버에 접속해 톰캣이 혹여나 죽진 않았는지 ps -ef | grep java 명령어를 통해 확인해 보았습니다. 확인을 한 결과 톰캣은 정상작동하고 있는 것을 확인하였습니다. 그래도 혹시나 해서 톰캣을 재시작 해보았지만 역시나 정상작동하지 않았습니다. 그렇게 원인 파악에 대해 고민하던 중 선배님 df로 파일시스템을 사용해 보라고 하셨습니다. df 명령어(밑에 간단한 설명)를 통해 파일시스템을 보니 파일시스템 사용률이 100%을 다다랐던 것을 확인 할 수 있었습니다. 

해당 문제의 원인은 프로젝트에 약 15개 정도되는 배치성 프로세스(보통 1,2 분에 한 번씩)가 작동하고 있었는데 로그 레벨이 DEBUG로 설정되어 있었던 것이 화근이되었습니다. 이에 아무도움이 되지 않는 불필요한 로그들이 무수히 쌓이게 되었고 파일시스템 사용률이 100%로 치닫게 되었던 것이었습니다.

[그림 출처 : http://changpd.blogspot.kr/2013/05/spring-lo4j.html]

위의 그림을 보시면 log4j의 레벨을 보실 수 있는데 DEBUG로 설정을 하게 될 경우 DEBUG 상위수준의 로그 또한 모두 기록하는 것을 파악할 수 있다. (보통 실제 리얼환경에서는 ERROR 사용) 

문제 해결

:: 먼저 해당 로그 파일들을 제거(실제 리얼환경에서는 백업을 하길 권장)해주고 톰캣을 재시작 해주었다. 실제 환경일 경우 파일 시스템 용량이 특정 %이상 치솟았을 때는 메일, SMS로 상황을 미리 파악하고 대처할 수 있지만 알파환경의 경우에는 그렇지 않기 때문에 파일시스템 용량 상황을 주기적으로 점검해주고 특별한 이슈가 없다면 로그 레벨의 수준을 DEBUG 상위 레벨로 설정해 줄 것을 권장한다.  

#df 명령어에 대한 간단한 설명

:: 사용중인 파일시스템의 전체용량, 사용한 용량, 사용가능한 용량, 사용율, 마운트 정보 등을 보여주는 명령어로 현재 사용중인 파일 시스템들의 디스크사용량을 출력한다. df 명령어는 /etc/fstab파일에서 파일시스템정보를 참조하고, /etc/mtab에서 마운트된 정보를 참조한다고 한다. 기본표시 용량단위는 KB(Kilo Byte)이다. 

모니터링을 통해 서버 상태를 항상 체크하도록 합시다^^

 안녕하세요. 이번에는 최근에 읽은 '아파치 톰캣 7 따라잡기' 책에 대해 정리를 해보도록 하겠습니다. 처음에 회사에 왔을 때 아파치, 톰캣에 대한 지식이 많이 부족해 어려움들을 많이 겪었는데요. 서점에서 우연히 책을 보다가 해당 책의 제목을 발견하고 여전히 부족한 지식을 채우는데 도움이 될 것같아 일치의 망설임 없이 사서 읽게 되었습니다. 읽은지는 한 달정도 됬는데 한 번 읽고 넘기니 내용이 금방 가물가물 해지더라구요. 이참에 정리도 해놓고 틈틈히 보도록 해야겠다는 마음에 정리를 하게 되었습니다.

# 제가 몰랐던 내용이나 좀 더 확고히 하고 싶은 내용들에 대해서만 정리하기에 일목요연하지 못한점 양해 부탁드립니다.

ˇ 톰캣 bin 디렉터리에는 version.sh라는 스크립트가 있는데, 이 스크립트를 이용해 톰캣 버전과 시스템 정보를 확인할 수 있다. 

˚ 스크립트 설정 변경을 확인할 수 있도록 아주 유용한 스크립트 configtest.sh도 제공(톰캣 bin 디렉터리) 한다. configtest.sh 스크립트는 시스템 설정을 검토하고 에러를 찾아낸다. 

˚ 톰캣 설정파일인 conf 내부의 파일들에 대해 알아보자

  - catalina.policy : 톰캣 7의 보안 정책 권한을 설정하는 파일. JVM이 웹 애플리케이션에 어떤 보안 정책 권한을 적용할지를 결정한다.

  - catalina.properties : 이 파일은 서버를 시작할 때 검색하는 서버, 공유로더, JAR 등의 공유 정의를 포함한다.

  - server.xml : 톰캣의 중요 설정 파일 중 하나로 IP 주소, 포트, 가상 호스트, 컨텍스트 경로 등과 같은 중요 정보를 포함한다.

  - tomcat-users.xml : 역할에 기반한 정의에 따라 인증, 승인에 사용하는 파일이다. 이 파일은 데이터베이스의 사용자/암호/역할을 이용한 인증과 컨테이너로 관리되는 보안 구현에 사용된다. 이 파일을 고쳐서 사용자를 추가/삭제하거나 기존 사용자에 역할을 할당/비할당할 수 있다.

  - logging.properties : 톰캣 인스턴스의 로깅 프로퍼티(스타트업 로그 같은)를 정의한다.

  - web.xml : 톰캣 인스턴스가 시작될 때 모든 애플리케이션(톰캣 인스턴스로 로딩되는)의 기본 값을 정의한다. 웹 애플리케이션의 자신만의 배포 디스크립터를 포함하면 기본 디스크립터의 설정을 애플리케이션의 디스크립터의 설정으로 바꾼다.

  - context.xml : 애플리케이션을 실행할 때 이 파일의 내용을 로드한다. context.xml에는 세션 저장, 코밋 연결 추적 등과 같은 설정 파라미터가 있다.

˚ JDBC : 자바 데이터베이스 연결 JDBC, Java Database Connectivity은 자바 기반 데이터베이스 접근 기술로 클라이언트가 서버 데이터베이스에 접근하는데 필요한 API를 제공한다. JDBC는 관계형 데이터베이스에 맞게 만들어졌으며 데이터베이스 질의, 갱신 기능을 제공한다.

˚ JNDI : 자바 네이밍과 디렉터리 인터페이스 JNDI, Java Naming and Directory Interface 서비스는 자바 프로그래밍 언어를 사용해 만들어진 애플리케이션에 네이밍, 디렉터리 기능을 제공하는 자바 플랫폼 API다.

˚ DataSource : JDBC API를 이용해 관계형 데이터베이스에 접근할 때 사용하는 자바 객체다. 

˚ 톰캣의 배포, 설정 과정에서 흔히 발생하는 문제

  1. 

  [ 문 제 ] 

 ˚  사용자가 애플리케이션을 배포한 다음에도 여전히 예전 코드가 보인다고 불평

  [ 해결과정 ] 

 ˚  doc 베이스의 파일이 최근 파일인지 확인한다.

 ˚  톰캣 7의 logs 디렉터리에 있는 catalina.out을 통해 특정 WAR 파일명이 배포되었는지 확인한다

 ˚  이전 두 가지 모두 확인했는데도 문제가 해결되지 않으면 톰캣 서비스를 중지하고 다음 명령어를 이용해 work/Catalina/localhost 디렉터리에 있는 temp 디렉터리의 컨텐츠를 삭제한다. work/Catalina/localhost 디렉터리에 있는 temp 디렉터리의 컨텐츠를 삭제한다.

cd /opt/tomcat/temp

rm -rf ../temp/*

cd /opt/tomcat/work/Catalina/localhost/

rm -rf ../localhost/*
 

 ˚ 톰캣 서비스를 재시작하고 사용자에게 다시 애플리케이션을 확인하도록 한다.

  2.

  [ 문 제 ] 

 ˚ 사용자가 한 노드에서는 현재 배포된 코드를 볼 수 있지만 다른 노드에서는 여전히 예전 코드가 표시된다고 불평

 [ 해결과정 ]

 ˚ doc 베이스의 파일이 최근 파일인지 확인한다.

 ˚ 톰캣 7의 logs 디렉터리에 있는 catalina.cout을 통해 특정 WAR 파일명이 배포되었는지 확인한다.

 ˚ 이전 두 가지 모두 확인했는데도 문제가 해결되지 않으면 node2의 톰캣 서비스를 중지한다. node1의 코드를 복제하도록 설정하고 다음 명령어를 이용해 work/Catalina/localhost 아래의 temp 디렉터리의 컨텐츠를 삭제한다. 

cd /opt/tomcat/temp

rm -rf ../temp/*

cd /opt/tomcat/work/Catalina/localhost/

rm -rf ../localhost/*

 ˚ 톰캣 서비스를 재시작하고 사용자에게 애플리케이션을 확인하도록 한다. 또한 node1과 node2가 복제 모드로 동작하는지 데이터베이스 상태를 확인한다.

 ˚ 양쪽 노드에서 데이터베이스에 연결한다.

  3.

  [ 문 제 ]

 ˚ server.xml을 고친 이후로 톰캣 인스턴스가 실행되지 않는 현상이 발생했다.

  [ 해결 과정 ]

 ˚ 톰캣 bin 디렉토리로 이동한다.

 ˚ configtest.sh를 실행한다.

 ˚ 출력된 내용들 중에 에러 메시지를 보면 톰캣이 이미 실행 중임을 알 수 있다. 따라서 웹 서버를 중지하고 temp 디렉터리를 비운다.

 ˚ 서비스를 다시 시작한다.

˚ 톰캣 7의 커넥터 종류 

 : 커넥터란 요청을 수락하고 응답을 리턴하는 교차점을 가리킨다. 톰캣에는 자바 HTTP 커넥터, 자바 AJP 커넥터, ARP(HTTP/AJP) 커넥터 세 가지 종류의 커넥터가 있다. 애플리케이션은 자신의 요구사항에 맞는 커넥터를 사용한다.

 1. 자바 HTTP 커넥터 

 : HTTP 프로토콜을 기반으로 하는 자바 HTTP 커넥터는 HTTP/1.1 프로토콜만 지원한다. 톰캣은 자바 HTTP 커넥터를 이용해 독립형standalone 웹 서버로 동작 할 수 있으며, jsp/서블릿 호스트 기능도 제공할 수 있다.

 2. 자바 AJP 커넥터

 : 자바 AJP 커넥터는 AJP(아파치 JServ 프로토콜)와 AJP를 통한 웹 서버 통신을 기반으로 한다. 자바 서블릿 컨테이너를 인터넷에 노출하고 싶지 않을 때 AJP 커넥터를 사용(다른 프론트엔트 서버를 이용)하며 톰캣 7에서 SSL 터미네이션을 처리하지 않는 상황이라면 AJP 커넥터를 매우 유용하게 활용할 수 있다. AJP 구현 예제로 mod_jk, mod_proxy 등이 있다.

 3. APR(AJP/HTP) 커넥터

 : ARP(Apache Portable Runtime)은 확장성, 성능, 다른 웹 서버와의 협력 작업 상황에서 능력을 발휘한다. 

오늘 정리는 여기서 마치도록 하고 정리 하지 못한 내용은 part.2로 포스팅하도록 하겠다.

 안녕하세요. 오늘 포스팅 주제는 'POP3 수동 접속하기'입니다. 그에 앞서서 간단히 POP3에 대해 설명하고 수동 접속하는 방법에 대해 알아보도록 하겠습니다. 포스팅을 하게 된 배경은 고객들이 고객센터 페이지를 통해서 문의를 넣는 경우가 아닌 직접 담당자에게 메일을 써서 문의를 넣는 경우가 있는데 이 메일들을 문의를 처리해주는 시스템에서 확인 할 수 있도록 메일의 내용을 불러와 확인 할 수 있어야 합니다. 허나 기획 쪽으로부터 특정 메일에 오는 문의들을 제대로 못 불러 간다는 문의가 있었습니다. 이에 실제로 서버에서 telnet을 통해 해당 메일의 서버에서 해당 메일 ID로 문의들을 잘 가져오는지 확인하는 작업이 필요했습니다. 먼저 간단히 POP3에 대해 살펴보도록 하겠습니다.

1. POP3 ( Post Office Protocol3 )란???

지식백과를 참고해 보자면 단순히 메일 클라이언트가 메일을 사용자 자신의 PC로 다운로드할 수 있도록 해주는 프로토콜이라고 설명되어 있습니다. 좀 더 지식백과의 내용을 살펴보자면 현재 대부분의 메일 서버에서는 POP3을 사용하고 있으며 사용자는 주기적으로 서버에 있는 자신의 메일 수신함을 점검하고, 만약 수신된 메일이 있으면 클라이언트 쪽으로 다운로드한다. 메일을 수신하는 프로토콜에는 POP3와 IMAP(Internet message access protocol)가 있는데, IMAP은 서버에 직접 접속해 메일을 관리하는데 비해 POP3은 메일 서버에 있는 메일을 자신의 컴퓨터로 가져와 관리한다는 차이가 있다.

 -네이버 지식백과 

 지식백과의 내용을 보면 어느 정도 이해를 하실 수 있으리라 믿습니다. 쉽게 말해 우리가 지금 사용하고 있는 네이버 메일 같은 경우에도 POP3를 지원하고 있는데 우리가 보내는 메일들이 네이버의 메일 서버에 쌓이게 됩니다. 우리는 네이버 페이지에 로그인을 하고 메일함으로 가게 될 경우 내게 온 메일들에 대해 확인할 수 있습니다. 이 때 메일을 보기 위해 해당 메일을 클릭하면 나의 수신함으로 전체 내용이 pop3프로토콜에 의해 다운받아지게 됩니다. 반면 IMAP(Internet Message Access Protocol)는 메일을 클릭해서 볼 때마다 해당 네이버  메일 서버에 접속해서 보게 되는 것입니다. 따라서 POP3는 메일함에서 지우면 영원히 지워지지만, IMAP은 메일을 지워도 해당서버에는 그대로 남아있게 됩니다.

2. POP3에 수동 접속하기 (메일 설정)

 내게 오는 메일들을 다른 클라이언트에서도 가져가 확인할 수 있게 하기 위해서는 메일 설정이 필요합니다. 말 그대로 네이버 메일 서버에서 내 메일 ID로 접속해서 다른 클라이언트에서도 가져가 확인할 수 있도록 허용해줘야 합니다.

1)그림을 보면 1번 톱니바퀴 모양을 누릅니다. 

2)그 후 옆을 보면 POP3/IMAP 설정을 볼 수 있습니다. 클릭합니다.

3)클릭을 하면 밑에 POP3을 설정할 수 있는 부분이 있고 본인이 사용하고자 하는 설정에 맞게 설정해주고 '확인'을 눌러줍니다.

4)그 밑을 보면 POP 서버에 접속할 수 있는 정보들이 뜹니다.

3. POP3 수동으로 접속하기

메일의 설정을 하고 난 후 TELNET을 통해 접속해 보도록 하겠습니다.

1) 먼저 서버에서 해당 POP서버에 접속을 합니다.

 telnet POP3서버주소 110  (네이버 pop3 서버에 접속할 경우 'telnet pop.naver.com 110' 을 입력해 주시면 되겠습니다.) 

2) 위 처럼 접속하게 되면 정상적으로 연결이 된경우 CONNECTED라는 문구를 보실 수 있습니다. 그 후 서버에서 내 메일 계정 아이디와 비밀번호를 입력해 서버에서 내 메일 스토리지로 접근을 해야 합니다.

 USER hongildong3@naver.com 

 PASS ***********

하게 되면 밑의 그림과 같은 화면을 볼 수 있습니다.

3) 그 후 LIST 라는 명령어를 치시게 되면 내가 메일에서 설정을 한 이후에 새로 온 메일들의 리스트를 볼 수 있습니다.

4) 특정 메일의 내용을 보고 싶을 경우 LIST를 했을 때 나온 번호를 참고해 'RETR 번호' 를 통해 메일 내용 모두 (헤더와 본문 모두)를 확인 할 수 있습니다.

그림은 번호가 4번인 메일의 내용을 확인하는 사진입니다.

4. 추가적인 POP3 명령어

   STAT - 도착한 메일의 갯수와 총 용량

   TOP 메일번호 - 지정한 크기만큼 보여주기 (헤더와 본문을 통틀어 지정한 메일의 줄수만큼 보여준                              다.

   UIDL - 모든 메일에 고유번호 붙이기

   UIDL 메일번호 - 낱개 단위의 메일에 고유번호 알아내기

   REST - 새로고침

   DELE 메일번호 - 도착한 메일 삭제

   QUIT - 접속종료

부족한 내용이 있거나 잘 못된 내용이 있으면 댓글로 피드백 부탁 드립니다.

이상으로 오늘의 포스팅을 마치도록 하겠습니다.

 안녕하세요. 오늘은 전에 특정 서비스를 기존 빌드 서버에서 다른 빌드 서버로 이전하는 작업을 진행하면서 경험했던 삽질에 대해서 얘기해보도록 하겠습니다. 해당 서비스는 jdk1.7로 빌드가 되어야 하는데 옮기는 서버에는 jdk1.7이 아닌 jdk1.6이 깔려있어 서버에 jdk1.7을 설치하면서 겪었던 에로사항들에 대해 지금부터 포스팅하도록 하겠습니다.

1. 문제 상황

 해당 빌드 서버에 프로젝트를 이전하고 빌드를 수행했는데 다음과 같은 에러가 떴다. 살펴보니 서버와 해당 프로젝트 jdk버전이 맞지 않았던 것이다. (프로젝트 jdk1.7 서버 jdk1.6이 설치된 상황) 따라서 문제를 해결하기 위해 서버에 jdk1.7을 설치해야 하는 상황이었다. 

2. wget을 이용한 jdk1.7다운 그리고 또 다른 문제 발생

 jdk1.7 다운로드 페이지에 가서 wget을 하기 위한 url을 얻어와 서버에서 당연하게 wget http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz 을 수행했다. 하지만 문제는 다음 그림과 같았다.

 빨간색 라인을 보면 해당 명령어를 수행했고 그 결과 나는 노란색 네모 상자와 같은 에러문구를 받게 되었다. 

ERROR: certificate common name `www.oracle.com' doesn't match requested host name `edelivery.oracle.com'.

To connect to edelivery.oracle.com insecurely, use `--no-check-certificate'. Unable to establish SSL connection.

 3. 문제 해결

 월 초(15.01)에 현재 팀에 분산 되어 있는 빌드 및 CI 서버 통합 작업을 진행하였다. 이번 포스팅은 서버 통합 작업을 하다가 발생한 java.lang.OutOfMemoryError: PermGen space문제에 대해 알아보도록 하겠다. 먼저 첫 번째로 문제가 발생한 현상에 대해 살펴보고 둘 째, 어떻게 해결했는지 살펴보고 마지막 셋째, java.lang.OutOfMemoryError: PermGen space에 대해 자세히 알아보자.

 1. 서버 작업 중 발생한 현상

 기존 서버에서 빌드 되는 프로젝트들도 많았지만 (약 50개 정도) 해당 부분에 대해서는 많은 문제가 되지 않았다. 왜냐하면 여러 프로젝트(10개 이상)가 동시에 빌드 작업을 진행하는 경우는 제로에 가까웠기 때문이다. 문제는 특정 소스코드가 수행되었을 때 자동으로 빌드되 commit_build와 특정 시간 간격마다 수행되게 하는 배치 빌드 등을 추가하면서 부터 발생하였다. 처음에는 서버 통합작업을 잘 진행하고 있었는데 어느 순간 부터(c_build, i_build)가 여러 개 추가되는 시점부터 서버가 뻗어버리는 현상이 발생하였다. 

 다음 그림과 같이 java.lang.OutOfMemoryError: PermGen space 에러가 발생한 것을 볼 수 있다. 이로 인해 서버가 뻗어 버리는 현상이 주기적(약1시간 간격)으로 나타났다. 그래서 일차적으로 주기적으로 빌드 되는 프로젝트들에 대해 주기적으로 빌드 되지 않도록 작업하였다.

  2. 해결한 방법

먼저 해결책을 말하자면 해당 서버의 톰캣/bin catalina.sh 에 들어가서 밑의 그림과 같이 추가해주었다.

그림이 잘 안보인다 ㅠㅠ 아무튼

 JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MaxPermSize=512m -XX:-UseConcMarkSweepGC"

를 선언해주어 해결하였다. (기존에는 -XX:MaxPermSize가 선언되어 있지 않았다. (기본 20m로 설정되있다고 한다)

# -XX:+UseConcMarkSweepGC

 // 표준 garbage collector가 아닌 perm gen도 gc하는 concurrent collector를 사용하도록 한다.

# -XX:+CMSPermGenSweepingEnabled

 // perm gen 영역도 gc의 대상이 되도록 한다.

# -XX:+CMSClassUnloadingEnabled

// 클래스 데이타도 gc의 대상이 되도록 한다.

# -XX:MaxPermSize=64m

// 어느정도 크기가되어야 gc가 자주 발생하지 않는다. 기본값이 8M인듯.

  3. java.lang.OutOfMemoryError: PermGen space 관련 정보들에 대해 알아보자. (두서 없이 정리됨을 양해바람)

# java.lang.OutOfMemoryError: PermGen space문제는 기본적으로 동적 클래스를 많이 사용할 경우 빈번히 발생하는 문제로 JSP->SERVLET 변화. SPIRNG에서의 동적 클래스를 많이 사용하는 프레임워크로 인해 발생한다.

# JVM이 새로운 클래스 정의를 로드해야 하는데 이를 수행하기 위한 PerGen 공간이 충분하지 않아 발생한다. 즉, 이미 너무 많은 클래스들이 로딩되어 있으며 서버가 현재 크기의 PermGen이 처리할 수 없을 만큼 많은 클래스들을 사용하고 있기 때문이기도 하다. 

# 보통 Java heap이나 힙의 특정 영역에 객체를 할당 할 수 있는 공간이 충분하지 않을 때 발생

# PermGen space 라는 메시지는 permanent generation 이 가득 찬 상태라는 것을 알려준다. permanent generation은 클래스와 메쏘드 객체가 저장되는 힙의 영역을 나타낸다. 어플리케이션이 많은 수의 클래스를 로드하면, -XX:MaxPermSize 옵션을 사용하여 permanent generation의 크기를 증가시킬 필요가 있다. 

# 보통 톰캣을 사용하다가 이 에러를 보았다면 대체로 웹 어플리케이션을 너무 많이 Update 하거나 Reload 한 것이 원인이 될 수 있다. 톰캣과 JVM은 웹 어플리케이션을 삭제하고 다시 생성할 때 할당한 모든 메모리를 해제하지는 않는다. 톰캣을 여러 번 리로드 하면 할당된 메모리가 바닥나서 동작하지 않게 된다. 

# 톰캣에서 이 에러가 발생했을 경우 해결 방법은 1. 톰캣을 재시작 하는 것(임시적으로 해결) 2. 톰캣이 할당할 수 있는 메모리를 늘려 준다. 3. 메모리 누수가 발생하지 않도록 톰캣을 설정 (불필요한 프로젝트 들이 로딩되지 않도록 정리)

# Heap은 프로그램이 돌아가는 도중에 생성 삭제되는 곳으로 garbage-collected가 일어나는 곳이며 Permenant는 프로그램이 끝날 때까지 영원히 메모리를 차지하고 있는 공간으로 garbage-collected가 일어나지 않는 곳이다. Heap에는 동적으로 생기는 메모리 들이 들어가는 곳이고, Permenanat는 Class names, Internalized strings, Objects 등이 들어가며 PermGen도 이곳에 해당한다. 

참조 :

http://mindasom.tistory.com/96

http://jwchoi85.tistory.com/155#recentComments