Tomcat 무분별하게 catalina.out 크기 커지는것 막기

기존에 작성했던 [이곳]의 글은 catalina.out 파일을 쓰지 못하게 하여 중복 로깅을 못하게 하는 방법이었습니다.
실제로 톰캣은 catalina.<날짜>와 catalina.out 두개의 파일을 로깅하고 있어 퍼포먼스에 조금 신경이 쓰이는 부분이었습니다.

기존의 글을 토대로 catalina.out을 제거하였다고 쳐도 admin이나 localhost같은 특이한 로그 파일이 자꾸 늘어나는것도 신경이 조금 쓰이더군요.

톰캣의 conf 디렉토리 안에있는 logging.properties 안의 내용을 다음과 같이 수정하여 봅시다.

위의 내용을 제외한 나머지는 모두 주석처리 해버리면 catalina.<날짜> 형태의 로그 외에는 모두 기록하지 않습니다.

개발환경이 아닌 단순 서비스 환경에서는 이렇게 로그를 최소화 하는것이 좋겠네요.

1catalina.org.apache.juli.FileHandler.level 의 값을 조정하여 로그 레벨을 정의할수도 있습니다.

——————————————————————————————————

일 단. 톰캣로그를 날짜별로 남기는 녀석이 누구인가 알아보니. tomcat6.0 conf디렉토리에 있는 logging.proerties파일에 정의된 *..org.apache.juli.FileHandler클래스들이다. 이 녀석들은 콘솔출력과 별개로 날짜별로 로그파일을 생성한다. 즉, 콘솔출력을 catalina.out으로 저장하는 부분만 막으면 문제는 해결된다.

org.apache.catalina.startup.Bootstrap “$@” start >> /dev/null 2>&1 &
#      org.apache.catalina.startup.Bootstrap “$@” start \
#      >> “$CATALINA_BASE”/logs/catalina.out 2>&1 &

위와 같이 catalina.sh를 바꾸어주면 된다. 이런곳이 2군데 있다.

—————————————————————————————————-

cronolog라는 놈을 www.cronolog.org 에 가서 다운받는다.

 

설치방법
* root 로 설치해야 한다.
./configure
make
make install

 

그런다음 catalina.sh 파일을 수정한다.
.
.
.
.
  shift
touch “$CATALINA_BASE”/logs/catalina.out
if [ “$1” = “-security” ] ; then
echo “Using Security Manager”
shift
“$_RUNJAVA” $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=”$JAVA_ENDORSED_DIRS” -classpath “$CLASSPATH” \
-Djava.security.manager \
-Djava.security.policy==”$CATALINA_BASE”/conf/catalina.policy \
-Dcatalina.base=”$CATALINA_BASE” \
-Dcatalina.home=”$CATALINA_HOME” \
-Djava.io.tmpdir=”$CATALINA_TMPDIR” \
     org.apache.catalina.startup.Bootstrap “$@” \
start |/usr/local/sbin/cronolog “$CATALINA_BASE”/logs/catalina.out.%y%m%d >> /dev/null 2>&1 &
#      org.apache.catalina.startup.Bootstrap “$@” start \
#      >> “$CATALINA_BASE”/logs/catalina.out 2>&1 &
     if [ ! -z “$CATALINA_PID” ]; then
echo $! > $CATALINA_PID
fi
else
“$_RUNJAVA” $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=”$JAVA_ENDORSED_DIRS” -classpath “$CLASSPATH” \
-Dcatalina.base=”$CATALINA_BASE” \
-Dcatalina.home=”$CATALINA_HOME” \
-Djava.io.tmpdir=”$CATALINA_TMPDIR” \
     org.apache.catalina.startup.Bootstrap “$@” \
start |/usr/local/sbin/cronolog “$CATALINA_BASE”/logs/catalina.out.%y%m%d >> /dev/null 2>&1 &
#      org.apache.catalina.startup.Bootstrap “$@” start \
#      >> “$CATALINA_BASE”/logs/catalina.out 2>&1 &
.
.
.
.
start 포함해서 한줄에 작성해야 한다.
기존 문장은 주석처리 하든 지우던 하공…
그리고, shutdown.sh를 이용해 톰캣을 죽일때
cronolog도 같이 죽지만,
때에 따라 안죽는 경우도 있으니
ps 명령을 이용해 죽었는지 확인해야한다.
ps -ef cronolog

—————————————————————————————————

# Configuration of Web log
#log4j.rootLogger=DEBUG,console,INFO, web
#log4j.rootLogger = INFO, stdout
#핸들러의 로깅레벨은 SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL 이 있습니다

log4j.rootLogger=CONSOL , DEBUG , ERROR , SYSTEM , WARN , WEB
log4j.appender.CONSOL=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOL.Append=true
log4j.appender.CONSOL.ImmediateFlush=true
log4j.appender.CONSOL.Threshold=INFO
log4j.appender.CONSOL.DatePattern=’.’yyyy-MM-dd
log4j.appender.CONSOL.MaxFileSize=20MB
log4j.appender.CONSOL.MaxBackupIndex=10

#Layout 형식 : TTCCLayout, HTMLLayout,  XMLLayout, PatternLayout, SimpleLayout
#PatternLayout, SimpleLayout – 자바의 Throwable 에러들과 예외를 무시한다
log4j.appender.CONSOL.layout=org.apache.log4j.PatternLayout

 

#소스코드의 위치정보를 출력한다. %C. %M(%F:%L) 의 축약형이다 / %d %-5p [%t] %-17c{2} (%13F:%L) %3x – %m%n
log4j.appender.CONSOL.layout.ConversionPattern=[%-5p] %d{HH:mm:ss} [%c] [time: %r] – %m%n

 

# 로그파일 경로.
#log4j.appender.CONSOL.File=C:/javadev/develop/logs/mmsgw_web/
#log4j.appender.CONSOL.File=C:/egovframeworkSample/workspace/mmsgw_web/WebContent/WEB-INF/classes/logs
log4j.appender.CONSOL.File={catalina.home}/logs/tomcat.consol.log

 

#[%d{yyyy-MM-dd}형식은 프로그램의 실행속도를 느리게 함으로 SimpleDateFormat 형식지정한다
log4j.appender.CONSOL.layout.DateFormat=ISO8601

 

#[YYYY-MM-DD HH:MM:SS, mm] 형식을 뜻한다.
log4j.appender.CONSOL.layout.TimeZoneID=GMT-8:00

 

 

 
#매일 자정에 로그파일을 교체하며 기존파일은 xx.log_2004.07.12  org.apache.log4j.ConsoleAppender , DailyRollingFileAppender
log4j.appender.SYSTEM=org.apache.log4j.RollingFileAppender
log4j.appender.SYSTEM.Append=true
log4j.appender.SYSTEM.DatePattern=’.’yyyy-MM-dd
log4j.appender.SYSTEM.Threshold=INFO
log4j.appender.SYSTEM.ImmediateFlush=true
log4j.appender.SYSTEM.MaxFileSize=20MB
log4j.appender.SYSTEM.MaxBackupIndex=10

#자바의 Throwable 에러들과 예외를 포함하기 위해 HTMLLayout을 사용한다.
log4j.appender.SYSTEM.layout=org.apache.log4j.PatternLayout

#[%d{yyyy-MM-dd}형식은 프로그램의 실행속도를 느리게 함으로 SimpleDateFormat 형식지정한다
log4j.appender.SYSTEM.layout.DateFormat=ISO8601

#[YYYY-MM-DD HH:MM:SS, mm] 형식을 뜻한다.
log4j.appender.SYSTEM.layout.TimeZoneID=GMT-8:00

#소스코드의 위치정보를 출력한다. %C. %M(%F:%L) 의 축약형이다 / %d{HH:mm:ss} %5p (%C{2} – %M:%L) – %m%n
#log4j.appender.SYSTEM.layout.ConversionPattern=[%d] %-5p %l – %m%n
#log4j.appender.SYSTEM.layout.ConversionPattern=[%-5p] %d{HH:mm:ss} [%c] [time: %r] – %m%n
log4j.appender.SYSTEM.layout.ConversionPattern=%d{dd-MM-yy HH:mm:ss:SSS} – {%p} %c{2} Thread [%t]; %x %m%n

# 로그파일 경로.
#log4j.appender.SYSTEM.File=C:/javadev/develop/logs/mmsgw_web/
#log4j.appender.SYSTEM.File=C:/egovframeworkSample/workspace/mmsgw_web/WebContent/WEB-INF/classes/logs
log4j.appender.SYSTEM.File={catalina.home}/logs/tomcat.stdout.log

 

 

 

log4j.appender.WEB=org.apache.log4j.RollingFileAppender
log4j.appender.WEB.File=${catalina.home}/logs/tomcat.web.log
#log4j.appender.WEB.File=${catalina.home}/logs/
log4j.appender.WEB.MaxFileSize=20MB
log4j.appender.WEB.MaxBackupIndex=10
log4j.appender.WEB.layout=org.apache.log4j.PatternLayout
log4j.appender.WEB.layout.ConversionPattern=%p %t %c – %m%n
#log4j.appender.WEB.layout.ConversionPattern=[%-5p] %d{HH:mm:ss} [%c] [time: %r] – %m%n
#log4j.logger.org.apache.catalina=DEBUG, R

 

log4j.logger.org.apache.catalina.core=INFO
log4j.logger.org.apache.catalina.session=INFO
log4j.logger.org.apache.jasper.compiler=INFO

 

 

출처 : http://yaku.tistory.com/135

첫번째 참고
tomcat 튜닝 – outofmemory
http://www.javastudy.co.kr/javastudy/new_bbs/qna_view.jsp?bbs_name=lecbasicbbs&theid=364&pageNum=1

이것도 참고.
http://kr.sun.com/developers/tech_docs/wireless_web06/wireless02.html

* Sun Microsystyems의 자바 HotSpot VM은 힙을 세 개의 영역으로 나누고 있다.
힙의 세 영역은 다음과 같다:
1) Permanent space: JVM 클래스와 메소드 개체를 위해 쓰인다.
2) Old object space: 만들어진지 좀 된 개체들을 위해 쓰인다.
3) New(young) object space: 새로 생성된 개체들을 위해 쓰인다.

* Heap layout 할당에 영향을 주는 스위치들
명령행 스위치 설명
————-|——-
-Xms=[n]  최소 heap size
-Xmx=[n]  최대 heap size
-XX:PermSize=[n]  최소 perm size
-XX:MaxPermSize=[n]  최대 perm size
-XX:NewSize=[n]  최소 new size
-XX:MaxNewSize=[n]  최대 new size
-XX:SurvivorRatio=[n]  New/survivor 영역 비율
-XX:newratio=[n]  Old/new 영역 비율. HotSpot 클라이언트 VM은 8, HotSpot 서버 VM은 2.
-XX:TargetSurvivorRatio=[n]  GC동안 비울 생존자 수용 가능량 퍼센티지 (capacity percentage.) 초기값은 50%

* New Generation 메모리 할당 공식
Eden = NewSize – ((NewSize/(SurvivorRatio + 2)) * 2)
From space = (NewSize – Eden)/2
To space = (NewSize – Eden)/2
* Old Generation 메모리 할당 공식
Old = Xmx – MaxNewSize

* GC한 상태의 Heap메모리 정보출력
jdk1.4에서 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

* 정적페이지가 많을 때
-Xms418m -Xmx418m
-XX:PermSize=1024m
-XX:MaxPermSize=1024m
-XX:NewSize=290m
-XX:MaxNewSize=290m
-XX:SurvivorRatio=3

* 동적인 페이지가 많을 때
-Xms1024m -Xmx1024m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:NewSize=800m
-XX:MaxNewSize=800m
-XX:SurvivorRatio=4

-Xms384m -Xmx384m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=3

출처 : http://gamadeus.tistory.com/145?srchid=BR1http%3A%2F%2Fgamadeus.tistory.com%2F145

두번째 참고
 이것은 동시접속 성능 개선을 위한 톰캣 튜닝 방법

è Tomcat설정 변경 : Server.xml

 

maxThreads=”1024″ minSpareThreads=”126″ maxSpareThreads=”512″

enableLookups=”false” redirectPort=”8888″ acceptCount=”100″

connectionTimeout=”5000″ disableUploadTimeout=”true” />

 

 

è WEB-INF\classes\SqlMapConfig.xml

 

lazyLoadingEnabled=”true” maxRequests=”2048″ maxSessions=”512″

maxTransactions=”1024″ useStatementNamespaces=”false” />

 

 

è JVM Heap Memory 설정 : Startup.bat

set JAVA_OPTS= -Xms512m -Xmx1024m -MaxPermSize=128m

 

 

è AdmPoolFactory.java

GenericObjectPool.Config getDefaultConfig(){

GenericObjectPool.Config config=new GenericObjectPool.Config();

config.maxIdle=32;

config.minIdle=8;

config.maxActive=128;

config.testOnBorrow=true;

return config;

}

  출처 : http://lkhstory.blogspot.com/2010/08/tomcat.html

세번째 위에것들 참고하여 본인이 작업한거.
(
작업결과 속도개선에는 위 방법이 별 효과가 없는 듯)

참고 : http://www.webpagetest.org (웹 페이지 속도테스트 사이트)

user 프로파일을 다음과 같이 변경 하였음.
이건 머 catalina.sh에 해도 되고. startup.sh에 해도 되고 본인이 하고 싶은곳에 환경설정 하면 되는 것임.
export JAVA_OPTS=”-Xms1024m -Xmx1024m -XX:MaxPermSize=128m”
뒤에 MaxPermSize 는 앞에 -XX:  이렇게 붙여줘야 됨.

본인은 apache mod_jk를 이용하여 AJP 커넥션을 사용함
– 톰캣 설정에서는 다음과 같이 minSpareThreads, maxSpareThreads, acceptCount 추가 하였음. maxThreads 는변경
<Connector port=”8110″
enableLookups=”false”
redirectPort=”8513″
debug=”0″
protocol=”AJP/1.3″
URIEncoding=”UTF-8″
maxThreads=”512″
minSpareThreads=”128″
maxSpareThreads=”256″
acceptCount=”100″
connectionTimeout=”600000″
                                disableUploadTimeout=”true” />

tomcat 관련 설정 내용 참고 : http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html

– 참고로 아파치의 workers.properties 설정 부분(이쪽은 머 기존 설정에서 건드린게 없습니다.)
worker.nipa_worker1.type=ajp13
worker.nipa_worker1.host=210.10.10.56
worker.nipa_worker1.port=8110
worker.nipa_worker1.lbfactor=1
worker.nipa_worker1.connect_timeout=5000
worker.nipa_worker1.prepost_timeout=5000
worker.nipa_worker1.socket_keepalive=True
worker.nipa_worker1.socket_timeout=10
worker.nipa_worker1.connection_pool_timeout=600

apache mod_jk 관련 설정 내용 참고 : http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html

본인의 설정이 전부 맞다고 생각하시면 안되고 저는 이렇게 했다는 것입니다.
참고만 하세요.
아직도 저는 고생중이랍니다. 앞으로도 쭈욱~~ 완벽하게 세팅하는 그날까지.
혹여나 이눔의 톰캣때문에 고생하시는 분들이 있으실까봐 부족하나마 남겨봅니다.

요래저래 찾는중에 위에 두 블로거님께 감사드립니다.

 

출처 : http://deve.tistory.com/category/apache-tomcat

[Original Document]

 

 

신세대 Heap
JDK 1.4.1에서 heap은 신세대, 구세대,
영구세대(Permanent generation)의 3단계로 나눠진다.
신세대는 또한 Eden과 Semi-spaces로 나뉜다. Eden과
semi-spaces의 크기는 SurvivorRatio(생존률)에 의해 조정되며 다음과 같이 계산할 수 있다.

Eden = NewSize – ((NewSize / ( SurvivorRatio
+ 2)) * 2)
From space = (NewSize – Eden) / 2
To space = (NewSize – Eden) /
2

NewSize는 신세대의 크기이며 -XX:NewSize 옵션을 사용해 지정할 수 있다.
SurvivorRatio는 정수이며 1부터 매우 높은 값까지 가능하다. 신세대의 크기는 다음 옵션을 사용해 조절할 수 있다.

-XX:NewSize
-XX:MaxNewSize
-XX:SurvivorRatio

예를 들어 128MB의 신세대에서 64MB를 Eden에, 32MB를
Semi-Space에 할당하고자 하면 NewSize와 MaxNewSize, SurvivorRatio의 값을 다음과 같이 명시할 수 있다.

java -Xms512m -Xmx512m -XX:NewSize=128m
-XX:MaxNewSize=128m \
-XX:SurvivorRatio=2 application


구세대 Heap

구세대 또는 Tenured
Generation는 신세대에서 승진한 오래된 객체를 가지고 있다. -Xms 매개변수를 사용해서 구세대의 최대 크기를 조정할 수
있다.
앞서 예를 보다 확장해서 256MB의 구세대 heap과 256MB의 신세대를 -mx 변수를 사용해서 지정할 수 있다.

java -Xms512m -Xmx512m -XX:NewSize=256m
-XX:MaxNewSize=256m \
-XX:SurvivorRatio=2
application

신세대가 256MB를 사용하고 구세대가 다른 256MB를 사용한다. -Xms를 사용해서 초기 heap 크기를
지정했다.

 

 

영구세대의 Heap
영구세대(Permanent
generation)는 클래스 객체와 그 관련 메타 정보를 저장하는 데에 사용된다. 기본 크기는 4MB이며 -XX:PermSize와
-XX:MaxPermSize 옵션을 사용해 설정할 수 있다.
종종 로그 파일에서 Full GC를 볼 수 있을 텐데, 이것은 영구세대를
확장할 때 생기는 것이다. 이런 현상은 -XX:PermSize와 -XX:MaxPermSize 옵션을 사용해서 영구세대의 heap을 크게 잡으면
막을 수 있다. 예를 들어 다음과 같이 해보자.

java -Xms512m -Xmx512m -XX:NewSize=256m
-XX:MaxNewSize=256m \
-XX:SurvivorRatio=2 -XX:PermSize=64m
-XX:MaxPermSize=64m application

영구세대의 컬렉션을 비활성화시키는 방법은 -Xnoclassgc 옵션을 사용하는 것이다.
이 옵션은 클래스 객체를 컬렉션하지 못하게 하기 때문에 조심해서 사용해야 한다. 이를 사용하기 위해서는 GC가 일어나지 않을 정도로 클래스
객체를 저장할 수 있는 영구세대의 크기를 크게 잡으면 된다. 예를 들어 다음과 같이 한다.

java -Xms512m -Xmx512m -XX:NewSize=256m
-XX:MaxNewSize=256m \
-XX:SurvivorRatio=2 -XX:PermSize=128m
-XX:MaxPermSize=128m \
-Xnoclassgc
application
 
 
기본 사용법
Java 애플리케이션은 다음 명령어로 실행될 수 있다.

java application

기본적으로 신세대에서 Eden은 2MB, Semi-space는 64KB가 잡혀 있다.
구세대 heap은 5MB로 시작해서 44MB까지 확장된다. 영구세대의 기본 크기는 4MB이다.

-Xms와 -Xms 스위치
사용하기

구세대의 기본 heap 크기는 -Xms와 -Xmx를 사용해서 초기값 및 최대 크기값을 변경할 수 있다.

java -Xms <initial size> -Xmx
<maximum size> program

예를 들면 다음과 같다.

java -Xms128m -Xmx512m
application

:XX 스위치를 사용해 새로운 Low Pause 또는 Throughput
Collector 사용하기

·Low Pause Collector 사용하기
신세대에서는
-XX:+UseParNewGC 옵션을 사용해 Parallel Copying Collector를 활성화시킬 수 있으며, 구세대에서는 -XX:
+UseConcMarkSweepGC를 사용해 Concurrent Collector를 활성화시킬 수 있다. 예를 들면 다음과 같다.

java -server -Xms512m -Xmx512m
-XX:NewSize=64m -XX:MaxNewSize=64m \
-XX:SurvivorRatio=2 -XX:+
UseConcMarkSweepGC \
-XX:+UseParNewGC application

다만 -XX:+UseParNewGC가 명시되지 않았으면 신세대는 기본적으로
Copying Collector(http://wireless.java.sun.com/ midp/articles/garbage/참조)를 사용하게
될 것이다. 또한 단일 CPU 시스템에서 -XX+UseParNewGC가 명시되지 않았다면 CPU의 개수가 1개이기 때문에 기본인 Copy
Collector가 사용된다. 병렬의 정도를 증가시켜 Parallel Copy Collector를 활성화시킬 수
있다.

– 병렬의 정도를 조정하기
기본적으로 Parallel Copy Collector는 CPU 개수만큼의
쓰레드를 생성해 사용하지만 병렬의 정도를 조정해야 한다면 다음과 같이 변경할 수 있다.

-XX:ParallelGCThreads=<desired
parallelism>

기본값은 CPU 개수와 동일하다. 예를 들어 신세대의 컬렉션이 4개의 병렬 쓰레드를
사용하기 위해선 다음과 같다.

java -server -Xms512m -Xmx512m
-XX:NewSize=64m -XX:MaxNewSize=64m \
-XX:SurvivorRatio=2 -XX:+UseParNewGC
-XX:ParallelGCThreads=4 \
-XX:+UseConcMarkSweepGC application


– JDK 1.4.1에서 ‘promoteall’ 변경자
모방하기

‘promoteall’ 변경자는 JDK 1.2.2에서 신세대의 모든 유효한 객체를 구세대로 별도의 과정 없이 곧바로
승진시킨다. JDK 1.4.1에는 ‘promoteall’ 변경자가 없지만 보유분포(tenuring distribution)를 조정해서 비슷한
현상을 만들 수 있다. MaxTenuringThreshold 옵션을 통해 신세대에 있는 객체가 노화되는 횟수를 조정한다. 이 옵션을 0으로
설정하면 곧바로 구세대로 승진되는 것이다. SurvivorRatio는 20000 또는 그 이상의 높은 값으로 설정해서 신세대 Heap 크기 중
Eden이 대부분 사용하게 한다.

-XX:MaxTenuringThreshold=0
-XX:SurvivorRatio=20000

예를 들면 다음과 같다.

java -server -Xms512m -Xmx512m
-XX:NewSize=64m -XX:MaxNewSize=64m \
-XX:SurvivorRatio=20000
-XX:MaxTenuringThreshold=0 \
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
application


Concurrent Collection 초기화
조정하기

Concurrent Collector의 백그라운드 쓰레드는 구세대의 공간 활용 비율이 기본적으로 68%인,
-XX:CMSInitiatingOccupancy Fraction보다 높으면 시작하게 된다. 이 값은 변경할 수 있으며, 다음 옵션을 사용해서
Concurrent Collector를 더 빨리 실행시킬 수
있다.

-XX:CMSInitiatingOccupancyFraction=<percent>

예를 들면 다음과
같다.

java -server -Xms512m -Xmx512m -XX:NewSize=64m -XX:MaxNewSize=64m
\
-XX:SurvivorRatio=20000 -XX:MaxTenuringThreshold=0 \
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC \
-XX:CMSInitiatingOccupancyFraction=35
application

·Throughput Collector 사용하기
신세대에서 -XX:UseParallelGC
옵션을 사용해서 Parallel Scavenge Collector를 활성화시킬 수 있다. 구세대는 기본적으로 Mark-Compact
Collector을 사용하기 때문에 명시할 필요가 없다.

32비트일 때:
java -server -Xms3072m -Xmx3072m
-XX:NewSize=2560m \
-XX:MaxNewSize=2560m XX:SurvivorRatio=2
\
-XX:+UseParallelGC application64비트일 때:
java -server -d64
-Xms8192m -Xmx8192m -XX:NewSize=7168m \
-XX:MaxNewSize=7168m
XX:SurvivorRatio=2 \
-XX:+UseParallelGC application

단, -XX:TargetSurvivorRatio는 신세대에서 보유하고 있는 객체를
복사하는 데에 사용되는 보유한계이다. 큰 heap과 SurvivorRatio가 2이면 TargetSurvivorRatio의 기본값이 50이기
때문에 survivor semi-space가 낭비될 수 있다. 이 값을 75나 90으로 조정하면 공간 활용이 극대화될
것이다.


– 병렬 정도 조정하기

Parallel Scavenge Collector 또한 CPU 개수만큼
쓰레드를 생성해 사용하지만 병렬의 정도를 조정해야 한다면 다음과 같이 변경할 수 있다.

-XX:ParallelGCThreads=<desired
parallelism>

기본값은 CPU의 개수와 동일하다. 예를 들어 신세대 컬렉션을 처리하는 데에 4개의
병렬 쓰레드를 사용하기 위해선 다음과 같이 하면 된다.

java -server -Xms3072m -Xmx3072m
-XX:NewSize=2560m \
-XX:MaxNewSize=2560m XX:SurvivorRatio=2
\
-XX:+UseParallelGC -XX:ParallelGCThreads=4
application


– 성능을 위한 적응형 크기 조절

Parallel
Scavenge Collector는 -XX:+UseAdaptiveSizePolicy를 사용할 때 성능이 더 좋다. 신세대의 크기를 자동으로
조정하고 최대 성능을 위한 최적화된 생존률을 설정해준다. Parallel Scavenge Collector는 항상
-XX:UseAdaptiveSizePolicy 옵션을 사용하는 게 좋다. 예를 들면 다음과 같다.

java -server -Xms3072m -XX:+UseParallelGC
\
-XX:+UseAdaptiveSizePolicy
application

 

 

 

 

출처 : http://blog.daum.net/bluelinu/8247868