Chap1. 개발환경구성 3주차 20130329

© 2009 CUBRID Co, Ltd. All rights reserved.

Chapter 1. 개발환경구성 3주차

기술본부

2013.03.29

1


목차

1.현실적 시스템 성능저하 주요 원인

2.시스템 성능관리

3.오라클 성능 분석 체크리스트

별첨. 금주 세미나자료


0. W 차장은 이렇게 일한다.(큐브리드는 어떻게 일하는가?)

요새 고민은 어떻게 피드백을 빨리 할까 입니다. 빠른 피드백의 장단점이 있겠지만 단점은 어떻게 보완 할 것인지 고민입니다.

그래도 피드백이 늦어져서 하지 말아야 할 일을 반복 하는 것 보다는 낳으니까요.

1 2

피드백(feedback, 되먹임, 되알

림, 환류, 송환)은 어떤 일로 인

해 일어난 결과가 다시 원인에

영향을 미치는 자동 제어 원리이

다.

증가된 출력을 더 증가시키는 양

성 피드백(positive feedback)과

증가된 출력을 감소시켜 다시 안

정한 상태로 되돌리는 음성 피드

백(negative feedback)으로 나눌

수 있다. [출처] 위키페디아 -http://ko.wikipedia.org/wiki/%ED%94%BC%EB%93%9C%EB%B0%B1


1. 현실적 시스템 성능저하 주요 원인

일반적인 소프트웨어 프로젝트 중 전체 시스템의 성능저하의 주요 원인은 다음과 같으며 대부분의 경우 DB와 관련된 이슈가 대다수임.

DB근간 시스템에서의 성능저하 주요 원인

• 대부분의 성능저하 주요인은 DB관련 비효율

• 성능저하의 핵심은 CPU/Memory 부하가 아닌 비 효율적인 I/O

• 당사의 수많은 성능개선 컨설팅 경험에 비추어 90% 이상이 DB처리 효율화가 핵심

– RDB에 적합한 최적화 DB Design과 Optimizer가 최고의 효율을 낼 수 있는 옵티마이징 전략과 집합개념의 고성능 SQL이 성공의

열쇠

20%

DB Config. Design

15%

5%

Applications &

DB Design

70%

CPU 부하 15%Memory 부하

10%

기타

5%

I/O 비효율

70%

시스템 성능저하의 요인DB설계의 문제와 응용프로그램 문제로

인한 성능저하 요인

System Design

H/W Resources

※ 별첨4. 튜닝워크샵교재v1_20040712.ppt 참고


2. 시스템 성능관리

구축 및 운영 System이 최적의 자원으로 최적의 성능(시간/응답속도)을 발휘할 수 있도록 설계와 구현 응용시스템을 조화롭게 유지 개

선하는 기술

• Key factor base on Performance

• H/W Related Issues

– CPU , Memory , N/W , Disk … System config resources 부족

• S/W Related Issues

– DBMS

• DB Design , Index Design , Optimizing Strategy , SQL 효율 …

– Application Architecture

• 2-Tire , 3-Tier , EJB …

• OLTP , OLAP(adhoc) , Batch …

• C , COBOL , PL/SQL , JSQL , SP …

• Business Process Requirement

– 업무 처리 방식의 문제 등

– Load Balancing 정책 등

※ 별첨4. 튜닝워크샵교재v1_20040712.ppt 참고

별첨2. 퍼포먼스 강의 자료

_(Unix Performane

Management)


• 오라클 성능 분석 체크리스트

3. 오라클 성능 분석 체크리스트

순서 구분 체크리스트 검토 사항 및 권고 사항

1

설계

DB 설정이 최적화 되어 있는지 검토 OLTP,DSS에 맞게 셋팅 되어 있는지

2 테이블스페이스 설계가 I/O분산이 적절히 되도록 검토 TABLE과 INDEX는 테이블스페이스 분리 할것

3 오라클 메모리 설정이 최적화 되어 있는지 검토 가용메모리의 70~80% 셋팅 현재 1.2G -> 4G로 올릴것

4 물리 설계가 최적화 되어있는지 ( 파티셔닝, IOT) 검토 응용과 Data Access Path 에 의해 결정

5 인덱스 설계가 최적화 되어 있는지 검토 응용과 Data Access Path 에 의해 결정

6

서버튜닝

메모리 구조 튜팅( Buffer Cache, Large-Pool, Log Buffer , PGA ) Buffer Cache 4G , Large 20M, PGA 1G

7 CBO Opitmizer일 경우 통계 데이터 Analyze는 충분히 샘플링 되는지 검토 잘됨

8 Disk I/O를 분산하도록 설정이 되어 있는지 SAME으로 구성할 것을 권장함

9

SQL

Access Path가 최적화 되어 있는지 검토 대부분은 잘되어 있음

10Join Method는 옵티마이저가 업무 성격에

맞게 생성 되는지 검토( Nested Loop, Sort Merge , Hash Join)

11 NL 조인시 선행 테이블을 잘 선정하여 Access Path가 최적화 되는지 검토

12

응용

소프트 파싱을 하기 위한 데이터 바인딩을 하고 있는지 검토 prepareStatement 를 사용하여 바인딩 할것

13 부하를 줄이기 위한 응용 설정이 최적화 되어 있는지 검토

타 DBMS의 경우 다음과 같은 분석 체크리스트가 존재하며 CUBRID 분석 체크리스트도 만들 필요가 있음.


4. CUBRID 지식 분류체계 案

CUBRID 지식 분류체계 案


5. 역할별 튜닝 접근 Approach

시스템 성능 문제 발생시 역할별 튜닝 접근 방법은 다음과 같을 수 있습니다. 물론 쉬운 방법도 어려운 방법도 있습니다. 개발 단계별 접

근 방법도 분류해 볼 수 있는 방법이라고 생각합니다.

SE

DBA

개발자, SE

DBA, 개발자

DBA

DBA, 개발자

개발자, DBA, SE


6. 지식공유(Top down Approach) 1/2

퇴근시간TV드라마 시청시간

개인시간취침시간 출근시간

출근시간


6. 지식공유(Top down Approach) 2/2

쉬는날 평일평일

Documents

Chap1. 개발환경구성 3주차 20130329