달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2014. 8. 11. 11:24

[펌] Tomcat 튜닝 이야기. I.lib()/I.lib(Tomcat)2014. 8. 11. 11:24

.. .. ..

 

[펌] : http://bcho.tistory.com/788

 

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

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

 

가정

여기서 튜닝 하는 톰캣은 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등에서 기술 지원을 제공한다.

.
:
Posted by .07274.
2014. 8. 7. 10:33

톰켓(Tomcat) 로그 포맷 I.lib()/I.lib(Tomcat)2014. 8. 7. 10:33

.. .. ..

.

톰켓 로그 포멧은 아래와 같다.

 

[한글]

%a - 원격 IP 주소
%A - 로컬 IP 주소
%b - Bytes sent,excluding HTTP headers, or '-' if zero
%B - Bytes sent, excluding HTTP headers
%h - 원격 호스트 이름 (호스트가 잘못된 경우 IP 주소)
%H - 요청 프로토콜
%l - 인증시 원격 논리적 유저명.(언제나 '-'를 리턴함)
%m - 요청 메서드 (GET, POST, etc.)
%p - 요청시 접근한 Local port
%q - 쿼리 스트링(요청 파라미터?).
%r - 요청의 첫번째 라인 (메서드와 요청 URI)
%s - 응답 HTTP 상태 (200, 404 등)
%S - 사용자 세션 id
%t - 공통 로그 포멧에 맞는 날짜와 시간값
%u - 인증되었을 경우 원격 사용자.(아닐시에는 '-')
%U - 요청된 URL 경로
%v - 로컬 서버 이름
%D - 요청을 처리한 시간 (밀리세컨)
%T - 요청을 처리한 시간 (초)
%I - 현재 요청한 쓰레드 이름(차후 스텍 트레이스에 사용가능)

[영어]

%a - Remote IP address
%A - Local IP address
%b - Bytes sent, excluding HTTP headers, or '-' if zero
%B - Bytes sent, excluding HTTP headers
%h - Remote host name (or IP address if resolveHosts is false)
%H - Request protocol
%l - Remote logical username from identd (always returns '-')
%m - Request method (GET, POST, etc.)
%p - Local port on which this request was received
%q - Query string (prepended with a '?' if it exists)
%r - First line of the request (method and request URI)
%s - HTTP status code of the response
%S - User session ID
%t - Date and time, in Common Log Format
%u - Remote user that was authenticated (if any), else '-'
%U - Requested URL path
%v - Local server name
%D - Time taken to process the request, in millis
%T - Time taken to process the request, in seconds
%I - Current request thread name (can compare later with stacktraces)

.
:
Posted by .07274.
.. .. ..

[펌] : http://devhome.tistory.com/64

 

 

TOMCAT SSL 적용

JDK에 포함된 keytool을 이용하여 Tomcat에 SSL을 적용하는 방법을 소개한다.

1. JDK bin 폴더라 이동한다.

- %JAVA_HOME%\bin

Ex) Win7의 경우 'C:\Program Files (x86)\Java\jdk1.6.0_32\bin' 경로에 존재한다. - 버전에 따라 상이

2. JDK를 이용해 Tomcat 인증서를 생성한다.

- keytool -genkey -alias tomcat -keyalg RSA

3. 생성된 .keystore 파일 확인

- 사용자 홈 폴더에 .keystore 파일이 생성되어 있음

- Ex) Win7의 경우 'C:\Users\사용자계정\.keystore' 위치에 생성되어 있음

4. Tomcat server.xml 설정

1.<connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="${user.home}/.keystore" keystorePass="passwd" clientAuth="false" sslProtocol="TLS"></connector>

5. Tomcat 시작 및 SSL 적용확인

- https로 개발된 페이지를 접근해 보면됨

- Ex) https://localhost:8443

 

.
:
Posted by .07274.
.. .. ..

*Web 서버를 Tomcat에 설정하는 방법. (For Eclipse)

보통 서버의 개발서버나 실서버는 모두 APACHE 와 TOMCAT으로 구동이 된다.
그래서 APACHE 에는 htdocs 가 들어가고 TOMCAT 에는 IAIPWebApp 가 들어가게 된다.
하지만 개발중인 Eclipse 상에서는 Tomcat만 설정되고 Apache 가 설정되지 않기 때문에
임시방편으로 Eclipse 의  Tomcat의 server.xml 파일에는
아래와 같이 설정을 해준다.

<Host appBase="htdocs" autoDeploy="true" name="localhost" unpackWARs="true" xmlNamespaceAware="false" xmlValidation="false">
      <Context docBase="htdocs" path="/" reloadable="true" source="org.eclipse.jst.jee.server:htdocs"/>
      <Context docBase="IAIPWebApp" path="/iaip" reloadable="true" source="org.eclipse.jst.jee.server:IAIPWebApp"/>
</Host>

Host 의 appBase는 설정을 안해주어도 상관이 없고
Context의 docBase와 path 을 주의하여 설정하면 된다.

.
:
Posted by .07274.
2011. 7. 28. 11:40

8009 포트 설정 I.lib()/I.lib(Tomcat)2011. 7. 28. 11:40

.. .. ..
tomcat도 아파치 튜닝처럼 운영하면서 최적의 설정값을 찾아내야 합니다.
apache의 80포트로는 접속이 잘 안되는데, tomcat이 사용하는 8080 포트로는 해당 페이지가 잘 열리는지 살펴보세요.
아주 예전에 이런 경험이 있어 설정 변경을 했습니다.

다음은 TOMCAT 홈/conf/server.xml 의 일부 default 설정입니다.
(2004.중순 tomcat 5.0.x의 기준입니다. 오래됐네요. ^^)

코드:

<Connector port="8080"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />

<Connector port="8009"
enableLookups="false" redirectPort="8443" debug="0"
protocol="AJP/1.3" />


위에서 8080으로 쓰이는 connector의 thread 설정 튜닝과
8009포트를 사용하는 AJP connector의 KeepAlive on/off와 Min/Max process 개수 등의 설정이 필요합니다.
thread 설정을 약간 늘려보시구요, AJP connector의 maxKeepAliveRequests는 off로 하고 process개수를 변경해보세요.
80은 접속이 잘 안되고, 8080은 된다면 다음 설정이 효과가 있을겁니다. 설정값은 님이 직접 튜닝하시구요.

코드:

<Connector port="8080"
maxThreads="300" minSpareThreads="75" maxSpareThreads="150"
enableLookups="false" redirectPort="8443" acceptCount="250"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />

<Connector port="8009"
enableLookups="false" redirectPort="8443" debug="0"
maxKeepAliveRequests="-1" minProcessors="150" maxProcessors="500"
protocol="AJP/1.3" />


MaxKeepAliveRequests = 일정 시간동안 클라이언트가 요청한 값을 넘어가면 자식 프로세스는 죽고 다른 자식프로세스가 처리하는 것입니다.

MaxRequestsPerChild = 아파치 웹서버의 자식프로세스들이 클라이언트의 요청 개수를 지정한다. 만약 자식프로세스가 이 값만큼의 클라이언트요청을 받았다면 이 자식프로세스는 자동으로 죽게된다

두개다 어느 정도의 값을 지나게 되면 자식프로세스는 죽게 된다는 것입니다... 두개의 차이점이 무엇인가요..???

보통
MaxKeepAliveRequests 는 100 MaxRequestsPerChild 30입니다

.
:
Posted by .07274.
.. .. ..
Catalina.out 파일이 기하급수적으로 쌓이는 문제가 생겨서
하루에 한번씩 지우는 방법을 찾아보는데

결론은 불가능 하다~! Tomcat 이 종일 Catalina.out 파일을 잡고 살기 때문에
빌어먹을것이 불가능 하다는 것이다( 설정상으로..)

우회 방법은 아래와 같은 좋은 글이 있어 들고 왔다.

[펌] http://tenny.egloos.com/1226439

우선, 톰켓 로그 설정법은

이런 곳 http://tomcat.apache.org/tomcat-5.5-doc/logging.html

그리고 또 이런 곳에 잘 나와있다. http://minaret.biz/tips/tomcatLogging.html

하지만, 이런 곳에는 http://tomcat.apache.org/faq/logging.html

톰켓은 기본적으로 catalina.out 파일을 rotate하지 않는다고 한다.
톰켓 입장에서는 당신이 로깅패키지를 쓰면 되기 때문에 문제가 없다고 하는데,,, 글쎄다...
어떻게든 로그가 계속 쌓이는 것은 막아야하지 않겠는가... ( 정말 쉬운 방법이 있으면 가르침을 주시면 참 고마울 것 같다)

System.out and System.err both print to catalina.out. But you can suppress this via the swallowOutput property and sent to different log files.
catalina.out does not rotate. But it should not be an issue because nothing should be printing to standard output since you are using a logging package, right? a thread about rotation of catalina.out



방법1. cronolog 로테이트 로깅 프로그램 사용

http://marc.info/?l=tomcat-user&m=105645816302666&w=2

방법2. log4j 사용

http://minaret.biz/tips/tomcatLogging.html


첫 번째 방법은 패키지 설치가 귀찮아서 안해봤고, 두 번째 방법을 해보니, 로깅은 되는데, catalina.out은 계속 쌓이는 듯 하다. 뭔가 설정을 잘못한 것일 수도 있지만, 분석을 해봐도 뜻대로 catalina.out에 로깅이 중단되지는 않았다.

해보지는 않았지만, pipe 처리를 해서 rotate를 완전 다른 프로세스에게 넘기는 첫번째 방법이 더 쉬워보이기는 한다. 하지만 이 역시, 톰켓을 kill할 때, 가끔 cronolog가 혼자 살아있다는 bug report 가 있기는 하다.


이제 귀찮고 해서, shell script를 만들고 crontab에 넣어 버렸더니, 잘되기는 한다.

rotateTomcatLog.sh

#!/bin/sh

LOG_DIR=/tomcat/log/dir
DATE=`/bin/date +%Y-%m-%d`

/bin/nice /bin/cp $LOG_DIR/catalina.out $LOG_DIR/catalina.$DATE.out
/bin/nice /bin/cat /dev/null > $LOG_DIR/catalina.out
rm -Rf $LOG_DIR/*.log


#
# delete out-of-date catalina.log
#

DELETE_DATE=`/bin/date +%Y-%m-%d --date '20 day ago'`
#DELETE_DATE`/bin/date +Y-%m-%d --date '1 month ago'`

echo "$LOG_DIR/catalina.$DELETE_DATE.out"

for file in $LOG_DIR/*
do
if [[ "$file" < "$LOG_DIR/catalina.$DELETE_DATE.out" ]]
then
rm -f $file
fi
done

# end of file

위 스크립트는 cataline.out 하루에 한 번씩 rotate하고, backup 파일은 20일 동안 보관한다.
뭐 취향에 맞게 바꿔써도 무방할 것 같지만, 괜하게 log를 copy하는 부하가 맘에 걸린다.

/etc/logrotate.d/ 밑의 설정처럼 rotate도 하면서 backup 파일 보관 기간까지 설정하면서,
날짜와 크기 제한까지 같이 두는 설정이 있으면 좋겠다.
(log4j는 날짜로 로테이트하면서, 크기 제한까지 두지는 못하는 것 같다.)


.
:
Posted by .07274.
.. .. ..

서버에 기본적으로 접근하는 주소들 (ex.10.12.120.217  신규 1서버) 은 Apache 로 들어가게 되며 80포트로 접근하게 된다.
이때 jsp 파일같은 경우는 Tomcat으로 보내서 Tomcat이 처리하게 하는데 중요한건
Apache와 Tomcat을 연결해줘야 둘이 호환한다는 것.

     1. apache2/conf/httpd.conf 파일을 열어서 mod_jk.conf 라는 파일을 import 해준다.
           
  include conf/mod_jk.conf
     2. apache2/conf/mod_jk.conf 파일을 만들어 준다.
               
LoadModule    jk_module  modules/mod_jk.so
JkWorkersFile "/usr/local/web/apache2/conf/workers.properties"
JkShmFile    "/usr/local/web/apache2/bin/mod_jk.shm"
JkLogLevel    info
#JkLogFile  "|/usr/local/web/apache2/bin/rotatelogs /usr/local/web/apache2/logs/mod_jk_log.%Y%m%d 86400"
JkLogFile "logs/mod_jk.log"
JkOptions  +ForwardKeySize +ForwardURICompatUnparsed -ForwardDirectories

## Mount Configuration
JkMount /*.jsp node1
#JkMount /*.do node1
JkMount /servlet/* node1


    3. mod_jk.conf 파일에 프로퍼티 파일인 /apache2/conf/workers.properties 파일을 만들어준다.
   
            ###################################
               ## [ Define Round Robin 2 worker using ajp13 ]
               ###################################
               worker.list=node1,jkstatus                     #node1 이라는 놈을 만든다.

               ###################################
               ## 0. Define loadbalancer
               ###################################
               ## 1. Set properties for worker (ajp13)
               ## worker.list=node1
               ###################################
               worker.node1.type=ajp13                #Apache 와 Tomcat 이 asp13 프로토콜과 주고받는타입.               
               worker.node1.host=127.0.0.1
               worker.node1.port=8009                        #node1의 포트. 이건 tomcat의 포트를 의미한다.
               worker.node1.lbfactor=1                       #로드 벨런싱 관련 프로퍼티.
               worker.node1.socket_timeout=300          
               worker.node1.socket_keepalive=False

               ## Do not use cachesize with values higher then 1 on Apache 2.x prefork or Apache 1.3.x
               ## Its default value (eq. connection_pool_minsize) is (connection_pool_size+1)/2
               worker.node1.connection_pool_size=1
               worker.node1.connection_pool_minsize=1
               worker.node1.connection_pool_timeout=60

               worker.jkstatus.type=status



※ 혹시 Version 이 바뀌어 mod_jk 이 정상작동하지 않을시(Log를 보면 확인가능) 아파치 사이트에서 mod_jk 관련 문서를 받아서 설정값을 살펴보도록 한다.


위와같이 했다면 연결이 끝났다~! 이제 Apache를 Restart시킨다. 그리고 웹에 접근하면 첫화면이야 잘나오겠지만
실제 jsp가 Tomcat 과 연동지 않는것을 알수있다. 이부분은 Tomcat 에 필요한 웹 서비스가 Context로 등록되지 않았기 때문이다. Tomcat 의 administration 에서 tomcat server/Service /Host/Context 에 필요로 하는 웹 서비스가 있는지 확인하고 없다면 등록하면 된다.

.
:
Posted by .07274.