해프닝

이곳 Tokyo는 올 여름 소낙비가 많다. 요 2~3주동안, 한낮의 더위를 식히려는 듯 저녁이 되면 어김없이 굵은 빗방울이 쏟아져 내린다. 시원해서 좋지만, 기대하고 있던 저녁죠깅을 거르기가 일쑤다. 늦더위가 길어지려나…

정기적으로 상주하고 있는 고객사에서 어느 날 운영팀 전원이 테스트로 분주해 하고 있었다. 이야기를 들어보니 관리하는 파일이 늘어난 관계로 NAS를 2배로 증설을 해야 하는데 운영환경에 앞서 검증환경에서 늘렸더니 AP의 처리시간이 크게 증가했다는 것. 몇번의 추가테스트를 실시했지만 결과는 마찬가지였다. 원인을 찾아내지 못하면 운영환경에서의 디스크 증설 자체가 어려운 관계로 디스크 납품사로부터의 지원을 받아 디스크 성능도 측정해 보았지만 디스크의 Read/Write성능은 오히려 개선되었다는 보고서가 올라왔다. 그럼 왜 느려졌을까?

DB 내부관리대상 데이타도 아니었기에 DB성능은 애초부터 분석대상외였지만 지푸라기라도 잡는 심정으로 MaxGauge로그의 분석의뢰가 왔다. 분석결과는 흥미로웠다.
- CPU시간 증가 및 대기시간증가
- CPU시간 증가분의 51%가 ‘parse time cpu’
- 대기시간증가분의 61%가 SQL Parsing관련 대기시간

위 측정결과로 SQL파싱시간이 원인인 것으로 추정되었기에 추가 테스트를 해보았다.

<테스트시나리오>

특정 테이블을 검색하는 리터럴SQL를 10000회(리터럴변수:1~10000) 실행

<테스트케이스>
CASE-1：CURSOR_SHARING=SIMILAR, 검색대상 칼럼에 히스토그램통계 작성(고객환경)
CASE-2：CURSOR_SHARING=FORCE, 검색대상 칼럼에 히스토그램통계 작성
CASE-3：CURSOR_SHARING=SIMILAR, 검색대상 칼럼에 히스토그램통계 삭제
CASE-4：CURSOR_SHARING=FORCE, 검색대상 칼럼에 히스토그램통계 삭제

<테스트결과>

결과적으로 ‘CURSOR_SHARING=SIMILAR, 검색대상 칼럼에 히스토그램통계 작성’의 환경에서 리터럴SQL이 성능저하에 치명적이라는 것이 증명이 되었다. 재미있는 사실은 운영환경은 매일의 DB재기동으로 리터럴SQL의 영향이 크지 않았지만 테스트 환경은 몇달동안 Shared Pool의 Flush가 없었기 때문에 그 사이의 수많은 테스트의 리터럴SQL의 누적영향으로 이번 성능저하현상이 나타났다는 것이다. 결국 테스트의 오류가 원인으로 밝혀짐에 따라 시나리오에 Shared Pool 및 Buffer Cache의 Flush를 추가한 테스트를 진행함으로써 디스크추가은 순조롭게 진행되었다. 그리고 CURSOR_SHARING의 조정과 히스토그램통계의 자동수집 리터럴SQL대응에 대한 검토는 또다른 숙제로 남았다.

이번의 해프닝으로 다시금 절감하게 된 것은 MaxGauge가 폭넓은 데이타를 상세하게 제공한다는 사실은 알고 있지만 실제로 고객사의 엔지니어는 충분히 활용하고 있지 못하는게 현실이다. 사용자의 기술적인 이해가 부족한 면도 있지만 그보다는 툴을 활용하는 사례 및 방법이 충분하게 개발되고 제공되지 못한 부분이 크게 다가온다. 마침 지난주에 제품교육이 있었는데 활용TIP중에 하나로 위의 사례 ‘특정시간대의 성능계측 및 진단’을 추가하였다. 현장엔지니어의 누군가가 SQL파싱시간이 변화된 것을 간단하게 확인했더라면 이번의 소동은 없지 않았을까? 반성해 본다. 그리고 제품사업의 기본을 다시금 새겨본다.

어떤 제품이라도 고객이 잘 쓰게끔만 하면 성공한 제품이다.