톰캣 튜닝

조대협

 

이번에는 톰캣 서버에 대한 튜닝 옵션에 대해서 한번 알아보자.

애플리케이션 관점에서의 튜닝도 중요하지만, 각 솔루션에 대한 특성을 업무 시나리오에 맞춰서 튜닝하는 것도 못지 않게 중요하다. 여기서 톰캣 튜닝을 설명하는 것은 톰캣 자체에 대한 튜닝 옵션을 소개하는 것도 목적이 있지만, 그보다 업무형태에 따라서 어떠한 접근을 해서 톰캣을 튜닝하는지를 소개하기 위함이다.

 

가정

여기서 튜닝 하는 톰캣은 HTTP/JSON형태의 REST 형태로 서비스를 제공하는 API 서버의 형태이다. 여러대의 톰캣을 이용하여 REST 서비스를 제공하며, 앞단에는 L4 스위치를 둬서 부하를 분산하며, 서비스는 stateless 서비스로 공유되는 상태 정보가 없다. 

server.xml 튜닝

톰캣의 대부분 튜닝 패러미터는 ${Tomcat_HOME}/conf/server.xml 파일에 정의된다.

몇몇 parameter를 살펴보도록 하자.

 

Listener 설정

 <Listener className=”org.apache.catalina.security.SecurityListener” checkedOsUsers=”root” /> 

이 옵션은 tomcat이 기동할 때, root 사용자이면 기동을 하지 못하게 하는 옵션이다. 서버를 운영해본 사람이라면 종종 겪었을 실수중의 하나가application server를 root 권한으로 띄웠다가 다음번에 다시 실행하려고 하면 permission 에러가 나는 시나리오 이다. root 권한으로 서버가 실행되었기 때문에, 각종 config 파일이나 log 파일들의 permission이 모두 root로 바뀌어 버리기 때문에, 일반 계정으로 다시 재 기동하려고 시도하면, config 파일이나 log file들의 permission 이 바뀌어서 파일을 읽어나 쓰는데 실패하게 되고 결국 서버 기동이 불가능한 경우가 있다. 이 옵션은 이러한 실수를 막아 줄 수 있다.

 

Connector 설정

 

protocol=”org.apache.coyote.http11.Http11Protocol”

먼저 protocol setting인데, Tomcat은 네트워크 통신하는 부분에 대해서 3가지 정도의 옵션을 제공한다. BIO,NIO,APR 3 가지이다. NIO는 Java의 NIO 라이브러리를 사용하는 모듈이고, APR은 Apache Web Server의 io module을 사용한다. 그래서 C라이브러리를 JNI 인터페이스를 통해서 로딩해서 사용하는데, 속도는 APR이 가장 빠른것으로 알려져 있지만, JNI를 사용하는 특성상, JNI 코드 쪽에서 문제가 생기면, 자바 프로세스 자체가 core dump를 내면서 죽어 버리기 때문에 안정성 측면에서는 BIO나 NIO보다 낮다. BIO는 일반적인 Java Socket IO 모듈을 사용하는데, 이론적으로 보면 APR > NIO > BIO 순으로 성능이 빠르지만, 실제 테스트 해보면 OS 설정이나 자바 버전에 따라서 차이가 있다. Default는 BIO이다.

 

acceptCount=”10″

이 옵션은 request Queue의 길이를 정의한다. HTTP request가 들어왔을때, idle thread가 없으면 queue에서 idle thread가 생길때 까지 요청을 대기하는 queue의 길이이다. 보통 queue에 메세지가 쌓였다는 것은 해당 톰캣 인스턴스에 처리할 수 있는 쓰레드가 없다는 이야기이고, 모든 쓰레드를 사용해도 요청을 처리를 못한다는 것은 이미 장애 상태일 가능성이 높다.

그래서 큐의 길이를 길게 주는 것 보다는, 짧게 줘서, 요청을 처리할 수 없는 상황이면 빨리 에러 코드를 클라이언트에게 보내서 에러처리를 하도록 하는 것이 좋다. Queue의 길이가 길면, 대기 하는 시간이 길어지기 때문에 장애 상황에서도 계속 응답을 대기를 하다가 다른 장애로 전파 되는 경우가 있다.

순간적인 과부하 상황에 대비 하기 위해서 큐의 길이를 0 보다는 10내외 정도로 짧게 주는 것이 좋다.

 

enableLookups=”false”

톰캣에서 실행되는 Servlet/JSP 코드 중에서 들어오는 http request에 대한 ip를 조회 하는 명령등이 있을 경우, 톰캣은 yahoo.com과 같은 DNS이름을 IP주소로 바뀌기 위해서 DNS 서버에 look up 요청을 보낸다. 이것이 http request 처리 중에 일어나는데, 다른 서버로 DNS 쿼리를 보낸다는 소리이다. 그만큼의 서버간의 round trip 시간이 발생하는데, 이 옵션을 false로 해놓으면 dns lookup 없이 그냥 dns 명을 리턴하기 때문에, round trip 발생을 막을 수 있다.

 

compression=”off”

HTTP message body를 gzip 형태로 압축해서 리턴한다. 업무 시나리오가 이미지나 파일을 response 하는 경우에는  compression을 적용함으로써 네트워크 대역폭을 절약하는 효과가 있겠지만, 이 업무 시스템의 가정은, JSON 기반의 REST 통신이기 때문에, 굳이 compression을 사용할 필요가 없으며, compression에 사용되는 CPU를 차라리 비지니스 로직 처리에 사용하는 것이 더 효율적이다.

 

maxConnection=”8192″

하나의 톰캣인스턴스가 유지할 수 있는 Connection의 수를 정의 한다.

이 때 주의해야 할 점은 이 수는 현재 연결되어 있는 실제 Connection의 수가 아니라 현재 사용중인 socket fd (file descriptor)의 수 이다. 무슨 말인가 하면 TCP Connection은 특성상 Connection 이 끊난 후에도 바로 socket이 close 되는 것이 아니라 FIN 신호를 보내고, TIME_WAIT 시간을 거쳐서 connection을 정리한다. 실제 톰캣 인스턴스가 100개의 Connection 으로 부터 들어오는 요청을 동시 처리할 수 있다하더라도, 요청을 처리하고 socket이 close 되면 TIME_WAIT에 머물러 있는 Connection 수가 많기 때문에, 단시간내에 많은 요청을 처리하게 되면 이TIME_WAIT가 사용하는 fd 수 때문에, maxConnection이 모자를 수 있다. 그래서 maxConnection은 넉넉하게 주는 것이 좋다.

이외에도 HTTP 1.1 Keep Alive를 사용하게 되면 요청을 처리 하지 않는 Connection도 계속 유지 되기 때문에, 요청 처리 수 보다, 실제 연결되어 있는 Connection 수가 높게 된다.

그리고, process당 열 수 있는 fd수는 ulimit -f 를 통해서 설정이 된다. maxConnection을 8192로 주더라도, ulimit -f에서 fd 수를 적게 해놓으면 소용이 없기 때문에 반드시 ulimit -f 로 최대 물리 Connection 수를 설정해놔야 한다.

 

maxKeepAliveRequest=”1″

HTTP 1.1 Keep Alive Connection을 사용할 때, 최대 유지할 Connection 수를 결정하는 옵션이다. 본 시나리오에서는 REST 방식으로Connectionless 형태로 서비스를 진행할 예정이기 때문에, Kepp Alive를 사용하지 않기 위해서 값을 1로 준다.

만약에 KeepAlive를 사용할 예정이면, maxConnection과 같이 ulimit에서 fd수를 충분히 지정해줘야 하낟.

 

maxThread=”100″

사실상 이 옵션이 가장 중요한 옵션이 아닌가 싶다. 톰캣내의 쓰레드 수를 결정 하는 옵션이다. 쓰레드수는 실제 Active User 수를 뜻한다. 즉 순간 처리 가능한 Transaction 수를 의미한다.

일반적으로 100 내외가 가장 적절하고, 트렌젝션의 무게에 따라 50~500 개 정도로 설정하는 게 일반적이다. 이 값은 성능 테스트를 통해서 튜닝을 하면서 조정해 나가는 것이 좋다.

 

tcpNoDelay=”true”

TCP 프로토콜은 기본적으로 패킷을 보낼때 바로 보내지 않는다. 작은 패킷들을 모아서 버퍼 사이즈가 다 차면 모아서 보내는 로직을 사용한다. 그래서 버퍼가 4K라고 가정할때, 보내고자 하는 패킷이 1K이면 3K가 찰 때 까지 기다리기 때문에, 바로바로 전송이 되지 않고 대기가 발생한다.

tcpNoDelay 옵션을 사용하면, 버퍼가 차기전에라도 바로 전송이 되기 때문에, 전송 속도가 빨라진다. 반대로, 작은 패킷을 여러번 보내기 때문에 전체적인 네트워크 트래픽은 증가한다. (예전에야 대역폭이 낮아서 한꺼번에 보내는 방식이 선호되었지만 요즘은 망 속도가 워낙 좋아서tcpNoDelay를 사용해도 대역폭에 대한 문제가 그리 크지 않다.)

 

Tomcat Lib 세팅

다음으로 자바 애플리케이션에서 사용하는 라이브러리에 대한 메모리 사용률을 줄이는 방법인데, 일반적으로 배포를 할때 사용되는 라이브러리(jar)를 *.war 패키지 내의 WEB-INF/jar 디렉토리에 넣어서 배포 하는 것이 일반적이다. 보통 하나의 war를 하나의 톰캣에 배포할 때는 큰 문제가 없는데, 하나의 톰캣에 여러개의 war 파일을 동시 배포 하게 되면, 같은 라이브러리가 각각 다른 클래스 로더로 배포가 되기 때문에, 메모리 효율성이 떨어진다.

그래서 이런 경우는 ${TOMCAT_HOME}/lib 디렉토리에 배포를 하고 war 파일에서 빼면 모든 war가 공통 적으로 같은 라이브러리를 사용하기 때문에 메모리 사용이 효율적이고, 또한 시스템 운영 관점에서도 개발팀이 잘못된 jar 버전을 패키징해서 배포하였다 하더라도, lib 디렉토리의 라이브러리가 우선 적용되기 때문에, 관리가 편하다.

반대로 war의 경우, war만 운영중에 재배포를 하면 반영이 가능하지만, lib 디렉토리의 jar 파일들은 반드시 톰캣 인스턴스를 재기동해야 반영되기 때문에, 이 부분은 주의해야 한다.

 

JVM Tuning

Java Virtual Machine 튜닝은 java 기반 애플리케이션에서는 거의 필수 요소이다.

-server

제일 먼저 해야할일은 JVM 모드를 server 모드로 전환하는 것이다. JVM 내의 hotspot 컴파일러도 클라이언트 애플리케이션이나 서버 애플리케이션이냐 에 따라서 최적화 되는 방법이 다르다.

그리고 메모리 배치 역시 클라이언트 애플리케이션(MS 워드와같은)의 경우 버튼이나 메뉴는 한번 메모리에 로드 되면, 애플리케이션이 끝날 때 까지 메모리에 잔존하기 때문에 Old 영역이 커야 하지만, 서버의 경우 request를 받아서 처리하고 응답을 주고 빠져서 소멸되는 객체들이 대부분이기 때문에, New 영역이 커야 한다.

이런 서버나 클라이언트냐에 대한 최적화 옵션이 이 옵션 하나로 상당 부분 자동으로 적용되기 때문에, 반드시 적용하기를 바란다.

 

메모리 옵션

앞에서도 설명하였듯이 JVM 튜닝의 대부분의 메모리 튜닝이고 그중에서도 JVM 메모리 튜닝은 매우 중요하다. 결국 Full GC 시간을 줄이는 것이 관건인데, 큰 요구 사항만 없다면, 전체 Heap Size는 1G 정도가 적당하다. 그리고 New대 Old의 비율은 서버 애플리케이션의 경우 1:2 비율이 가장 적절하다. 그리고 PermSize는 class가 로딩되는 공간인데, 배포하고자 하는 애플리케이션이 아주 크지 않다면 128m 정도면 적당하다. (보통256m를 넘지 않는다. 256m가 넘는다면 몬가 애플린케이션 배포나 패키징에 문제가 있다고 봐야 한다.)

그리고 heap size는 JVM에서 자동으로 늘리거나 줄일 수 가 있다. 그래서 -Xms와 -Xmx로 최소,최대 heap size를 정할 수 있는데, Server 시스템의 경우 항상 최대 사용 메모리로 잡아 놓는 것이 좋다. 메모리가 늘어난다는 것은 부하가 늘어난다는 것이고, 부하가 늘어날때 메모리를 늘리는 작업 자체가 새로운 부하가 될 수 있기 때문에, 같은 값을 사용하는 것이 좋다.

이렇게 JVM 메모리를 튜닝하면 다음과 같은 옵션이 된다.

-Xmx1024m –Xms1024m -XX:MaxNewSize=384m -XX:MaxPermSize=128m

이렇게 하면 전체 메모리 사용량은 heap 1024m (이중에서 new가 384m) 그리고 perm이 128m 가 되고, JVM 자체가 사용하는 메모리가 보통300~500m 내외가 되서 java process가 사용하는 메모리 량은 대략 1024+128+300~500 = 대략 1.5G 정도가 된다.

 

32 bit JVM의 경우 process가 사용할 수 있는 공간은 4G가 되는데, 이중 2G는 시스템(OS)이 사용하고 2G가 사용자가 사용할 수 있다. 그래서 위의 설정을 사용하면 32bit JVM에서도 잘 동작한다.

64 bit JVM의 경우 더 큰 메모리 영역을 사용할 수 있는데, 일반적으로 2G를 안 넘는 것이 좋다.(최대 3G), 2G가 넘어서면 Full GC 시간이 많이 걸리기 시작하기 때문에, 그다지 권장하지 않는다. 시스템의 가용 메모리가 많다면 Heap을 넉넉히 잡는 것보다는 톰캣 인스턴스를 여러개 띄워서 클러스터링이나 로드밸런서로 묶는 방법을 권장한다.

 

OutOfMemory

자바 애플리케이션에서 주로 문제가 되는 것중 하나가 Out Of Memory 에러이다. JVM이 메모리를 자동으로 관리해줌에도 불구하고, 이런 문제가 발생하는 원인은 사용이 끝낸 객체를 release 하지 않는 경우이다. 예를 들어 static 변수를 통해서 대규모 array나 hashmap을 reference 하고 있으면, GC가 되지 않고 계속 메모리를 점유해서 결과적으로 Out Of Memory 에러를 만들어낸다.

Out Of Memory 에러를 추적하기 위해서는 그 순간의 메모리 레이아웃인 Heap Dump가 필요한데, 이 옵션을 적용해놓으면, Out Of Memory가 나올때, 순간적으로 Heap Dump를 떠서 파일로 저장해놓기 때문에, 장애 발생시 추적이 용이하다.

-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid<pid>.hprof

 

GC 옵션

다음은 GC 옵션이다. Memory 옵션 만큼이나 중요한 옵션인데, Parallel GC + Concurrent GC는 요즘은 거의 공식처럼 사용된다고 보면 된다. 이때 Parallel GC에 대한 Thread 수를 정해야 하는데, 이 Thread수는 전체 CPU Core수 보다 적어야 하고, 2~4개 정도가 적당하다.

-XX:ParallelGCThreads=2 -XX:-UseConcMarkSweepGC

GC 로그 옵션

그리고 마지막으로 GC Log 옵션이다. 서버와 JVM이 건강한지 메모리상 문제는 없는지 GC 상황은 어떻게 디는지를 추적하려면 GC 로그는 되도록 자세하게 추출할 필요가 있다. GC로그를 상세하게 걸어도 성능 저하는 거의 없다.

-XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps -XX:-TraceClassUnloading -XX:-TraceClassLoading

 

마지막에 적용된 TraceClassLoading은 클래스가 로딩되는 순간에 로그를 남겨준다. 일반적으로는 사용하지 않아도 되나, OutOfMemory 에러 발생시 Object가 아니라 class에서 발생하는 경우는 Heap dump로는 분석이 불가능 하기 때문에, Out Of Memory 에러시 같이 사용하면 좋다.

 

지금까지 간략하게 나마 톰켓 솔루션에 대한 튜닝 parameter 에 대해서 알아보았다. 사실 이러한 튜닝은 일반적인 개발자에게는 힘든 일이다. 해당 솔루션에 대한 많은 경험이 있어야 하기 때문에, 이런 parameter는 vendor의 기술 지원 엔지니어를 통해서 가이드를 받고, 성능 테스트 과정에서 최적화를 하고 표준화된 parameter를 정해서 사용하는 것이 좋다. Apache Tomcat의 경우에도 오픈소스이기는 하지만, Redhat등에서 기술 지원을 제공한다.

 

Apache Tomcat Tuning Guide

 

출처: <http://bcho.tistory.com/category/%EC%84%B1%EB%8A%A5%EA%B3%BC%20%ED%8A%9C%EB%8B%9D/WAS%20%ED%8A%9C%EB%8B%9D>

 

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