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

353 views

Published on

  • Be the first to comment

  • Be the first to like this

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

  1. 1. © 2009 CUBRID Co, Ltd. All rights reserved. Chapter 1. 개발환경구성 3주차 기술본부 2013.03.29 1
  2. 2. © 2009 CUBRID Co, Ltd. All rights reserved. 목차 1.현실적 시스템 성능저하 주요 원인 2.시스템 성능관리 3.오라클 성능 분석 체크리스트 별첨. 금주 세미나자료
  3. 3. © 2009 CUBRID Co, Ltd. All rights reserved. 0. W 차장은 이렇게 일한다.(큐브리드는 어떻게 일하는가?) 요새 고민은 어떻게 피드백을 빨리 할까 입니다. 빠른 피드백의 장단점이 있겠지만 단점은 어떻게 보완 할 것인지 고민입니다. 그래도 피드백이 늦어져서 하지 말아야 할 일을 반복 하는 것 보다는 낳으니까요. 1 2 피드백(feedback, 되먹임, 되알 림, 환류, 송환)은 어떤 일로 인 해 일어난 결과가 다시 원인에 영향을 미치는 자동 제어 원리이 다. 증가된 출력을 더 증가시키는 양 성 피드백(positive feedback)과 증가된 출력을 감소시켜 다시 안 정한 상태로 되돌리는 음성 피드 백(negative feedback)으로 나눌 수 있다. [출처] 위키페디아 - http://ko.wikipedia.org/wiki/%ED%94%BC%EB%93%9C%EB%B0%B1
  4. 4. © 2009 CUBRID Co, Ltd. All rights reserved. 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 참고
  5. 5. © 2009 CUBRID Co, Ltd. All rights reserved. 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)
  6. 6. © 2009 CUBRID Co, Ltd. All rights reserved. • 오라클 성능 분석 체크리스트 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가 최적화 되어 있는지 검토 대부분은 잘되어 있음 10 Join Method는 옵티마이저가 업무 성격에 맞게 생성 되는지 검토( Nested Loop, Sort Merge , Hash Join) 11 NL 조인시 선행 테이블을 잘 선정하여 Access Path가 최적화 되는지 검토 12 응용 소프트 파싱을 하기 위한 데이터 바인딩을 하고 있는지 검토 prepareStatement 를 사용하여 바인딩 할것 13 부하를 줄이기 위한 응용 설정이 최적화 되어 있는지 검토 타 DBMS의 경우 다음과 같은 분석 체크리스트가 존재하며 CUBRID 분석 체크리스트도 만들 필요가 있음.
  7. 7. © 2009 CUBRID Co, Ltd. All rights reserved. 4. CUBRID 지식 분류체계 案 CUBRID 지식 분류체계 案
  8. 8. © 2009 CUBRID Co, Ltd. All rights reserved. 5. 역할별 튜닝 접근 Approach 시스템 성능 문제 발생시 역할별 튜닝 접근 방법은 다음과 같을 수 있습니다. 물론 쉬운 방법도 어려운 방법도 있습니다. 개발 단계별 접 근 방법도 분류해 볼 수 있는 방법이라고 생각합니다. SE DBA 개발자, SE DBA, 개발자 DBA DBA, 개발자 개발자, DBA, SE
  9. 9. © 2009 CUBRID Co, Ltd. All rights reserved. 6. 지식공유(Top down Approach) 1/2 퇴근시간 TV드라마 시청시간 개인시간 취침시간 출근시간 출근시간
  10. 10. © 2009 CUBRID Co, Ltd. All rights reserved. 6. 지식공유(Top down Approach) 2/2 쉬는날 평일평일

×