태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[티팩] 나에게 데이터를 달라!

오라클 2010.06.10 16:51
아래 대화 내용은 (거의) 실제 상황입니다.

A : 현재 특정 프로세스가 PGA를 3G이상 사용하면서 시스템에 문제를 일으키고 있습니다.

B : PAT(PGA Aggregate Target)가 얼마나 되나요?

A : 이 시스템의 PAT(PGA Aggregate Target)는 1.8G에 불과합니다. 어떻게 PGA의 크기가 PAT보다 커질 수 있습니까?

B : PAT는 정렬등에 필요한 작업 영역을 할당하기 위한 가이드입니다. 가령 PAT가 1.8G라고 하면 하나의 프로세스가 사용 가능한 최대 작업 크기 영역은 최대 수백M일 것입니다. 이 영역보다 큰 데이터를 정렬하면 Disk I/O가 발생한다는 의미이지 프로세스가 사용 가능한 물리적 메모리를 수백M로 제한한다는 것을 의미하지는 않습니다.

A : 그렇군요. 그럼 AWR과 같은 성능 데이터를 저장하고 있으면 특정 프로세스가 3G의 메모리를 사용한 이유를 알 수 있나요?

B : 흐음...


AWR이나 Maxgauge, SpotLight와 같은 모니터링 솔루션을 이용하는 경우 대부분의 대화는 여기서 단절되고 맙니다.

엔지니어들의 실력이 부족해서가 아닙니다. 데이터가 부족하기 때문입니다.

위와 같은 유형(메모리의 증가와 그에 의한 성능 저하)의 성능 문제는 일반적인 모니터링만으로는 원인을 밝히는 것이 불가능합니다. 이런 문제는 모니터링의 영역이 아닌 트러블슈팅의 영역에 해당하기 때문입니다.

모니터링 데이터가 제공해주는 것은 "결과"에 불과합니다. 즉 "메모리 사용량이 3G이다"라는 결과를 보고 있는 것이지요. 그 "이유"를 밝히는 것은 사람의 몫이고 트러블슈팅의 영역입니다.

만일 이 시점에 적절한 데이터가 없다면? 모든 것이 추측에 불과하게 됩니다. 그나마 대부분은 추측조차도 할 수 없는 경우들입니다. 앞으로 몇 차례의 포스트를 통해서 이야기하고자 하는 것이 이런 것들입니다. 일반적인 모니터링 만으로는 그 원인을 알 수 없는 성능 문제들에는 어떤 유형이 있고, 각 유형별로 어떤 데이터를 어떻게 수집해서 어떻게 분석해야 하는가?

이것은 래치, 락, 뮤텍스, 메모리, 함수, 덤프, 진단이벤트 등이 어우러지는 복잡하면서 재미있는(혹은 너무나 재미없는?) 세계입니다. 앞으로 잘 이야기를 풀어갈 수 있을지 모르겠지만, 가능한 재미있게 풀어봐야겠습니다.

PS) 위에서 언급한 것과 같은 성능 문제의 경우에는 어떻게 해야 트러블슈팅이 가능할까요? 이미 비슷한 경험을 하신 분들도 많겠지만...

저작자 표시
신고
Trackback 0 : Comments 2
  1. 한정윤 2010.06.11 12:58 신고 Modify/Delete Reply

    매일 들어오는 블로그인데, 바쁘신게 보이네요...
    티팩....발음도 좋고....기대되네요...
    항상 감사합니다..

  2. EJql 2010.06.14 00:39 신고 Modify/Delete Reply

    티팩.. 좋은 프로젝트를 하십니다.
    과연 베타를 끝내신 후는 느낌이 오지만 그전에 마음껏 사용하고 마음껏 피드백을 할 수 있게 노력하겠습니다.

Write a comment

티스토리 툴바