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

11,920 views
11,627 views

Published on

This slide allows you to increase your web application server performance. If you want to get this, please email us(support at osci.kr)

Published in: Technology
0 Comments
30 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,920
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
1
Comments
0
Likes
30
Embeds 0
No embeds

No notes for slide

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

  1. 1. Certified Partner by Performance Tuning
  2. 2. 2 - Internal Use Only - Performance Tuning 개요 성능이란? • 각 애플리케이션 단위 응답 시간 Server Request 수행 View WebServer 웹컴포넌트 Application Server Controller Model Database Server 요 청 응 답 시 간 Transaction per Second
  3. 3. 3 - Internal Use Only - Performance Tuning 개요 성능 튜닝 준비를 위한 기본기 다지기 • TPS : Transaction Per Second • 단위 시간당 최대 처리건수 : Total Number of Transaction • TPM : Transaction per Minute • 초당 요청 건수 - RPS : Request per Second • 트랜잭션 응답 시간 : Transaction Response Time • 동시 사용자 : Concurrent User • 처리량 : Throughput
  4. 4. 4 - Internal Use Only - Performance Tuning 개요 성능 튜닝 준비를 위한 기본기 다지기 • Light Load Zone : 사용자가 증가함에 따라 선형적으로 처리량이 증가하는 단계 • Saturation Point : 애플리케이션이 수용할 수 있는 최대 동시 사용자 수를 의미 • Heavy Load Zone : 클라이언트의 부하가 상승함에도 처리량이 일정 부분 지속 • Buckle Zone : 하나 이상의 시스템 리소스(메모리,CPU 등)가 소진되어 처리량이 점점 떨어지는 단계 용어 : IBM Tuning Methodology : http://www.redbooks.ibm.com/abstracts/tips0245.html?Open
  5. 5. 5 - Internal Use Only - Performance Tuning 개요 성능 튜닝 범주 • 단순 웹 애플리케이션이라고 해서 WAS만을 고려해서는 안 된다. • 튜닝의 대상은 애플리케이션이 돌고 있는 모든 주변 상황을 고려. 애플리케이션 웹 서버 운영체제 데이터베이스 WAS CPU MEMORY DISK I/O N/W IO 네트워크 업그레이드 혹은 확장 설계, 구현, 환경 설정 파라미터 설정
  6. 6. 6 - Internal Use Only - Performance Tuning 성능 튜닝 순환 4단계 Baseline 구성 Performance Tuning 데이터 수집 STEP 1 결과 분석 STEP 2 환경 설정 STEP 3 테스트 및 결과 STEP 4
  7. 7. 7 - Internal Use Only - Performance Tuning 성능 튜닝 순환 6단계 애플리케이션 수정 솔루션 검토 (해결책) 성능 테스트 모니터링 데이터 수집 planningexecution 병목 구간 확인 솔루션 적용 optional
  8. 8. 8 - Internal Use Only - Performance Tuning 기준치(Baseline) 산정 • 애플리케이션에 대한 서비스 시작 전 성능에 대한 기준치 산정이 필요 • 성능 목표  응답 시간(Response Time), 처리량(Throughput), 리소스 사용(Resource Utilization) 관점에서 얻어야 할 성능 목표치 산정  점검 리소스 사용량 : CPU, Memory, Disk I/O, Network I/O • 테스트 계획 및 테스트 스크립트  로드 테스트 시 필요한 일정 산정 및 스크립트 구성  로드 테스트용 도구 선정 • 점검 기준표 작성  시스템, 플랫폼, 애플리케이션에 대한 점검 매트릭스 사전 작성  성능 튜닝 프로세스에 대한 일지 기록
  9. 9. 9 - Internal Use Only - 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. 10. 10 - Internal Use Only - 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. 11. 11 - Internal Use Only - 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. 12. 12 - Internal Use Only - 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. 13. 13 - Internal Use Only - Performance Tuning 파일럿 애플리케이션 추출 • 전체 기반 성능 테스트를 할 경우 모두를 테스트할 수는 없다. • 상위 트랜잭션의 80%를 차지하는 10~20%의 애플리케이션을 추출 • 애플리케이션 트랜잭션의 경우 대부분 파레토(Pareto, 80 vs 20) 법칙이 적용.
  14. 14. 14 - Internal Use Only - Performance Tuning Bench Mark Test 진행 • 조건  같은 워크 로드  같은 테스트 스크립트  같은 부하 생성 서버  모든 테스트 환경이 동일해야 함. • 변경 가능 항목  시스템 파라미터  JVM 파라미터  애플리케이션 서버 인스턴스 동일한 부하를 줄 수 있는 Machine Gun 선택
  15. 15. 15 - Internal Use Only - Performance Tuning BMT를 통한 튜닝 접근법 • 관련된 모든 수치를 최대한 높인 후, 점차적으로 Active Thread 수를 증가시키며 테스트를 시행하고, 그 결과를 반드시 TPS그래프로 그리거나 툴을 이용. • 각 Tier 혹은 머신의 CPU/MEM, 네트워크, 응용 애플리케이션이 사용하는 TCP/IP port를 모니터링하 고, 각 구간의 Saturation Point를 찾아라. • 가급적 백엔드(Backend)시스템의 Saturation Point부터 찾아야 한다. • 가장 먼저 Bottle-neck으로 도출되는 구간부터 튜닝하라. • 다시 Active thread 수를 증가시키며 동일한 테스트를 반복 시행하고 TPS의 전체적인 그래프를 통해 성능상의 변화를 확인하라. 이 과정은 계속 반복되어야 한다. <자바 서비스넷 이원영 대표>
  16. 16. 16 - Internal Use Only - 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. 17. 17 - Internal Use Only - 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. 18. 18 - Internal Use Only - 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. 19. 19 - Internal Use Only - 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. 20. 20 - Internal Use Only - Performance Tuning 테스트 결과 분석
  21. 21. 21 - Internal Use Only - 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. 22. 22 - Internal Use Only - Performance Tuning 문제가 발생할 확률 99% • 범위를 먼저 분석  웹 서버, 애플리케이션 서버, 데이터 베이스 서버 모두가 연동될 경우 어디서 문제가 발생되 었는지 범위를 좁혀야 함.  어떻게 추적할 것인가? • 문제 발생시 추적 도구를 동원.  APM(Application Performance Monitoring Tool)  Profiler 분석  Log를 이용한 결과 분석 등
  23. 23. 23 - Internal Use Only - 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. 24. 24 - Internal Use Only - Performance Tuning 깔때기 이론 • 일정한 처리량일 경우 요청 유입이 많아진다면? • 아래의 그림에서 처리량을 늘려줄 수 있는 방법은? • 하부에 DB가 있을 경우 WAS vs DB의 CPU는 어떤 상태를 보일까? 요청 유입 요청 큐잉(Request Queue) 처리량(Response) WAS 구간
  25. 25. 25 - Internal Use Only - 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. 26. 26 - Internal Use Only - Performance Tuning 성능 장애 요인 파악 – Relative Performance Problem • 하드웨어 용량 부족 (메모리, CPU 등)으로 인한 성능 저하 및 장애. • 네트워크 용량 문제 • 연계 시스템일 경우 대상 시스템의 응답 속도 저하로 인한 병목 • Back-end 트랜잭션의 상대적 성능 저하 (TP-모니터 : Tuxedo, CICS, Tmax) • EAI Adapter 처리 방식으로 인한 성능 저하(XML Parsing 등) • SQL Query 성능 저하로 인한 장애(대용량 쿼리, Full scan 등)
  27. 27. 27 - Internal Use Only - Performance Tuning 병목 해결을 위한 구조 • 근본적인 문제를 찾아야 한다. • 잘못된 접근법  WAS의 Thread 수 증가시킴  JDBC Connection Pool 증가시킴 • 유입되는 모든 요청을 처리할 수 있는 모양을 만들어야 한다. 웹 서버 플러그인 WAS DB Request
  28. 28. 28 - Internal Use Only - 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. 29. 29 - Internal Use Only - 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. 30. 30 - Internal Use Only - 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. 31. 31 - Internal Use Only - 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. 32. 32 - Internal Use Only - 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. 33. 33 - Internal Use Only - 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. 34. 34 - Internal Use Only - Performance Tuning 애플리케이션 구간 처리 시간 분석 병행 • 애플리케이션 로그를 통한 각 구간별 로그를 저장 후 문제 지점 분석 1. 요청과 동시에 UUID와 같은 식별키를 이용하여 트랜잭션 ID 채번 후 시간 로그를 남김 2. 대상 시스템 호출 직전 요청 시간을 남김 3. 대상 시스템으로부터 응답과 동시에 현재 시간에 대한 로그를 남김 4. 호출 측으로 응답을 반환하기 직전 트랜잭션 아이디와 함께 로그를 남김 • 대상 시스템 응답 시간을 얼마인가? • 시스템 내에서 처리한 순수한 시간은 얼마인가? Adapter Adapter Adapter Adapter Source Target ① ② ③④
  35. 35. 35 - Internal Use Only - Performance Tuning 사용자 및 TPS의 상관 관계 Saturation point ResponseTime User Load X 100users User Load Throughput X Saturation point Utilization User Load X Saturation point
  36. 36. 36 - Internal Use Only - Performance Tuning 가장 이상적인 모습
  37. 37. 37 - Internal Use Only - Performance Tuning 증상 1 • 다음의 그래프를 보았을 때 예상할 수 있는 문제점은?
  38. 38. 38 - Internal Use Only - Performance Tuning 예상 1 • 증상  응답 속도(Response Time)가 수행 도중 급격하게 떨어짐.  TPS가 가끔씩 비정상적으로 증가 • 예상  CPU 경합(lock contention) • 왜 발생하는가?  특정 jar 파일을 여러 개의 스레드가 액세스  Synchronized 블록에 대한 멀티 스레드 처리  예전 log4j 등의 동일 리소스 사용 • Thread dump 시 보통 ‘waiting to lock’ 형태로 발견됨. • 해결  덤프 등을 통하여 문제 발생 라이브러리 혹은 코드를 통해서 해결.
  39. 39. 39 - Internal Use Only - Performance Tuning 증상 2
  40. 40. 40 - Internal Use Only - Performance Tuning 예상 2 • 증상  사용자와 함께 TPS 증가 후 특정 시점 급격히 감소 • 예상  Gabage Collection 문제는 아닌 것으로 예상됨.  리소스에 대한 문제로 의심. • 왜 발생하는가?  너무 많은 스레드로 인한 과도한 컨텍스트 스위칭  코드 내 스레드의 sleep으로 인한 상태 변화  OS 관련 파라미터(멀티 스레드 관련)의 잘못된 설정 • 실제로 대량 스레드에 대한 context switch가 많이 발생하여 나타난 결과
  41. 41. 41 - Internal Use Only - Performance Tuning 증상 3
  42. 42. 42 - Internal Use Only - Performance Tuning 예상 3 • 증상  20 user 시점까지 정상증가 후 이후 서서히 감소 • 예상  CPU 경합 현상 패턴은 아님.  메모리 누수일 경우 이와 같은 그래프를 상당히 보임 • 왜 발생하는가?  Static Collection 객체 등에 지속적인 데이터 삽입 • 확인 방법  시스템 자원 모니터링을 통하여 문제점 파악
  43. 43. 43 - Internal Use Only - Performance Tuning 증상 4
  44. 44. 44 - Internal Use Only - Performance Tuning 예상 4 • 증상  초기 TPS는 크게 증가하나 바로 떨어진 후 안정화  CPU, 메모리 사용량 거의 없음 • 예상  Leak, CPU 경합은 없을 것으로 예상됨(단지 예상임)  적정 스레드 개수를 잘못 산정 • 왜 발생하는가?  과도한 웹 서버의 스레드, WAS 스레드 • 실제 Apache worker 스레드를 과도하게 설정하여 나타난 문제 변경후
  45. 45. 45 - Internal Use Only - Performance Tuning 증상 5
  46. 46. 46 - Internal Use Only - Performance Tuning 예상 5 • 증상  부하시 지속적으로 응답 시간 증가 후 응답없음 • 예상  Long-running 트랜잭션들이 많은 확률  대용량 쿼리를 사용하는 애플리케이션이 있을 가능성 • 대용량 쿼리 실행시 파급 효과  Heap 메모리 지속적 증가  응답 지연으로 인한 요청 큐(request queue)에 누적  수행중인 다른 트랜잭션들의 time-out 발생  메모리 확보를 위한 JVM의 과도한 GC 작업 발생  결국 서버가 다운되는 현상(복구되는 경우 거의 없음)
  47. 47. 47 - Internal Use Only - Performance Tuning 요약 • 문제가 발생하는 곳에서 모든 추론을 동원할 것. • 호기심이 문제 해결을 이끈다.  문제의 실체에 접근할 수 있는 모든 경로를 탐색하라.  모든 사건에 대해 “왜(why)?”를 붙이도록 한다. • 모든 시스템 리소스에 대한 지속적인 모니터링이 필요 • 모든 작업은 기록을 통해 하나씩 순차적으로 해결해야 한다.  한꺼번에 두 가지 파라미터 등을 변경하고 테스트 하는 것은 없다.  한번에 하나씩 테스트하고 모든 항목을 기록한다.
  48. 48. 48 - Internal Use Only - 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. 49. 49 - Internal Use Only - 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. 50. 50 - Internal Use Only - 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. 51. 51 - Internal Use Only - Performance Tuning Core 튜닝 • Native IO – Performance Pack • Execute Thread • Request Queue Size • Socket Reader • 너무 많은 실행 스레드 설정을 오히려 성능을 저하시킬 수 있음. • 새로운 스레드를 지속적으로 생성하는 애플리케이션 디자인은 피해야 함.
  52. 52. 52 - Internal Use Only - Performance Tuning JDBC Connection Pool • 커넥션 풀 사이즈 및 테스트 옵션 • Statement 캐시 • 컨넥션 풀 요청 타임아웃 • 반환되지 않은 커넥션 자동 closing 옵션 활성화 • 일반적으로 초기 연결값과 최대 연결값을 같도록 설정  데이터 베이스 등의 소켓 연결작업은 상당한 리소스를 필요로 함. • 최대 커넥션 개수는 WAS의 최대 실행 스레드(execute thread)를 넘지 않도록 함
  53. 53. 53 - Internal Use Only - Performance Tuning EJB Tuning • EJB Pool 개수 튜닝 • CMP 튜닝  Relationship-caching, 엔티티 빈에 연관된 Pre-fetching • JNDI Lookup 캐시를 통한 EJB 레퍼런스 • 동일한 JVM일 경우 Local Interface를 사용 • 애플리케이션 범위의 캐시를 사용
  54. 54. 54 - Internal Use Only - 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. 55. 55 - Internal Use Only - Performance Tuning Servlet/JSP Tuning • 세션 관리(Session Management) • 세션 저장 전략  Memory  File System  Database • 세션 속성 설정  세션 타임 아웃 시간  세션 캐시 사이즈 • JSP 사전 컴파일(pre-compile) 기능 사용 • 서블릿 재로딩 기능 • 요청마다 페이지 변경 확인 기능 제거 • <% page session=“false”%>를 통해 세션 자동 생성 기능 억제
  56. 56. 56 - Internal Use Only - Performance Tuning 요약 • 성능이란 무엇인가? • 성능 튜닝 프로세스 • 성능 측정 및 병목 파악 • 장애 진단 • 성능 패턴 분석 및 토론 • 자바 진단 • WAS 튜닝 포인트
  57. 57. 57 - Internal Use Only - OPEN SHARE CONTRIBUTE ADOPT REUSE

×