조규형님의 마소 2002년 3월 기고글을 요약했다.
DB 성능 측정에 도움이 될 듯하다...?
솔직히 장담은 못하겠다 ㅠㅠ
데이터베이스 성능에 문제가 발생한 경우 해결방법
1. 시스템의 사양을 높이는 방법
2. 튜닝
성능 관리의 단계
1. 분석단계
2. 설계단계
3. 개발단계
4. 테스트와 운영단계
1. 분석단계
업무 프로세스의 최적화, 시스템 구조 설정, 용량 산정
대략적인 경험치를 이용해 산정
2. 설계단계
논리적 설계, 데이터의 물리적 설계
논리 설계시에 도출된 ERD를 기초로 구축하고자 하는 시스템의 구조와 성능을 고려해 물리적 설계를 해야함.
요구 응답시간, 분산 데이터베이스 환경, 동시 사용자의 수, 데이터의 크기, 병렬 프로세싱 등을 고려.
3. 개발단계
SQL을 효율적으로 작성
옵티마이저의 이해
인덱스 정책
4. 테스트, 운영단계
OS튜닝
네트워크 튜닝
데이터베이스 튜닝
애플리케이션 튜닝
----
개발, 테스트, 운영 단계에서 고려해야 하는 오라클과 연동한 OS, 네트워크 튜닝에 대해 알아보자.
OS튜닝
OS에는 CPU, 메모리, 디스크I/O가 대표적 튜닝 대상.
통상적으로 OS튜닝은 전체 성능의 10% 이상의 성능 향상을 기대하기 힘들다.
다른 부분의 튜닝을 끝내고도 만족할만한 성과가 나타나지 않을 때 자세한 OS 튜닝으로 좋은 효과가 나타나는 경우가 있다.
CPU튜닝
유닉스의 sar 명령을 이용해 CPU의 사용량을 볼 수 있다.
# date; sar 3 10
2012년 9월 14일 금요일 오후 01시 41분 55초
SunOS 5.10 Generic_137111-01 sun4u 09/14/2012
13:41:55 %usr %sys %wio %idle
13:41:58 3 7 0 90
13:42:01 3 2 0 95
13:42:04 8 9 0 83
13:42:07 47 19 0 33
13:42:10 20 18 0 62
13:42:13 15 14 0 70
13:42:16 12 8 0 80
13:42:19 6 6 0 89
13:42:22 4 4 0 92
13:42:25 4 3 0 93
Average 12 9 0 79
CPU는 정상적인 운영 상태에서 권장하는 사용 정도는 70~80%.
시스템의 사용량이 많은 시점을 고려하여 20~30%의 idle time이 유지되어야 함.
idle이 0%라는 의미는 CPU를 100% 사용한다고 볼 수도 있겠지만, 100% 이상을 사용해 CPU의 병목현상이 발생한다고 판단.
CPU가 부족하다고 판단된 경우에는 문제시되는 부분을 찾아 해결하거나 CPU 증설을 고려.
CPU의 사용량이 과다하게 나타났을 경우라면 우선 %usr, %sys, %wio의 비율을 비교.
데이터베이스를 사용하는 애플리케이션이 운영되는 시스템일 경우에는 %usr > %sys > %wio의 순으로 나타나는 것이 정상적.
%wio의 수치가 가장 높게 나타날 경우에는 CPU의 사용이 I/O waiting을 위해 사용된다고 추정가능함.
I/O의 병목현상을 해소시켜 주거나 유닉스 파일 시스템의 오퍼레이팅 버퍼 캐시의 활용도를 높여주면 전체적인 CPU 사용량은 감소하게 됨.
버퍼 캐시의 활용도를 높여주는 것보다는, I/O를 분산시키는 것이 훨씬 효과적임.
%sys의 사용량이 높을 경우에는 정상적이지 않은 프로세스가 CPU를 많이 점유하는 경우. 이런 경우 현재 시스템에서 CPU를 많이 사용하는 프로세스를 찾아 원인을 분석.
(현재 Solaris에서는 top이 없어서 prstat으로 확인가능하다.)
프로세스 분석에서 주의 깊게 봐야하는 것은 %CPU, %MEM, TIME.
각각 CPU 점유율, 메모리 점유율, 자동 후 CPU의 누적된 사용치.
하나의 프로세스가 CPU 하나를 99%나 100%를 차지하고 오랜 시간(1분 이상) 사용할 경우 이프로세스가 어떤 프로세스인지, 그리고 어떤 작업을 하는지 파악해야 함.
메모리 튜닝
유닉스 시스템은 Physical 메모리의 한계를 극복하기 위해 버추얼 메모리 개념을 사용해 메모리를 운영하는데, 버추얼 메모리의 크기는 'Physical 메모리 + 버추얼 메모리(Swap disk)'다. 버추얼 메모리는 page의 집합으로 구성되며, page의 크기는 보통 4KB 또는 8KB이다. Page란 메모리는 나누는 단위인데, 가능한 한 많은 Free 메모리를 유지하기 위해 현재 사용하고 있지 않은 page를 disk로 저장한다(page-out). 만약 현재의 어떤 프로세스가 physical 메모리에 존재하지 않은 page를 요청하면(page fault) disk에 저장한 page를 메모리로 읽어 들인다(page-in).
Swapping은 간단히 설명하자면 paging보다는 좀 더 큰 단위의 작업이다. paging이 page 단위의 관리를 한다고 하면, swapping은 프로세스가 사용하는 모든 page를 관리한다. 그러므로 다시 그 프로세스가 돌아가기 위해서는 관련된 모든 page가 메모리로 읽혀져야 하ㄴ므로 성능에 막대한 지장이 있다.
시스템이 정상적으로 운영되기 위해서는 Swapping은 절대 발생하지 않아야 하며, Paging도 되도록 겹쳐 발생하지 않도록 해야 한다. 그러므로 메모리를 모니터링할 때는 주로 paging과 swapping의 유무와 양을 중점적으로 분석한다. Paging과 Swapping의 내역을 보려면 다음과 같은 명령을 사용하면 된다.
paging
# sar -p 3 5
SunOS 5.10 Generic_137111-01 sun4u 09/14/2012
14:43:48 atch/s pgin/s ppgin/s pflt/s vflt/s slock/s
14:43:51 20.07 2.96 2.96 1.32 37.50 0.00
14:43:54 89.11 5.28 5.28 211.22 511.22 0.00
14:43:57 119.02 5.25 26.23 242.30 1349.84 0.00
14:44:00 142.76 7.24 29.28 302.96 705.92 0.00
14:44:03 284.21 17.11 85.86 767.76 1428.95 0.00
Average 131.05 7.57 29.93 305.13 807.24 0.00
swapping
# sar -w 3 5
SunOS 5.10 Generic_137111-01 sun4u 09/14/2012
14:44:06 swpin/s bswin/s swpot/s bswot/s pswch/s
14:44:09 0.00 0.0 0.00 0.0 5491
14:44:12 0.00 0.0 0.00 0.0 4849
14:44:15 0.00 0.0 0.00 0.0 2001
14:44:18 0.00 0.0 0.00 0.0 3976
14:44:21 0.00 0.0 0.00 0.0 2094
Average 0.00 0.0 0.00 0.0 3682
시스템 내에 paging, swapping이 많이 발생하면 시스템의 성능을 보장할 수 없다. 현재 사용 가능한 Physical 메모리 내에 대부분의 사용 메모리가 들어갈 수 있도록 시스템을 재구성해야 한다.
현재 1GB의 메모리가 있다고 가정할 때, 유닉스 커널이 사용하는 메모리, 오라클 데이터베이스의 SGA영역, 개별 프로세스가 점유하는 메모리의 합이 일반적으로 고려되는 메모리의 양이다. 오라클의 SGA영역은 OS의 전체 메모리 중 40~60%를 사용하도록 지정한다.
만약 OS에 Swapping, Paging이 많이 발생해 메모리가 부족하다고 판단될 경우에는 메모리의 사용량을 줄여 Swapping, Paging을 없애야 한다. 따라서 초기 설정값을 지정하고 메모리의 사용량∙Swapping∙Paging의 양을 보고 SGA를 좀더 늘리거나 줄이면서 최적화된 메모리 사용량 구조를 도출하면 된다.
I/O 튜닝
... 시간관계상 다음 기회에...
댓글 없음:
댓글 쓰기