[오픈소스컨설팅]Performance Tuning How To

Certified Partner by
Performance Tuning

2
- Internal Use Only -
Performance Tuning 개요
성능이란?
• 각 애플리케이션 단위 응답 시간
Server
Request 수행
View
WebServer
웹컴포넌트
Application Server
Controller
Model
Database Server
요 청
응 답 시 간
Transaction per Second

3
성능 튜닝 준비를 위한 기본기 다지기
• TPS : Transaction Per Second
• 단위 시간당 최대 처리건수 : Total Number of Transaction
• TPM : Transaction per Minute
• 초당 요청 건수 - RPS : Request per Second
• 트랜잭션 응답 시간 : Transaction Response Time
• 동시 사용자 : Concurrent User
• 처리량 : Throughput

4
성능 튜닝 준비를 위한 기본기 다지기
• Light Load Zone : 사용자가 증가함에 따라 선형적으로 처리량이 증가하는 단계
• Saturation Point : 애플리케이션이 수용할 수 있는 최대 동시 사용자 수를 의미
• Heavy Load Zone : 클라이언트의 부하가 상승함에도 처리량이 일정 부분 지속
• Buckle Zone : 하나 이상의 시스템 리소스(메모리,CPU 등)가 소진되어 처리량이 점점 떨어지는 단계
용어 : IBM Tuning Methodology : http://www.redbooks.ibm.com/abstracts/tips0245.html?Open

5
성능 튜닝 범주
• 단순 웹 애플리케이션이라고 해서 WAS만을 고려해서는 안 된다.
• 튜닝의 대상은 애플리케이션이 돌고 있는 모든 주변 상황을 고려.
애플리케이션
웹 서버 운영체제 데이터베이스 WAS
CPU MEMORY DISK I/O N/W IO
네트워크
업그레이드 혹은 확장
설계, 구현, 환경 설정
파라미터 설정

6
Performance Tuning
성능 튜닝 순환 4단계
Baseline 구성
Performance
Tuning
데이터 수집
STEP 1
결과 분석
STEP 2
환경 설정
STEP 3
테스트 및 결과
STEP 4

7
Performance Tuning
성능 튜닝 순환 6단계
애플리케이션
수정
솔루션 검토
(해결책)
성능 테스트
모니터링
데이터 수집
planningexecution 병목 구간
확인
솔루션 적용
optional

8
Performance Tuning
기준치(Baseline) 산정
• 애플리케이션에 대한 서비스 시작 전 성능에 대한 기준치 산정이 필요
• 성능 목표
 응답 시간(Response Time), 처리량(Throughput), 리소스 사용(Resource Utilization) 관점에서
얻어야 할 성능 목표치 산정
 점검 리소스 사용량 : CPU, Memory, Disk I/O, Network I/O
• 테스트 계획 및 테스트 스크립트
 로드 테스트 시 필요한 일정 산정 및 스크립트 구성
 로드 테스트용 도구 선정
• 점검 기준표 작성
 시스템, 플랫폼, 애플리케이션에 대한 점검 매트릭스 사전 작성
 성능 튜닝 프로세스에 대한 일지 기록

9
Performance Tuning
AS-IS 운영 축적 자료를 통한 용량 산정
AS-IS 시스템( XXX사 XXX 장비, OOO tpmC)
일일 총 트랜잭션 : 43,200,000 건
동시 단말 : 8 Robot Agent
평균 초당 트랜잭션 : 500 Request/Sec
CPU 사용률: 70%
예 1> A업체 생산 시스템
AS-IS 시스템( XXX사 XXX 장비, OOO tpmC)
일일 총 방문자: 46,293명
Peak 동시 단말사용자: 1000명
일일 총 호출건수 : 1,795,867건
Peak Arrival Rate : 182.5 tps
Request Interval : 13.7 sec
Visit time: 6분 25초
한 사용자당 총 호출횟수: 23회
CPU 사용률: 70%, 메모리 사용 : 1.6G
예 2> B 업체 인터넷 시스템

10
Performance Tuning
TO-BE 목표 성능 지표 산정(예시)
Total Resources WAS : 3,040,000 tpmC DB : 1,600,000 tpmC
품 질 속 성 기 준 목 표 치 비 고
수행 내용
최대 TPS 성능 테스트 ( 3,040,000 / 1,680 = 1,809.7Tps) 1,809 TPS 이상 2009.06.28 기준 1,809Tps
최대 응답시간 (솔루션 처리 시간 (IN + OUT)) < 3 Sec주1) 업무의 복잡도, 대상 시스템(데이터
베이스, 타 시스템) 처리시간
안정성 테스트
- 24 hours 이상 주2)
실패 거래 None
시스템 충돌 No 상세 시나리오의 체크 리스트를
작성하여 결과를 확인
메모리 누수 현상 No 상동
확장성 테스트
시스템용량을 25% 에서
50%, 75%, 100%로
확장하는 테스트
주3)
확장에 따른 성능 증가를 보여주는
방법
Graph
확장에 따른 성능의 표준 편차
범위
~5 %
확장에 따른 응답시간의 표준 편차
범위
~0.05 sec
주1) 처리시간은 타겟 시스템으로 송,수신처리에 대한 연계 총 처리시간 임.
주2) 일일 영업시간 (8시간)을 기준으로 산정함.
주3) 시스템의 수를 1(전체 대비 25%)에서 2 (전체 대비 50%), 3 (전체 대비 75%), 4 (전체 대비 100%) 로 증가시켜 시스템 확장성을 테스트

11
Performance Tuning
테스트 일정 도출
일 자 주요 Activity 세부 Activity
2013.00.00 시스템 설치
 시스템 Setup - H/W, S/W, Middleware, DBMS,
통신환경구축 등
 상세 테스트 시나리오 준비
 대상 프로젝트 적용시 예상 거래 테스트 케이스
 안정성 테스트 케이스
 테스트를 위한 데이터 수집
 Load Runner Script 준비
2013. 00. 00 ~
2013.00. 00
시스템 환경 점검
성능/부하 테스트 및 결과
데이터 수집
테스트 수행
 시스템 내부 Configuration Setup 및 튜닝
L4, WAS 서버 튜닝
 DBMS 서버 튜닝
 시스템 파라미터 튜닝
 시나리오상의 업무들의 사전 테스트 실시
 Memory Leak & Garbage Collection Optimizing
시나리오에 따른 성능/부하 테스트 진행
테스트 및 결과 자료 수집
2013. 00. 00 결과 보고서 작성  테스트 결과 자료에 대한 분석 및 평가

12
Performance Tuning
테스트 일정 상세 도출
날 짜 시간 작업 내용 담당 비 고
6/26(금) 17:30 -
- 시스템 입고
- p595, superdome, E10000 * 1EA, E4900 * 1EA,
ST9990, NT Rack * 1EA
H/W 벤더
6/27(토) 09:00 -
- O/S Install 및 config 구성
- JDK 1.6 최신 Version Install, C compiler Install
- Network 연결 및 설정
H/W 벤더
H/W 벤더
BMT 시행사
IP정보
6/28(일) 09:00 - - DISK 구성 H/W 벤더 전원확보
6/29(월) 09:00 -
- Database Engine Install (클러스터 구성)
- WAS Engine Install
- Web Server Install
- Rule Engine Install
DB 벤더
M/W 벤더
BMT 시행사
DB Table 정보
6/30(화) 09:00 - - BMT 애플리케이션 세팅 BMT 시행사
7/1(수) 09:00 - - 구성 점검
7/2(목)
7/3(금) 09:00 - - DB Table 구성 확인 및 구성 점검
7/4(토) - BMT 시나리오 설명회 BMT 시행사
7/6(월)~7/31(금) - BMT 시나리오 수행 ALL

13
Performance Tuning
파일럿 애플리케이션 추출
• 전체 기반 성능 테스트를 할 경우 모두를 테스트할 수는 없다.
• 상위 트랜잭션의 80%를 차지하는 10~20%의 애플리케이션을 추출
• 애플리케이션 트랜잭션의 경우 대부분 파레토(Pareto, 80 vs 20) 법칙이 적용.

14
Performance Tuning
Bench Mark Test 진행
• 조건
 같은 워크 로드
 같은 테스트 스크립트
 같은 부하 생성 서버
 모든 테스트 환경이 동일해야 함.
• 변경 가능 항목
 시스템 파라미터
 JVM 파라미터
 애플리케이션 서버 인스턴스
동일한 부하를 줄 수 있는 Machine Gun 선택

15
Performance Tuning
BMT를 통한 튜닝 접근법
• 관련된 모든 수치를 최대한 높인 후, 점차적으로 Active Thread 수를 증가시키며 테스트를 시행하고,
그 결과를 반드시 TPS그래프로 그리거나 툴을 이용.
• 각 Tier 혹은 머신의 CPU/MEM, 네트워크, 응용 애플리케이션이 사용하는 TCP/IP port를 모니터링하
고, 각 구간의 Saturation Point를 찾아라.
• 가급적 백엔드(Backend)시스템의 Saturation Point부터 찾아야 한다.
• 가장 먼저 Bottle-neck으로 도출되는 구간부터 튜닝하라.
• 다시 Active thread 수를 증가시키며 동일한 테스트를 반복 시행하고 TPS의 전체적인 그래프를 통해
성능상의 변화를 확인하라. 이 과정은 계속 반복되어야 한다.
<자바 서비스넷 이원영 대표>

16
Performance Tuning
성능 측정 툴
• LoadRunner
 http://www8.hp.com/us/en/software-solutions/software.html?compURI=1175451
• SOAP UI
 http://www.soapui.org/
• Apache Bench
 $apache/bin/ab
• Apache JMeter
 http://jmeter.apache.org/

17
Performance Tuning
Apache Bench
• Option
 Usage: ab [options] [http[s]://]hostname[:port]/path
 Options are:
 -n requests Number of requests to perform
 -c concurrency Number of multiple requests to make
 -t timelimit Seconds to max. wait for responses
 -b windowsize Size of TCP send/receive buffer, in bytes
 -C attribute Add cookie, eg. 'Apache=1234. (repeatable)
 -A attribute Add Basic WWW Authentication, the attributes
 are a colon separated username and password.
 -k Use HTTP KeepAlive feature

18
Performance Tuning
Apache Bench
• 테스트
 ab -n 10000 -c http://10.64.160.179:8080/test.jsp
 동시 사용자 10명이 총 1000번의 요청을 날린다. (각각 10000번이 아님)
• 결과
Server Software: Apache-Coyote/1.1
Server Hostname: 10.64.160.179
Server Port: 8080
Document Path: /test.jsp
Document Length: 1543 bytes
Concurrency Level: 10
Time taken for tests: 2.700 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 18856956 bytes
HTML transferred: 15443887 bytes
Requests per second: 3703.10 [#/sec] (mean)
Time per request: 2.700 [ms] (mean)
Time per request: 0.270 [ms] (mean, across all concurrent requests)
Transfer rate: 6819.26 [Kbytes/sec] received

19
Performance Tuning
성능 측정 기록
Test Date 시나리오 AP Server 시나리오 Time
WAS
인스턴스수
Total Users TPS 응답시간 CPU CPU MAX
2013.06.17 TC1-1(a) AP1 TC1-1 10m 1 30 410.258 0.072 63.39 69.00
TC1-1(b)
TC1-2(a)
TC1-1 10m 1 30 241.460 0.118 23.15 24.00
TC1-2(b) TC2-1 10m 2 60 433.651 0.132 45.00 48.00
TC1-2© TC2-1 10m 3 90 618.593 0.135 66.26 71.00
TC1-2(d) TC2-1 10m 4 120 814.038 0.144 89.31 94.00
TC1-2(e) TC2-1 10m 5 150 817.087 0.175 92.21 96.00
TC1-2(f) TC2-1 10m 6 180 836.576 0.207 94.31 96.85
2013.06.17 TC3-1(a) AP3 TC3-1 10m 1 40 518.266 0.073 83.35 89.00
TC3-1(b)
TC3-2(a)
TC3-1 10m 1 40 196.311 0.195 24.34 25.00
TC3-2(b) TC3-2 10m 2 80 353.730 0.218 47.36 50.00
TC3-2© TC3-2 10m 3 120 522.938 0.223 72.27 75.00
TC3-2(d) TC3-2 10m 4 160 669.803 0.230 94.24 98.00
2013.06.17 TC5-1(a) AP5 TC5-1 10m 1 40 502.639 0.075 83.83 89.00
TC5-1(b)
TC5-2(a)
TC5-1 10m 1 40 183.560 0.210 24.53 26.00
TC5-2(b) TC5-2 10m 2 80 328.652 0.233 47.63 50.00
TC5-2© TC5-2 10m 3 120 472.794 0.244 71.51 74.00
TC5-2(d) TC5-2 10m 4 160 621.968 0.249 94.92 98.00

20
Performance Tuning
테스트 결과 분석

21
Performance Tuning
병목의 단골 손님
• CPU – 스레드 경합에 의한 비정상적인 CPU 사용
• Network – CPU 대기 시간 및 네트워크 부하.
• Disk – 실제 디스크에 대한 물리적인 초당 디스크 입출력(Disk I/O).
일반적인 경우 모니터링 측정치가 20ms 이상이면 잠재적인 병목으로 진단함.(sar, iostat)
• Java Heap – 가비지 컬렉션이 시간이 응답시간의 15%이상을 차지하면 사이즈 조정 필요
(HP Jmeter, IBM GA, Jconsole 등)
• WAS Thread Pool – 요청 큐로 보면 되며 동시 대기 스레드가 많아질 경우 병목이 발생
• Database Thread Pool – 데이터 베이스 풀 개수로 인한 성능 병목 현상 발생

22
Performance Tuning
문제가 발생할 확률 99%
• 범위를 먼저 분석
 웹 서버, 애플리케이션 서버, 데이터 베이스 서버 모두가 연동될 경우 어디서 문제가 발생되
었는지 범위를 좁혀야 함.
 어떻게 추적할 것인가?
• 문제 발생시 추적 도구를 동원.
 APM(Application Performance Monitoring Tool)
 Profiler 분석
 Log를 이용한 결과 분석 등

23
Performance Tuning
어떻게 문제 구간을 확인할 수 있는가?
• 항상 첫 번째로 각 서버의 CPU를 주시하라!
Web / WAS Server Database Server
Cluster
LoadRunner PC
LoadRunner
(PC 10 EA)
Web
Server
App Server
App Server
App Server
App Server
Plug-in
JDBC Thin
1000 Virtual User
Web Server App Server DB Server Where tune?
High Low Low
Suitable High Low
Suitable Low High
Suitable High High

24
Performance Tuning
깔때기 이론
• 일정한 처리량일 경우 요청 유입이 많아진다면?
• 아래의 그림에서 처리량을 늘려줄 수 있는 방법은?
• 하부에 DB가 있을 경우 WAS vs DB의 CPU는 어떤 상태를 보일까?
요청 유입
요청 큐잉(Request Queue)
처리량(Response)
WAS 구간

25
Performance Tuning
성능 장애 요인 파악 – Absolute Performance Problem
• 애플리케이션 처리 미비 - JDBC 리소스 미 반환에 의한 장애
• 명시적 Commit/Rollback 미비로 인한 DB Lock
• 메모리 관련 장애(과다 메모리 사용, 누수(Memory Leak), Native Memory Leak)
• 시스템 WAS 튜닝 미비에 의한 장애(Pool Size, Thread 개수, Heap Size)
• JVM/WAS/JDBC 등 제품의 버그에 의한 장애(JDBC Driver, JVM Bug, WAS Bug)
• 라이브러리 등에서의 Thread Lock/Dead Lock에 기인한 장애(예: Log4j 1.2.6)
• 대용량 파일 다운로드/업로드
• 비규칙적 애플리케이션 무한루프/CPU 100%
• 특정 사용자, 특정 그룹의 사용자들만 성능저하

26
Performance Tuning
성능 장애 요인 파악 – Relative Performance Problem
• 하드웨어 용량 부족 (메모리, CPU 등)으로 인한 성능 저하 및 장애.
• 네트워크 용량 문제
• 연계 시스템일 경우 대상 시스템의 응답 속도 저하로 인한 병목
• Back-end 트랜잭션의 상대적 성능 저하 (TP-모니터 : Tuxedo, CICS, Tmax)
• EAI Adapter 처리 방식으로 인한 성능 저하(XML Parsing 등)
• SQL Query 성능 저하로 인한 장애(대용량 쿼리, Full scan 등)

27
Performance Tuning
병목 해결을 위한 구조
• 근본적인 문제를 찾아야 한다.
• 잘못된 접근법
 WAS의 Thread 수 증가시킴
 JDBC Connection Pool 증가시킴
• 유입되는 모든 요청을 처리할 수 있는 모양을 만들어야 한다. 웹 서버
플러그인
WAS
DB
Request

28
Performance Tuning
분석 도구 – OS
• vmstat(AIX/Linux)
 메모리 요약 정보, 스왑 영역, 프로세스, 페이징, IO 블럭 및 컨텍스트 스위칭 데이터
• top(UNIX/LINUX)
 초 단위로 CPU/IO 사용량 및 프로세스들의 각종 사용량 정보를 표현.
• topas(UNIX/AIX)
 AIX 전용 top 유틸리티.
• netstat(Unix/Linux)
 네트워크 연결상태, 도메인 소켓 연결 상태, 네트워크 연결에 사용된 프로세스
• Lsof(List Open File)
 특정 파일 액세스 프로세스, 호스트 접속 확인, 포트 접속 리스트, 프로세스가 사용하는 파일
리스트 등

29
Performance Tuning
CPU 병목 찾기
• vmstat – 시스템 확인
id : Idle Percentage
us : 사용자 프로세스에 대한 CPU 퍼센트값
sy : 커널 프로세스에 대한 CPU 퍼센트값
wa : CPU와 연관된 I/O 대기 시간
in : 커널 인터럽트 횟수
cs : 커널에 대한 컨텍스트 스위치
필수 확인 사항
[root@KVM2 ~]# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 8 28548 28504 2319828 0 0 185 84 876 1403 10 6 72 12 0
0 0 8 28820 28504 2319828 0 0 0 0 1398 1651 4 4 92 0 0
0 0 8 28340 28504 2319828 0 0 0 0 1331 1633 5 3 92 0 0
0 0 8 28552 28512 2319820 0 0 4 72 1256 1615 4 2 92 1 0
1 0 8 28760 28512 2319844 0 0 0 0 1387 1583 7 3 90 0 0
0 0 8 28232 28512 2319844 0 0 0 0 1218 1583 5 1 93 0 0
0 0 8 28600 28512 2319844 0 0 0 0 1285 1618 5 2 93 0 0
0 0 8 29032 28512 2319844 0 0 0 0 1493 1547 4 9 87 0 0
0 0 8 28308 28520 2319836 0 0 4 56 1378 1603 5 3 92 0 0
0 0 8 28652 28520 2319860 0 0 0 0 1341 1610 4 2 93 0 0

30
Performance Tuning
CPU 병목 찾기
top - 11:31:05 up 2:03, 2 users, load average: 0.70, 0.54, 0.47
Tasks: 172 total, 1 running, 170 sleeping, 0 stopped, 1 zombie
Cpu(s): 6.9%us, 4.4%sy, 0.0%ni, 88.0%id, 0.6%wa, 0.1%hi, 0.0%si, 0.0%st
Mem: 3077012k total, 3059100k used, 17912k free, 186468k buffers
Swap: 5111800k total, 8k used, 5111792k free, 2031304k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3352 root 20 0 236m 107m 20m S 7.9 3.6 11:04.93 Xorg
5403 root 20 0 776m 155m 25m S 6.5 5.2 2:43.15 firefox
5177 root 20 0 1362m 1.1g 1.0g S 5.5 36.1 16:08.56 vmware-vmx
6489 root 20 0 439m 31m 12m S 3.3 1.1 0:02.54 npviewer.bin
5546 root 20 0 369m 20m 12m S 2.2 0.7 0:02.64 gnome-terminal
4448 root 20 0 441m 51m 33m S 0.8 1.7 1:01.79 vmplayer
3795 root 20 0 354m 51m 4892 S 0.4 1.7 0:07.05 gnome-screensav
q : 종료
N: pid 순 정렬 나중순
A: 최근 pid순 정렬
P : CPU사용률에 따라서 정렬
M : 메모리 사용률에 따라서 정렬
T : 누적시간 (CTIME)순 정렬
l : load average, uptime 사용정보 on"
PID : 프로세스 id
USER : 사용자(id)
PRI : 우선순위
NI : nice명령어값
SIZE : 가상이미지 크기(?)
RSS : 메모리 사용량
STAT: S(sleeping), R(running), W(swapped
out process), Z(zombies)
%CPU : CPU 사용률
%MEM : 메모리 사용률
TIME+ : 시작 후 누적시간

31
Performance Tuning
Network로 처리할 수 있는 최대 TPS 확인
• 네트워크로 인하여 실제 성능이 안나올 수 있음을 확인해야 함.
• bps : bit per second (1 byte = 8 bit, 1Kbyte = 1024 byte)
• 전송 속도
 E1 : 2.048 Mbps (2Mbps)
 T3 : 43.7361 Mbps (45Mbps)
 OC3 : 155.2 Mpbs
 10 Mbps, 100Mbps
• 100Mbps급: 실 전송속도의 60%라고 한다면
실 전송속도 60Mbps = 60*1024(Kbps) = 60*1024/8(KB/sec)
= 7680(KB/sec)
• 10K data전송 : 7680(KB/sec) / 10(KB) = 760.8 TPS
• 100K data 전송 : 7680(KB/sec) / 100(KB) = 70.68 TPS

32
Performance Tuning
Profiler
• 프로그램이 실행될 때 수집된 정보를 이용하여 프로그램의 행동을 조사하여 성능 분석 및 병목 등을
찾아낼 수 있는 소프트웨어 엔지니어링(성능 분석 툴)
• 리소스 관점에 따른 종류
 Performance Profiler, Memory Profiler
• 출력 결과에 따른 종류
 Flat Profiler : 모든 메소드 호출 시간에 대한 평균 시간을 계산
 Call-graph Profiler : 호출되는 메소드 등에 대한 call-chain을 이용하여 호출 시간, 빈드 등을
측정
• 상용 profiler
 Jennifer, JProbe profiler (Quest Software), OptimizeIT, JProfiler, TrueTime, etc.
• 오픈 소스 Profiler

33
Performance Tuning
Profiler
• 프로그램이 실행될 때 수집된 정보를 이용하여 프로그램의 행동을 조사하여 성능 분석 및 병목 등을
찾아낼 수 있는 소프트웨어 엔지니어링(성능 분석 툴)
• 리소스 관점에 따른 종류
 Performance Profiler, Memory Profiler
• 출력 결과에 따른 종류
 Flat Profiler : 모든 메소드 호출 시간에 대한 평균 시간을 계산
 Call-graph Profiler : 호출되는 메소드 등에 대한 call-chain을 이용하여 호출 시간, 빈드 등을
측정
• 상용 profiler
 Jennifer, JProbe profiler (Quest Software), OptimizeIT, JProfiler, TrueTime, etc.
• 오픈 소스 Profiler

34
Performance Tuning
애플리케이션 구간 처리 시간 분석 병행
• 애플리케이션 로그를 통한 각 구간별 로그를 저장 후 문제 지점 분석
1. 요청과 동시에 UUID와 같은 식별키를 이용하여 트랜잭션 ID 채번 후 시간 로그를 남김
2. 대상 시스템 호출 직전 요청 시간을 남김
3. 대상 시스템으로부터 응답과 동시에 현재 시간에 대한 로그를 남김
4. 호출 측으로 응답을 반환하기 직전 트랜잭션 아이디와 함께 로그를 남김
• 대상 시스템 응답 시간을 얼마인가?
• 시스템 내에서 처리한 순수한 시간은 얼마인가?
Adapter
Adapter
Adapter
Adapter
Source Target
① ②
③④

35
Performance Tuning
사용자 및 TPS의 상관 관계
Saturation point
ResponseTime
User Load
X
100users User Load
Throughput
X
Saturation point
Utilization
User Load
X
Saturation point

36
Performance Tuning
가장 이상적인 모습

37
Performance Tuning
증상 1
• 다음의 그래프를 보았을 때 예상할 수 있는 문제점은?

38
Performance Tuning
예상 1
• 증상
 응답 속도(Response Time)가 수행 도중 급격하게 떨어짐.
 TPS가 가끔씩 비정상적으로 증가
• 예상
 CPU 경합(lock contention)
• 왜 발생하는가?
 특정 jar 파일을 여러 개의 스레드가 액세스
 Synchronized 블록에 대한 멀티 스레드 처리
 예전 log4j 등의 동일 리소스 사용
• Thread dump 시 보통 ‘waiting to lock’ 형태로 발견됨.
• 해결
 덤프 등을 통하여 문제 발생 라이브러리 혹은 코드를 통해서 해결.

39
Performance Tuning
증상 2

40
Performance Tuning
예상 2
• 증상
 사용자와 함께 TPS 증가 후 특정 시점 급격히 감소
• 예상
 Gabage Collection 문제는 아닌 것으로 예상됨.
 리소스에 대한 문제로 의심.
 너무 많은 스레드로 인한 과도한 컨텍스트 스위칭
 코드 내 스레드의 sleep으로 인한 상태 변화
 OS 관련 파라미터(멀티 스레드 관련)의 잘못된 설정
• 실제로 대량 스레드에 대한 context switch가 많이 발생하여 나타난 결과

41
Performance Tuning
증상 3

42
Performance Tuning
예상 3
• 증상
 20 user 시점까지 정상증가 후 이후 서서히 감소
• 예상
 CPU 경합 현상 패턴은 아님.
 메모리 누수일 경우 이와 같은 그래프를 상당히 보임
 Static Collection 객체 등에 지속적인 데이터 삽입
• 확인 방법
 시스템 자원 모니터링을 통하여 문제점 파악

43
Performance Tuning
증상 4

44
Performance Tuning
예상 4
• 증상
 초기 TPS는 크게 증가하나 바로 떨어진 후 안정화
 CPU, 메모리 사용량 거의 없음
• 예상
 Leak, CPU 경합은 없을 것으로 예상됨(단지 예상임)
 적정 스레드 개수를 잘못 산정
 과도한 웹 서버의 스레드, WAS 스레드
• 실제 Apache worker 스레드를 과도하게 설정하여 나타난 문제 변경후

45
Performance Tuning
증상 5

46
Performance Tuning
예상 5
• 증상
 부하시 지속적으로 응답 시간 증가 후 응답없음
• 예상
 Long-running 트랜잭션들이 많은 확률
 대용량 쿼리를 사용하는 애플리케이션이 있을 가능성
• 대용량 쿼리 실행시 파급 효과
 Heap 메모리 지속적 증가
 응답 지연으로 인한 요청 큐(request queue)에 누적
 수행중인 다른 트랜잭션들의 time-out 발생
 메모리 확보를 위한 JVM의 과도한 GC 작업 발생
 결국 서버가 다운되는 현상(복구되는 경우 거의 없음)

47
Performance Tuning
요약
• 문제가 발생하는 곳에서 모든 추론을 동원할 것.
• 호기심이 문제 해결을 이끈다.
 문제의 실체에 접근할 수 있는 모든 경로를 탐색하라.
 모든 사건에 대해 “왜(why)?”를 붙이도록 한다.
• 모든 시스템 리소스에 대한 지속적인 모니터링이 필요
• 모든 작업은 기록을 통해 하나씩 순차적으로 해결해야 한다.
 한꺼번에 두 가지 파라미터 등을 변경하고 테스트 하는 것은 없다.
 한번에 하나씩 테스트하고 모든 항목을 기록한다.

48
Performance Tuning
WAS 튜닝 포인트
• 각 영역별 JMX를 통한 모니터링 방법을 가지고 있어야 함.
• WAS 구동을 위한 GC 옵션
• 문제 발생시 Thread Dump를 통한 문제 분석
Web Application Server
DBMS
EJB
EJB
DB Connection
Pool
Thread Pool
Request
EJB Pool
JDBC
Request
Queue
Execute ThreadExecute ThreadExecute Thread
Pooling
Pooling
Pooling

49
Performance Tuning
Platform(OS) Tuning
• TCP 파라미터 튜닝, OS 스레드 파라미터, 파일 디스크립터 튜닝,
예> 리눅스 커널 파라미터 튜닝
파라미터 기본값 변경값 내용
net.ipv4.neigh.default.unres_qlen 3 100 Increase TCP
net.ipv4.tcp_keepalive_time 7200 30 Drop keep-alive time
net.ipv4.tcp_fin_timeout 60 10 Drop it so lack of FIN times out quicker
net.core.netdev_max_backlog 1000 2500 Increase number of incoming connections backlog
net.ipv4.tcp_retries1 3 2 How many times to retry killing an alive TCP connection
net.ipv4.tcp_retries2 15 3 How many times to retry killing an alive TCP connection
net.ipv4.ip_local_port_range 32768 61000 1024 65000 Increase Local port range
net.core.rmem_max 131071 16777216 Max TCP Receive Buffer
net.core.rmem_default 109568 16777216 Default TCP Receive Buffer
net.core.wmem_max 131071 16777216 Max TCP Send Buffer
net.core.wmem_default 109568 16777216 Default TCP Send Buffer
net.ipv4.tcp_window_scaling 0 1 Enable really big(>65kb) TCP window scaling
net.ipv4.tcp_timestamps 1 0 Turn off timestamp
net.ipv4.tcp_sack 1 0 Turn off tcp sack
net.ipv4.tcp_orphan_retries 7 0 유저 파일 핸들에 할당되지 않은 연결에 몇번 재시도 할지
vm.swappiness 10 1 Swap 사용량 결정

50
Performance Tuning
JVM Tuning
• JVM Heap 사이즈 환경 설정
 Heap Size
 -Xms, -Xmx
 Young Generation Space
 -XX:NewRatio, -XX:NewSize, -XX:MaxNewSize
 Survivor Space
 -XX:SurvivorRatio
 Permanent Generation
 -XX:PermSize & -XX:MaxPermSize
 Aggressive Heap
 -XX:+AggressiveHeap

51
Performance Tuning
Core 튜닝
• Native IO – Performance Pack
• Execute Thread
• Request Queue Size
• Socket Reader
• 너무 많은 실행 스레드 설정을 오히려 성능을 저하시킬 수 있음.
• 새로운 스레드를 지속적으로 생성하는 애플리케이션 디자인은 피해야 함.

52
Performance Tuning
JDBC Connection Pool
• 커넥션 풀 사이즈 및 테스트 옵션
• Statement 캐시
• 컨넥션 풀 요청 타임아웃
• 반환되지 않은 커넥션 자동 closing 옵션 활성화
• 일반적으로 초기 연결값과 최대 연결값을 같도록 설정
 데이터 베이스 등의 소켓 연결작업은 상당한 리소스를 필요로 함.
• 최대 커넥션 개수는 WAS의 최대 실행 스레드(execute thread)를 넘지 않도록 함

53
Performance Tuning
EJB Tuning
• EJB Pool 개수 튜닝
• CMP 튜닝
 Relationship-caching, 엔티티 빈에 연관된 Pre-fetching
• JNDI Lookup 캐시를 통한 EJB 레퍼런스
• 동일한 JVM일 경우 Local Interface를 사용
• 애플리케이션 범위의 캐시를 사용

54
Performance Tuning
JMS Tuning
• JMS Persistence Store 의 적절한 선택
 File, Memory, JDBC
• 메시지 플로우 컨트롤을 통한 조절
• 만료된 메시지(Expired Message) 제어
• 메시지 유형(Byte, Object, XML 등) 및 전달(Queue, Topic) 방식 선택
?
Sender Receiver
Connection
Session
Producer
Consumer
Remoting
Core
Client-side Delegates
Client-side aspects
Server-
side
aspects
Server-side
endpoints

55
Performance Tuning
Servlet/JSP Tuning
• 세션 관리(Session Management)
• 세션 저장 전략
 Memory
 File System
 Database
• 세션 속성 설정
 세션 타임 아웃 시간
 세션 캐시 사이즈
• JSP 사전 컴파일(pre-compile) 기능 사용
• 서블릿 재로딩 기능
• 요청마다 페이지 변경 확인 기능 제거
• <% page session=“false”%>를 통해 세션 자동 생성 기능 억제

56
Performance Tuning
요약
• 성능이란 무엇인가?
• 성능 튜닝 프로세스
• 성능 측정 및 병목 파악
• 장애 진단
• 성능 패턴 분석 및 토론
• 자바 진단
• WAS 튜닝 포인트

57
OPEN
SHARE
CONTRIBUTE
ADOPT
REUSE

[오픈소스컨설팅]Performance Tuning How To

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [오픈소스컨설팅]Performance Tuning How To

Similar to [오픈소스컨설팅]Performance Tuning How To (20)

More from Ji-Woong Choi

More from Ji-Woong Choi (20)

[오픈소스컨설팅]Performance Tuning How To