WAS 시스템 설정 기준을 제시하라 Enjoy/etc2008. 10. 24. 18:35
출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard_pdf.php&bo_table=article&page=3&wr_id=913&publishdate=20030401
이상훈 | sanghoone@lgcns.com
J2EE Working Group의 간사로 활동하고 있으며, KM 활동의 일환으로 사내 K-Village SUN 전문가 포럼의 아키텍처 스터디에서 돌쇠(?) 역할을 하고 있다. 개인적으로는 프로덕트 라인 엔지니어링과 스쿠버 다이빙, 인라인 스케이팅, 스노우 보드에 관심이 많다.
다음은 K회사 WAS 관리자와 PM과의 대화내용이다.
WAS 관리자 : WAS 설정 값을 좀 변경하는 게 좋을 것 같습니다.
PM : 왜?
WAS 관리자 : 일부를 좀 바꿔보았더니 성능이 좋아지는 것 같아서요.
PM : 벤더가 왔을 때도 그냥 디폴트(Default)로 설정하라고 했잖아. 설정 바꾸지 말고 디폴트로 설정해! 문제 생기면 책임질꺼야?
WAS 관리자 : @.@
앞의 WAS 관리자와 PM의 대화가 비현실적이었으면 하지만 누구나 경험할 수 있는 안타까운 현실이다. 지난해 J2EE Working Group(이하 J2EE-WG)의 고민도 바로 ‘J2EE 기반의 WAS (Web Application Server) 설정에 대한 불명확성’이었으며, 이를 해결하고자 한 해를 보냈다.
J2EE의 주요 기술이 은행, 이동통신사업 등과 같이 대규모의 시스템에 적용되기 위해서는 시스템 성능에 대한 안정성이 필요하다. 그러나 성능 안정화 및 성능 향상을 위한 튜닝은 실제 프로젝트 팀보다 WAS 벤더에 의존적으로 수행되고 있는 경우가 많고, 개인적인 경험을 토대로 행해지기 때문에 개인의 능력에 따라 성능이 좌우되는 문제점이 제기되고 있다. 이에 J2EE-WG은 성능 안정화를 위한 시스템 성능 향상에 영향을 줄 수 있는 요소들을 선정하고, 각 요소에 대한 국내 J2EE 기반 WAS 벤더의 권고사항을 기초로 하여 성능 향상을 위한 고려사항들을 정리했다.
시스템 성능 향상을 위해서는 업무 모델링, 데이터 모델링, 네트워크, 하드웨어 등 각종 인프라스트럭처, 애플리케이션 아키텍처 등 모든 기본 요소가 업무 특성에 따라 종합적으로 고려되어야 하지만, J2EE-WG은 1차적으로 J2EE의 기반 구조를 제공해주는 ‘WAS 성능 향상을 위한 고려사항’을 제시하고자 한다(차후 기회가 되면 이런 기본 요소에 대한 부분도 다루도록 하겠다).
성능 향상을 위한 고려사항 선정
성능 향상을 위한 고려사항들은 J2EE 기반 시스템 구축 경험이 있는 J2EE-WG 회원들을 중심으로 선정되었다. 이러한 요소들은 현장에서 대부분 디폴트로 설정되고 있으며, 설정 변경보다는 시스템 용량(CPU, 메모리 등)을 늘리게 하는 주요 이슈들이다. 다음의 질문에 대한 각 벤더별 답변 내용의 주요 골자를 보며 고려되어야 할 사항들을 살펴보자(각 벤더의 답변 내용 중 오해의 소지가 있는 부분은 영문 그대로 실는다. 또한 각 벤더별 답변 원문은 ‘이달의 디스켓’을 참고하기 바란다).
짾 EJB 컨테이너 설정
짿 Deployment Descriptor 설정
쨁 패키징(packaging) 설정
쨂 트랜잭션 유형 설정
쨃 커넥션 풀링(connection pooling) 설정
쨄 기타 성능 향상 요소
EJB 컨테이너 설정
하나의 WAS에 여러 개의 컨테이너를 띄워서 시스템을 운영하는 경우가 많은데, 이때 각 컨테이너가 차지하는 시스템 리소스의 규모로 인해 컨테이너 설정이 전체적인 시스템 성능에 영향을 주고 있다. 컨테이너 설정을 어떻게 최적화해 운영·유지할 것인지 정확하게 입증하는 것은 중요한 이슈라고 생각된다. 컨테이너 수를 어떻게 결정하는지, 각 컨테이너는 어떻게 설정할 것인지 등에 대한 적정한 지표가 없어, 설정값이 대부분 디폴트로 설정되거나 벤더 기술 지원 인력의 주관적 경험에 의존해 결정되고 있다. 또한 업무 특성이 고려되지 않은 기술적인 접근은 실제 운영에 있어 예상치 못한 문제들을 발생시킬 수 있다. 기본 값이 아닌 다른 값으로 설정했을 때 발생될 수 있는 영향 혹은 문제점들에 대한 명확한 가이드라인의 부재로 인해, 업무 특성을 고려한 설정을 하려고 해도 어쩔 수 없이 디폴트로 운영하는 경우가 많다.
Q1. 컨테이너의 적정 개수 산정과 관련된 고려 사항
오라클 컨테이너에 있어 처리 가능한 트랜잭션 수는 시스템 리소스에 따라 많이 달라지며, 실제로는 최대로 수행 가능한 JVM 쓰레드의 수가 의미를 지닌다. 쓰레드 풀 사이즈의 설정을 통해 제어(공식적인 자료로는 ECperf 결과를 활용할 수 있다).
BEA 기본적으로 인스턴스 <= # of CPU(현재 1머신에서 8개인 인스턴스까지 사용하는 예가 있다)
IBM 케이스 1. 관련 EJB를 여러 개의 컨테이너에 분산시켜서 전개
- 성능적/비용적 측면에서 볼 때, 성능적 이점은 없이 JVM에 대한 프로세스 오버헤드만 존재할 뿐이다.
케이스 2. 모든 EJB를 하나의 컨테이너에 전개시키고 컨테이너를 복수 개로 클로닝(cloning)
- EJB 컨테니어에만 해당되는 특별한 고려사항은 없다.
- 웹 컨테이너 클러스터링시 개수 산정과 관련된 고려 사항과 같다.
썬 기본적으로 한 시스템 당 한 개의 컨테이너를 권장한다.
Q2. 복수의 컨테이너를 운용해야 할 경우 개수의 정확한 정의를 위해 제시하고 있는 권장사항
IBM 복수 개의 컨테이너 운용 목적 중에는 성능, 확장성, 신뢰성 등의 향상을 들 수 있다. 한 개의 머신에서 복수 개의 컨테이너를 운용하는 것에 대해선 대용량 시스템이어야 한다는 대전제를 필요로 한다. 특히 필요에 의한 복수의 컨테이너 운용은 업무별로 애플리케이션 서버를 분리해 운영하고자 하는 운영적인 측면에서 생각해 볼 수 있는데, 이는 그다지 바람직하지 않다(애플리케이션 서버 단위 → EAR 단위 업무 분리).
Q3. 설정항목, 설정 값의 저장위치와 항목별로 설정 값 변경시 발생할 수 있는 성능 영향
오라클 서버 설정을 위한 모든 항목은 XML 파일로 되어 있다.
server.xml : 메인 서버 설정
default-web-site.xml : 웹 서버 설정
rmi.xml : RMI 포트, 로그 등 설정
jms.xml : queues, topics, ports 등 설정
principals.xml : 사용자 및 역할 등 설정
data-sources.xml : DB 접근 제어 등 설정
global-web-application.xml : global Web applications 설정
application.xml : default application을 위한 설정
IBM 관리 콘솔을 통해서 설정할 수 있고, 그 값은 리파지토리 DB에 저장된다.
<캐시 크기>
- 캐시할 수 있는 인스턴스 수를 지정한다.
- 총 EJB 개수 X 동시사용자 수
- 지정된 값이 너무 작을 경우 성능저하의 원인이 된다.
<캐시 정리 간격>
- 컨테이너가 캐시 크기를 초과하지 않도록 캐시에서 사용되지 않은 항목을 제거하려고 시도하는 간격
- 일반적으로 캐시 크기를 증가시킨 것 만큼 간격도 증가시켜 준다.
<워크로드 관리 방침>
- 로컬 우선 라운드 로빙 방침이 라운드 로빙보다 성능이 더 좋다. 로컬 우선이란 EJB 클라이언트에서 EJB를 요청할 때 동일한 애플리케이션 서버에 있는 EJB 컨테이너 내의 EJB를 우선적으로 요청한다는 방침이다.
썬 server.xml에 있는 ejb-container 설정항목 중 다음을 유의해야 한다.
- steady-pool-size
- max-pool-size
- pool-resize-quantity
- pool-idle-timeout-in-seconds
- max-cache-size
- Cache-idle-timeout-in-seconds
- Removal-timeout-in-seconds
Q3의 경우 많은 기대를 했던 항목이지만 명쾌한 해답을 들을 수 없어서 아쉬웠던 부분이다. 업무 및 애플리케이션의 특성이 다양하기 때문에, 벤더에서도 케이스별 모범 답안을 제시하기가 어려웠던 내용이다. 그리하여 기술 지원을 하는 개개인의 역량과 경험에 따라서 시스템 성능이 좌우되는 현실을 경험할 수밖에 없는 것이다.
Deployment Descriptor
각 벤더에서 제공되는 가이드에는 Deployment Descriptor에 설정할 수 있는 항목들과 그에 대한 설명이 있지만 각 요소들이 실제로 시스템 성능에 어떠한 영향을 주는지 알 수 없기 때문에, 현실적으로는 대부분의 요소들을 디폴트로 설정하는 경우가 많다.
또한 Deployment가 정상적으로 이루어진 것처럼 보이지만 실제로 동작이 안되는 경우가 종종 발생하고 있으며, 일단 동작이 되면 그 자체에 만족하고 있기 때문에 성능에 대한 고려를 할 수 없는 환경이 만들어지고 있는 것이다.
Q4. 상황에 따라 여러 회사의 제품들이 함께 운영될 수 있는데, 이에 대한 가이드(예 : 웹 서버(A사) + 웹 컨테이너(B사) + 웹 애플리케이션 서버(C사) + DBMS(D사))
IBM < 툴 >
- 웹스피어는 텍스트 에디터를 통한 DD 직접 편집이 가능하지만 권장하지는 않는다.
- WSAD를 사용해서 개발할 경우, 개발과 동시에 웹스피어에 최적화된 DD가 자동으로 생성된다. 별도로 DD를 편집해야 할 경우에도 GUI를 통해 구조화된 방법으로 접근하기 때문에 쉽고 빠르게 작업할 수 있고 실수를 줄일 수 있다.
- WSAD 이외의 개발 툴을 사용할 경우에는, 웹스피어에서 제공하는 AAT(Application Assembly Tool)을 사용해서 역시 GUI로 작업할 수 있다.
< 튜토리얼 >
- DD는 HTTP Svr나 DB Svr의 종류에 독립적이다.
- 웹 애플리케이션(WAR), EJB(JAR), 엔터프라이즈 애플리케이션(EAR)의 DD 설정에 대해 쉽게 따라할 수 있는 튜토리얼이 웹으로 제공된다( http://www.ibm.com/software/webservers/appserv/ doc/v40/ae/infocenter/was/0607.html).
썬 Deployment Descriptor를 작성하는 가장 쉬운 방법은 썬원 스튜디오 4 IDE 또는 Administration 인터페이스를 사용한 EJB 모듈을 디플로이하는 것이다. 업데이트된 Deployment Descriptor 정보들은 제공되는 Ad ministration 인터페이스와 기타 유틸리티를 이용해 재설정할 수 있다.
‘한 벤더에서 모든 제품을 사야지 궁합이 잘 맞을까’라는 의문은 주위에서 쉽게 들을 수 있을 것이다. 표준 스펙은 따르고 있지만, 각 제품별로 벤더 나름대로의 특성들이 있기 때문에, 여러 벤더의 제품들을 조합하고자 할 때 혹은 조합해야 하는 경우에 어떠한 문제점들이 발생할 수 있고, 또 어떻게 조합하는 것이 좋은지 알고 싶었다. 그러나 벤더별 입장의 차이와 케이스별 조합이 매우 다양하다는 이유를 들면서 깊이 있는 답변을 주지 못하였다.
Q5. 주요 설정 항목(세부사항 : 퍼포먼스에 미치는 영향, WAS 설정 항목은 벤더별로 특성이 있는데, 각 벤더별로 유념해야 할 설정 항목들을 나열해 보았다)
오라클 server.xml에서 max-http-connections 설정에 유의
global-web-application.xml에서 main-mode 설정에 유의
web.xml에서 load-on-startup 설정에 유의
orion-ejb-jar.xml에서 do-select-before-insert 설정에 유의
orion-ejb-jar.xml에서 update-changed-fields-only 설정에 유의
orion-ejb-jar.xml에서 exclusive-write-access 설정에 유의
orion-ejb-jar.xml에서 isolation & locking-mode 설정에 유의
data-sources.xml에서 max-connections 설정에 유의
BEA 설정 값이 저장되어 있는 Weblogic-ejb-jar.xml 파일에서 다음 항목들 설정에 유의
- max-beans-in-free-pool
- initial-beans-in-free-pool
- max-bean-in-cache
- concurrency-strategy
- isolation-level
IBM 다음과 같은 설정항목에 유의
ibm-web-ext.xmi
ibm-ejb-jar-ext.xmi
썬 sun-ejb-jar.xml에서 풀링/캐싱 요소에 유의한다.
- Bean 풀 설정시
steady-pool-size
max-pool-size
pool-idle-timeout-in-seconds
Pool-resize-quantity
- Bean 캐시 설정시
max-cache-size
cache-resize-quantity
cache-idle-timeout-in-seconds
Victim-selection-policy
Q6. 운영 중인 WAS 상의 애플리케이션을 업데이트된 애플리케이션으로 교체하고자 할 경우 Deployment Descriptor 작성시에 고려되어져야 할 사항(Dynamic Deployment)
오라클 Deployment descriptor를 별도로 설정하지 않아도 변경된 클래스를 해당 디렉토리에 적용하면 자동적으로 dynamic deployement를 지원한다.
BEA 애플리케이션의 패키지 묶음
IBM 애플리케이션 서버를 재시작하지 않고도 애플리케이션 추가/변경 가능
웹 모듈
- JSP : DD의 설정과 관계없이 추가/변경 가능
- 서블릿 : 웹 애플리케이션 오토 리로딩이 true인 경우 추가/변경 가능
- 서블릿에서 참조하는 클래스나 Jar : 서블릿의 경우와 동일
- web.xml : 서블릿의 경우와 동일. 단, 다음의 경우는 해당 모듈 재시작 필요
- Web.xml에서 서블릿 맵핑 추가/변경시 HTTP Plugin configuration file 재생성 필요
- ibm-web-ext.xmi : 서블릿의 경우와 동일
- ibm-web-bnd.xmi : 해당 모듈 재시작 필요
-EJB 모듈
- ejb-jar.xml, ibm-ejb-jar-ext.xmi, ibm-ejb-jar-bnd.xmi : 변경시 모듈 재시작 필요
- Table.ddl : 변경시 DB 서버에서 재수행 필요
- Map.mapxmi, Schema.dbxmi : 변경시 EJB re-deploy, 모듈 재시작 필요
- EJB가 참조하는 클래tm나 Jar : 변경시 모듈 재시작 필요
- Home/Remote Interface class : 변경시 EJB re-deploy, 모듈 재시작 필요
썬 EJB 등의 일부 모듈이 변경된 경우에는 다시 디플로이를 한다든지, 서버를 재시작해야 할 필요는 없다. 변경된 파일(모듈)을 애플리케이션이 디플로이된 디렉토리(예 : instnce-dir/applications)에 넣어놓기만 하면 자동으로 변경된 것이 반영된다. Adminsration 인터페이스를 이용해 다이내믹 리로딩을 가능하게 하려면 다음과 같다.
짾 Adminsration 인터페이스에서 서버 인스턴스를 선택한다.
짿 애플리케이션을 선택한다.
쨁 애플리케이션의 설정 페이지들이 보여질 것이다.
쨂 ‘Reload Enabled’ 박스를 선택해 다이내믹 리로딩이 가능하도록 한다.
쨃 리로드되는 주기를 초단위로 입력한다(이 시간단위로 변화 여부가 체크된다).
쨄 설정을 저장한다.
Dynamic Deployment는 벤더 모두 지원한다는 입장을 보였으며, 고려되어야 할 사항보다는 어떻게 Dynamic Deployment를 하는지 알려주는 정도의 답변이었다.
패키징 설정
J2EE 기반의 애플리케이션은 HTML, XML, 서블릿, JSP, EJB 등과 같은 요소들로 구성되어 있으며 업무별, 기능별, 혹은 기타 다양한 원칙에 따라 JAR/WAR/EAR의 형태로 패키징된다. 그러나 각종 패키지들이 모호한 원칙에 따라 다양한 형태와 크기로 등록·설치되어 사용되고 있는 실정이므로, 패키징의 기술적인 제약사항, 기본요건, WAS간 호환 문제 해결 등을 위한 관련 가이드의 필요성이 제기되었다.
Q7. 패키징 단위 설정에 대한 권고사항(업무별, 기능별, 사용빈도별, 중요도별 등)
오라클 업무 프로젝트별 패키징을 권장
BEA 상황에 따라 다름. 그러나 관리가 따로 되는 단위가 제안됨
IBM 웹 모듈의 경우 HttpSession의 공유를 고려해야 한다.
J2EE 환경에서 HttpSession의 범위는 각 웹 애플리케이션으로 제한되기 때문에, HttpSession을 공유해야 할 서블릿/JSP는 동일한 웹 모듈 안에 있어야 한다.
썬 Type of Development Group
Small workgroup
Enterprise workgroup
Teams in Group
1 web team + 1 EJB team
2 EJB teams + 1 web team + 1 component
Modularizing Scheme
1 EAR = 1 EJB + 1 WAR
1 EAR = 2 EJB + 1 WAR + 1 individual component
Q8. 패키징의 기술적 제약사항 및 기본 요건
IBM 웹 모듈의 경우 HttpSession의 공유를 고려해야 한다.
특별한 제약사항은 없다.
Common code(common/utility class or Jar)의 위치는 다음 두 가지 중에서 상황에 맞는 것으로 선택
- Common classpath에 놓는다(Runtime Sharing)
소스 관리가 용이/약간의 시스템 자원 절약
- 각각의 EAR마다 하나씩 포함시킨다
애플리케이션이 서로에 대해 독립적
Q9. 패키징 사이즈에 따른 성능에의 영향과 근거
오라클 큰 패키지 사이즈는 수행 성능에는 문제가 없지만 개발시에 긴 설치 시간 및 메모리 점유로 인한 성능적인 부담을 줄 수 있음
BEA 상관 관계에 대한 문서는 아직 없음. 메모리에 많이 올라가서 많은 프로그램을 처리하는 것은 부하가 될 수 있음
IBM JDK 1.3.X에서 효율적으로 사용할 수 있는 애플리케이션 힙 사이즈의 한계는 대략 1.2GB다. 애플리케이션이 이 힙 사이즈 안에서 과도한 가비지 컬렉션 없이도 잘 수행된다면 패키징 사이즈는 성능과 직접적인 관계가 없다. 패키징 사이즈보다는 애플리케이션의 디자인과 코딩 기법이 성능에 미치는 영향이 훨씬 크다. 웹스피어 디벨로퍼 도메인에서 성능 향상을 위한 다양한 실전 예제를 찾아 볼 수 있다(http://www7b.soft ware.ibm.com/wsdd/zones/bp/).
Q10. WAS간 호환 문제를 해결하기 위한 패키징 방안
오라클 소스에는 영향이 없음. Deployment descriptor만 플랫폼에 맞추어 설정을 변경해 주면 됨
BEA 소스는 그대로 사용하고 포팅시에 Deployment Descriptor를 재작성할 필요가 있음
IBM 기본적으로 J2EE 표준 DD만 사용해서 패키징한 애플리케이션은 WAS 벤더에 비종속적으로 디플로이할 수 있다. WAS 벤더의 확장 DD를 사용할 경우에는 타 벤더와 호환되지 않기 때문에 디플로이하기 전에 확장 DD를 편집해 주어야 한다. WAS간 호환을 위해서는 벤더 확장 DD를 사용하지 않는 방법이 최선이다.
트랜잭션 유형 설정
트랜잭션의 설정은 중요한 자원에 대한 변경 관리시에 매우 중요한 사안이며, 그 관리를 위해서는 많은 시스템 자원이 필요하게 된다. 그러나 트랜잭션 관리가 필요하지 않은 경우가 있음에도 불구하고 트랜잭션 관리 범위를 확대함으로써 시스템 자원이 불필요하게 낭비되는 결과를 초래하는 경우가 많기 때문에, 트랜잭션 관리의 원칙을 도출하는 것은 중요한 의미를 가진다. 특히, CMT(Container Managed Transaction)보다는 BMT(Bean Managed Transaction)가 더 효과적인 경우에도 개발자의 기술 의존도가 높아지기 때문에 CMT를 선호하고 있으며, 트랜잭션 옵션 설정이 시스템 성능에 미치는 영향에 대한 확신이 부족하기 때문에 Transacti on_Required와 같은 값으로 설정하는 경우가 대부분이다.
Q11. CMT vs. BMT
트랜잭션 유형의 설정은 극단적으로 얘기하면 ‘개발자에 대한 믿음’과 ‘트랜잭션 유형을 염두에 둔 개발 표준에 대한 믿음’의 정도에 따라서 결정할 수 있다. 벤더의 입장도 개발자의 실수만 아니라면 BMT로 설정하는 것이 성능향상에 도움이 된다고 생각하고 있다. 결국 표준화가 철저하게 검증되어 지켜지고 있는 경우에만 BMT로 설정해 사용하라는 권고를 하고 있다. 사실 우리는 ‘BMT로 설정하고 또 BMP(Bean Managed Persistence)로 설정한다면 EJB를 왜 사용하는가?’라는 질문을 하였지만 논리적인 답변을 받을 수는 없었다. 다만 트랜잭션 유형 결정은 개발자의 실력과 그에 대한 믿음 그리고 개발표준 등의 정도에 따라서 이루어질 수 있다는데 공감하였다.
Q12. 트랜잭션 isolation에 대한 가이드라인
오라클 isolation 및 잠금 모드(locking mode)의 설정을 지원
BEA DB에 의존적임
IBM 대부분 트랜잭션 isolation 레벨은 데이터베이스 기본 isolation 레벨인 ‘Read Committed’를 그대로 따른다. 데이터 일관성의 문제는 성능의 문제보다 더 심각하기 때문에 불확실할 경우 ‘Serializable’을 선택한다. 만약 성능이 문제가 된다면 나중에 당황하지 않도록 낮은 isolation 레벨도 견딜 수 있는 트랜잭션을 작성하도록 개발할 때 신중하게 생각해 봐야 한다.
썬 server.xml
커넥션 풀링 설정
과거 DB 커넥션 자체에 많은 부하가 발생됐으나, 커넥션 풀링을 통해 시스템의 성능향상이 이루어졌다. 그러나 한정된 자원을 활용해 더욱더 안정적인 성능을 보장하기 위해서는 커넥션 풀링의 효율적 관리 방안이 도출되어야 한다. 커넥션 풀링 관련 가이드는 실제로 존재하지만, 설정 값 변경에 따른 시스템 성능에의 영향을 명확히 알지 못하기 때문에 자신감 있게 환경 설정을 하지 못하는 원인이 되고 있다.
Q13. 커넥션 풀링 관련 프로퍼티 설정 가이드 및 설정 근거와 성능에의 영향(min/max pool size, connection/idle/orphan ti meout, statement/preparedStatment cache size 등)
오라클 JDBC 커넥션 외에 HTTP 커넥션 등 종합적인 커넥션 리소스가 관리되어야 한다.
Data-source 최대 커넥션 수 >= (모든 JVM을 걸친) 동시 유효 쓰레드 수의 최대치
쓰레드가 무제한이거나, DB concurrency에 병목현상이 있는 경우에는 좀더 낮춰야 한다.
커넥션이 지속적으로 최대로 사용되고 있으면 wait-time을 조정해야 한다.
BEA InitialCapacity와 MaxCapacity의 개수를 동일하게 지정
- Caching Prepared Statement
- 성능 향상에 매우 도움이 됨
- 웹로직 콘솔에서 설정
- WLS가 애플리케이션이나 EJB에서 사용된 Prepared statement를 저장한다.
- 제약 사항 : 데이터베이스의 테이블이 삭제되었다가 재생성되거나, 컬럼이 추가 혹은 변경되는 경우는 에러가 날 수 있음
IBM Max : Burstness factora→0/부족하지 않으면 충분/Active 유저의 개수에 근접
Min : 첫 접속시에만 이슈
PreparedStatement cache : 빈번히 사용되는 pstmt # x Active 유저
썬 - setTransactionIsolationLevel()로 설정하기 보다는 드라이버에서 설정된 디폴트 isolation 레벨을 사용하는 것을 권장한다(idle time = 0).
- max-wait-time-in-millis = 0
- ‘Transcation-isolation-level’을 수정하는 것은 자제할 것을 권장한다.
- connection-validation-required = true로 설정할 것을 권장한다. 이는 DB 커넥션이 풀에 반환될 때마다 커넥션의 상태를 점검해준다.
Q14. 기술지원에 참여했던 안좋은 경우와 솔루션
IBM 상대적으로 최대 값을 100, 300, 500, 1000 등 불필요하게 높게 책정하는 경향이 있음. 권장사항은 Active 유저의 개수 근방에서 조정
기타 성능 향상을 위한 고려 사항
Q15. WAS 제품의 각 O/S별 최적 운용을 위한 파라미터 설정 가이드라인
오라클 네트워크(TCP) 파라미터 설정
tcp_conn_hash_size 32768
tcp_conn_req_max_q 1024
tcp_conn_ req_max_q0 1024
tcp_recv_hiwat 32768
tcp_slow_start_initial 2
tcp_close_wait_interval 60000
tcp_time_wait_interval 60000
tcp_xmit_hiwat 32768
BEA http://edocs.bea.com/wls/certifications/certifications/index.html를 참조한다.
IBM 웹스피어 애플리케이션 서버 4.0 InfoCenter
http://www-3.ibm.com/software/webservers/appserv/ infocenter.html
IBM WebSphere Redbooks
http://www.redbooks.ibm.com
468 웹스피어 추천 문서모음
http://www.javaservice.com/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=1010952419
140 웹스피어 V3 퍼포먼스 튜닝 가이드
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=959577074
301 벤치마크 테스트를 위한 퍼포먼스 튜닝 퀵가이드
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=985764595
[강좌] 웹 기반 시스템에서의 성능에 대한 이론적 고찰
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=consult&c=r_p&n=1008701211
405 웹 사이트 분석 방법 및 용량산정 팁
http://www.javaservice.net/~java/bbs/read.cgi?m=qna&b=consult&c=r_p&n=1015965697
Q16. 가비지 컬렉션 관련 설정 가이드라인
오라클 가비지 컬렉션 튜닝시에는 총 힙 메모리를 유념해야 한다.
힙 메모리는 기본적으로 가비지 컬렉션에 의해서 늘어나기도 하고 줄어들기도 한다.
또한 JVM은 사전에 정해진 특정 비율로 빈 메모리 공간을 유지하려는 특성이 있다.
목표 범위는 다음과 같은 형태로 설정할 수 있다.
-XX:MinHeapFreeRatio=
-XX:MaxHeapFreeRatio=
최대 범위는 ?Xms ~ ?Xmx 사이가 된다.
<키 포인트>
JVM에 기본적으로 할당된 메모리는 매우 적은 편이기 때문에, 별다른 문제가 없는 한 JVM에 메모리를 많이 할당해주어야 한다.
Xms와 Xmx는 같은 수치로 설정한다(물론 값에 대한 테스트는 수행되어야 한다).
프로세서를 증설하면 메모리를 늘려주어야 한다.
메모리 점유는 병렬적으로 일어나지만, 가비지 컬렉션은 그렇지 않음에 유의하라.
Another important tuning item is sizing the area of the heap dedicated to the young generation
BEA Java ?verbosegc : 가비지 컬렉션이 얼마나 자주 일어나는지 알 수 있음
힙 메모리 최소/최대 동일하게 설정
로우 메모리 설정 가능
IBM JDK 1.2 < JDK 1.3 이상에서는 가비지 컬렉션의 영향도는 없음
Xms 및 Xmx 값이 중요하며, 128-256-512m 정도 설정
썬 - Garbage collection reclaims the heap space previously allocated to objects no longer needed. The process of locating and removing the dead objects can stall any application while consuming as much as 25 percent throughput.
young generation 사이즈를 적절히 고려해 JVM에 충분한 메모리를 할당해야 한다.
JVM1.4를 위한 디폴트는 NewRatio 값과 -Xmx 값을 고려해 설정되어 있다.
- 솔라리스 시스템을 위한 설정의 예제를 살펴보자.
Q17. 쓰레드 관련 파라미터 설정 가이드라인
오라클 사용자의 부하가 큰 경우에는 쓰레드 수를 제한해야 하지만 시스템 리소스가 충분한 경우에는 쓰레드 수를 늘려준다.
최대 쓰레드 개수를 안다면 쓰레드 튜닝은 다음과 같이 두 형태로 할 수 있다.
짾 큐 사이지를 최대 쓰레드 수의 두 배로 설정한다.
짿 min=max로 설정하고 keepAlive=-1(쓰레드 타임아웃을 없앰)
BEA Unix Threading model : Green/native 쓰레드 방식, 더 좋은 성능을 위해 네이티브 쓰레드를 사용함.
ThreadCount : Default: 15/# of CPU수가 비교해 설정한다. 큐(Queue)에 쌓이지 않도록 한다.
StuckThreadMaxTime : Default: 600초/서버가 stuck되었다고 판단하는 기준 시간, Node Manager로 restart함.
ThreadPoolPercentSocketReaders : Default: 33/쓰레드 중 일부를 클라이언트 요청을 받는데 읽도록 할당
IBM Xss(native stack size) 값이 작아야 더욱 많은 쓰레드를 생성할 수 있음.
시스템 성능향상을 위한 과제
시스템의 성능에 문제가 발생하면 대게는 기술적으로만 접근하는 오류를 범한다. 또한 최근에 나온 기술이면 모든 것이 해결될 것이라고 생각하고 문제가 생기면 검증되지 않은 기술을 도입했기 때문이라고 책임을 회피하는 경우도 많다. 최고의 아키텍트는 특정 도메인의 특성에 해박하고, 업무 모델링, 인프라스트럭처와 애플리케이션에 대한 식견, 그리고 그 모두의 코디네이션(Coordination)에 능해야 한다고 혹자는 말한다. 그만큼 도메인(비즈니스)에 대한 이해가 기본적으로 필요하다는 것이다. 도메인에 대한 이해가 없는 기술적 접근은 필요 이상의 기술을 도입하게 할 수 있으며, 시스템 성능 점검시 잘못된 판단을 할 수 있다. 새로운 기술을 사랑하는 만큼 내가 개발하고 있는 업무 특성에도 관심을 가져보자.
그러나 WAS 관리자가 아무리 업무 특성을 잘 파악하고, 적극적으로 설정 변경을 주장한다 할지라도, 프로젝트의 특성상 ‘책임’ 문제가 있기 때문에, 많은 WAS 관리자들이 망설이고 있다. 이는 단순히 몇몇 사람이 해결할 수 있는 사항이 아니라 ‘성능 향상을 위한 튜닝 작업 절차’의 정형화와 정책적인 지원이 제도적으로 이루어 져야만 한다. 또한 성능을 고려하지 않는 방법론과 업무 모델링과 그리고 구현은 큰 문제가 아닐 수 없다. 시스템의 기능(functional requireme nts)만 만족하게 하고, 나중에서야 급급하게 시스템의 성능(nonfunctional requirements)을 고려하는 단기적인 시각은 반드시 고쳐져야 할 것이다. 성능을 전혀 고려하지 않은 상태에서 몇 가지 설정만 바꾸어서 일시적으로 성능이 향상되었다고 할지라도 근본적인 시스템 효율성은 향상될 수 없는 것이다.
성능이 안정화되기 위해서는 많은 부분에 노력이 필요하지만, J2EE-WG은 그 중에서 ‘성능 향상을 위한 WAS 설정’을 고민해 보았다. 고민의 흔적을 보면서 느꼈겠지만 고민을 풀어줄 해답은 아직 명쾌하게 정리되지 않았다. 아마도 국내 대부분의 기업 내부에서도 본지에서 다루었던 이슈들에 대해 문서화된 명확한 가이드라인을 제시하기는 힘들 것이다. 내부적으로 정리되지 않았던 노하우와 성능 관련 중요한 이슈들을 이제부터는 함께 정리해 보았으면 한다. 목마른 사람은 물을 찾게 되어 있지만, 마실 수 있는 물을 혼자 찾아야 한다면 그 만큼 절망적인 현실은 없을 것이다. 내가 알고 있는 길, 그 길에 대한 감각이 희미할 지라고 함께 찾았으면 한다. ‘우리는 명쾌한 가이드라인이 있는데’라고 하는 독자 혹은 함께 고민하고 싶은 사람이 있다면 서로에 대한 노하우를 전수받을 수 있는 소중한 자리가 마련되었으면 한다. 그리고 WAS 벤더들이 앞으로 만들어질 소중한 자리에서 소극적인 기존의 모습에서 벗어나 주도적으로 활동할 것을 기대한다.
정리 | 조규형 | jokyu@korea.cnet.com
