시간 기반의 응답시간 분석

전산 시스템의 성능 최적화는 사용자가 인지하는 응답시간을 최적화하는 것이다. 따라서 사용자가 시스템을 사용할 때마다 응답시간에 불만을 느끼지 못하도록 시스템 성능을 최적화하는 대안 수립과 상황 예측은 필수적이다.

어떤 시스템을 일일 단위의 응답시간 분석을 수행한 결과, 24시간 단위로 모든 애플리케이션이 일일 4~5시간 정도를 사용됐다고 하면 별반 문제가 없다는 결론이 도출될 수 있다. 특히 CPU가 여러 개가 존재하는 시스템에서는 애플리케이션에서 사용 가능한 시간이 실질적으로 24시간의 배수가 될 수 있기 때문에 일일 24시간 가운데 4~5시간 사용은 그다지 사용량이 많지 않다고 볼 수 있다. 특히 기존 방식의 시스템 분석 방법론으로는 특정한 문제점을 찾아낸다는 것은 매우 힘들다. 그러나 시간 단위의 응답시간 분석으로 특정 시간대에도 응답시간이 사용자가 느끼기에 최적화돼 있는지에 대한 분석이 수행돼야 한다.

예를 들어, CPU가 2개인 시스템에서 12시 10분부터 12시 20분까지의 응답시간 분석을 수행했다고 하자(그림 2). 그 결과 총 애플리케이션이 사용한 시간이 30분을 초과했다면, 이 시스템은 전체적인 사용량으로는 별다른 문제가 없겠지만 사용자는 특정 시간의 응답시간에 문제점을 느낀다고 가정할 수 있을 것이다.

특히 사용자가 특정 시간대의 응답시간에 불만을 느낀다면, 전체적인 일자별 시스템 분석 방법론도 중요하지만 반드시 시간대별 응답시간 분석을 통해 24시간 최적화된 시스템을 운영할 수 있도록 해야 한다. 응답시간 중 처리시간은 한정적인 시스템 자원의 사용량을 초과할 수 없지만, 대기시간의 경우에는 사용자가 요청을 하면 할수록 급격히 증가하는 형태를 보일 수 있다. 따라서 대기시간이 처리시간보다 커지면 커질수록 오라클의 대기 이벤트도 다양해지고 복잡하게 나타나게 되므로 정확한 원인 분석이 힘들어지게 된다.

(그림 2)는 특정 시간대에 사용자의 시스템 사용이 집중되는 형태를 보여준다. 따라서 특정 시간대에 발생한 애플리케이션과 세션 그리고 단위 SQL의 응답시간 분석을 통해 분석 기준을 설정하고 최적화할 수 있는 방안을 반드시 찾아야 한다.

특정 시간대에 집중 사용된 애플리케이션과 SQL을 분석한 결과, 상위 2개의 애플리케이션과 각 애플리케이션에서 수행된 각 상위 SQL이 이 시간대의 시스템 자원의 90% 이상을 소요했음을 확인할 수 있다. 결국 2개의 애플리케이션과 2개의 SQL을 분석해 24시간 최적화된 애플리케이션을 제공할 수 있고 사용자는 시스템 성능에 만족하게 됐다.

결국 시스템 응답시간 분석을 통해 전체적인 응답시간 분석을 수행한 후, 시간 기반의 응답시간 분석과 특정시간 기반의 애플리케이션 응답시간 분석을 통해 최종 사용자의 응답시간을 분석해 최적화하는 방안이 가장 효과적인 방법이라고 할 수 있겠다. 기존의 분석 방법론과는 달리, 응답시간 분석 이후 최종 사용자가 불만을 느끼지 않는 시간대의 애플리케이션 성능 분석은 배제하는 방법으로 접근하는 것이다.

애플리케이션 중심의 응답시간 분석시 장점

기존의 방법론은 사용자의 입장에서 응답시간을 분석하는 방법론과는 상당한 차이가 있다. 단순히 DBMS 내부의 딕셔너리에 남는 정보를 이용한 비율 기반 분석(ratio based analysis)의 기존 시스템 성능 분석은 사용자 중심이 아닌 DBMS 중심적인 분석 방법이다. 이런 기존 방법론은 사용자의 사용 유형과 사용 비중이 전혀 고려되지 않은 상태에서 단순 수치로 서버의 효율성을 체크하는 방법이기 때문에, 사용자에게 만족을 주기 어렵다.

사용자의 응답시간에 사용자 스스로가 만족하도록 하는 것이 가장 중요한 요소이고, 어떤 분석 방법론을 사용하더라도 시작점은 반드시 사용자의 응답시간 만족도 분석에 맞춰야 한다. 애플리케이션 중심의 응답시간 분석에 있어서 가장 중요한 요소는 사용자가 사용하는 애플리케이션이 만족할 만한 시간내에 원하는 답을 추출하는 것이다.

그렇지 않다면 그 시간대에 보여주는 시스템 응답시간을 통해 처리시간과 대기시간의 분석을 선행하고 분석의 표준을 설정한 뒤, 각 애플리케이션 레벨의 응답시간 분석을 통해 최적화 가능한 요소를 찾아내 사용자가 현재 수준에서 더 많은 애플리케이션을 수행하더라도 응답시간에 불만을 갖지 않도록 하는 분석 방법이다.

특정 애플리케이션에서 대기시간이 급증한다면 대기시간의 비중도를 분석해 CPU, I/O, 메모리 등과 같은 시스템 자원에 의한 것인지, 아니면 latch, enqueue, parameter 등과 같은 오라클 내부 자원에 의한 것인지를 분석한 후 문제 소지가 있는 성능 요소를 체크한다. 사용자가 불만을 느낄만한 요소가 발견되지 않거나 대기시간은 길지만 전체 응답시간에서 살펴봤을 때 큰 문제가 아니라면, 분석 대상에서 배제하는 형태로 접근한다. 이 때 최적화하는 방안은 여러 가지가 있으나 간략하게 설명하면 다음과 같다.

CPU 사용량이나 I/O 자원의 대기시간이 많다면 애플리케이션에서 사용하는 SQL의 효과적인 실행 계획 제어 또는 애플리케이션 수행 시간 재분배(load balancing) 등의 방법으로 최적화할 수 있다.

만약 공유 풀 대기와 내부 자원 대기의 값이 크다면 공유 풀의 크기, 애플리케이션의 SQL 사용 형태, 운영 시간중의 오브젝트 구조 변경, 불분명한 오브젝트, 공유 풀 관련 래치(latch)의 적절성 등의 다양한 요소들을 점검할 수 있다. 각각의 시스템 환경에 따라 분석 방법이 달라진다고 할 수 있다. 버퍼 대기와 내부 자원 대기의 값이 크다면 버퍼 캐시를 비효율적으로 사용하는 SQL을 분석하거나, 버퍼 캐시의 크기, 버퍼 캐시 관련 래치의 적절성 등의 요소를 점검할 수 있다.

시행착오 줄이는 애플리케이션 중심의 접근

이 외에도 다양한 요소가 있지만 위의 예를 든 것은 DBMS 서버 튜닝은 DBMS 입장에서 바라보면 효과적인 분석이 힘들어지고 많은 시행착오를 겪게 되기 때문이다. DBMS 관련 대기시간은 결국 애플리케이션에서 유발하는 것이고 이런 애플리케이션이 특정 시간대에 집중적으로 수행돼 DBMS 내부 자원의 경합이 발생하게 된다. 결국은 처리시간보다는 대기시간을 많이 소요하게 되는 것이다. 따라서 이런 경합을 유발시키는 애플리케이션을 중심으로 분석 접근하면 시행착오도 줄이고 가장 확실하고 효과적인 최적화 방안이 유도될 것이다.

SQL 튜닝, DBMS 서버 튜닝, 운영체제 튜닝 등의 모든 요소를 각기 독립적인 요소로 분석하는 것이 아니라, 애플리케이션 입장에서 애플리케이션의 수행 내역을 분석하며 각 요소의 튜닝을 연계해 분석해야 할 것이다. @