티스토리 뷰

이 글은 내가 InterMax라는 툴을 지원할 때 작성한 글이다. PC에서 썩고 있길래 여기에 올린다.

1)     WAS에서 성능이란 무엇인가?

우선 Web Application Server(이하 WAS)에서 성능을 분석하는 방법을 논의하기 이전에 WAS에서 성능이란 무엇인가에 대해 먼저 생각을 필요가 있다. 쉬운 설명을 위해 자동차를 예로 들어 보도록 하자. 자동차는 용도에 따라 다양한 종류가 있다. 우리 주위에서 흔히 있는 고급 승용차, 덤프 트럭 그리고 경주용 자동차까지 상당히 다양한 분류가 존재한다.

그렇다면 이러한 자동차의 성능은 어떻게 얘기 있을까? 아마도 앞서 열거한 자동차들에 대해 같은 지표로 성능을 얘기할 수는 없을 것이다. 속도만으로 성능을 따진다면 경주용 자동차를 따라갈 수는 없을 것이고 힘으로 하자면 덤프트럭을, 그리고 승차감을 기준으로 하면 고급 승용차가 가장 우선할 것이다.

경주용 자동차의 경우 가장 빠른 차를 가늠하는 경주에서 우승을 하기 위해 설계되었고 덤프트럭의 경우 가장 많은 짐을 실어 나르게끔 설계 되었으며 고급 승용차는 승객이 가장 편안하게 목적지까지 있도록 고안이 되었을 것이다. 이는 경주용 차는 짐을 싣거나 편안하게 목적지까지 가는 것과 속도 사이의 Trade-off 관계가 성립되었을 것이 명백하고 다른 종류의 자동차도 Trade-off 관계가 성립되어 있을 것이다.

경우 자동차마다 성능을 평가하는 지표는 당연히 경주용 자동차는 속도일 것이고 덤프트럭은 , 그리고 고급 승용차는 안락함이 선택될 것이다. 이는 자동차의 목적과 설계방향에 부합된다고 있다.


그렇다면 궁극적으로 우리가 석하고자 하는 시스템들의 성능을 생각하기 위해서는 역시 시스템의 목적과 설계방향을 생각 보지 않을 없다. WAS 초고속 네트워크가 보편화 되어 인터넷의 접근이 쉬워지자 기업들은 불특정 다수의 사람들을 대상으로 IT자원을 활용하는 Service 확장하기 시작했다. 그러면서 발생한 Application 배포, 편의성 등의 문제점을 해결하기 위해 Application 위치를 Client에서 Server측으로 이전하면서 점차로 주류가 시스템이라 있다.

WAS 기본 기능은 프로그램 실행 환경과 데이터베이스 접속 기능을 제공하는 , 여러 개의 Transaction 관리하는 , 그리고 업무를 처리하는 비즈니스 로직을 수행하는 등으로 생각해 있다. 그렇다면 다시 말해 WAS 불특정 다수의 사람들을 대상으로 기업의 서비스를 제공하기 위해 Transaction 단위로 Data Source 망라한 Application 탑재한 것이라 있다.

여기서 키워드는 불특정 다수, 서비스, Transaction 등을 꼽을 있다. 우선 불특정 다수라는 것은 가변적인 사용자 , 예측하기 어려운 이용 형태라는 특징으로 분리해볼 있다. 그리고 서비스라고 하는 것은 WAS라는 시스템을 바라보아야 관점으로 이해할 있다. 기업이 고객에게 제공하는 것들을 서비스라고 기업이 WAS 통해 제공하는 것이 비즈니스에 영향을 미칠 있다는 점이다.

마지막으로 Transaction인데 Transaction 의미를 Wikipedia에서는 다음과 같이 정의하고 있다.

“Transaction ATM, 데이터베이스 등의 시스템에서 사용되는 쪼갤 없다는 업무처리의 단위이다. 영어의 Transaction 거래를 뜻한다. 예를 들어 돈을 주었는데 물건을 받지 못한다면, 거래는 이루어 지지 못하고 원상태로 복구되어야 한다. 이와 같이 쪼갤 없는 하나의 처리 행위를 원자적 행위라고 한다. 여기서 쪼갤 없다는 말의 의미는 실제로 쪼갤 없다기 보다는 만일 쪼개질 경우 시스템에 심각한 오류를 초래할 있다는 것이다. 이러한 개념의 기능을 ATM 또는 데이터베이스 등의 시스템에서 제공하는 것이 바로 Transaction이다. Transaction 사용자가 시스템에 요구를 시작하여 시스템 내의 처리, 시스템에서 사용자에게 응답하는 모든 처리를 포함한다.”

Transaction이라는 키워드는 사실 WAS 기본기능에 해당되는 내용을 포괄한다고 있다. WAS 관리하는 단위로서의 Transaction 당연히 비즈니스 로직을 내용으로 하고 있고 그것은 데이터베이스의 접속에서 데이터 요청 변경, 그리고 데이터베이스에서 가져온 결과를 처리하고 보여주는 프로그램 실행환경으로 구체화되기 때문이다.

그렇다면 WAS 기업의 비즈니스를 위하여 불특정 다수에게 Transaction 단위로 서비스를 제공하는 시스템으로 정의 내릴 있으며 WAS 시스템의 목적은 당연히 비즈니스를 위해 서비스를 불특정 다수에게 원활하게 제공하기 위한 것으로 생각할 있다. 그렇다면 WAS 성능을 판단하는 지표도 이에 상응해야 것은 너무도 당연할 것이다.

 

2)     WAS에서 성능을 판단하는 기준

WAS 성능을 판단하는 기준은 WAS 목적에 준하면 불특정 다수에게 서비스를 얼마만큼 원활하게 있는가에 대한 것으로 생각해 있다. 그러나 원활하다는 것의 의미에 대해서는 짚고 넘어갈 것이 있다고 생각한다. 원활하다는 것은 많은 수의 사용자를 동시에 포용하는 것일까 아니면 사용자들의 요청에 대한 응답을 빨리 돌려 주는 것을 의미하는 것일까? 문제는 WAS 성능을 요청에 대한 동시 사용량 혹은 처리량을 기준으로 것이냐 아니면 처리 속도를 기준으로 것인지에 대한 것으로 바꾸어 생각해 있다.

일견 비슷해 보일 수도 있고 서로 일맥상통하는 부분이 분명이 있는 지표들이지만 이러한 지표의 선택은 WAS운영의 기본 방향 나아가 WAS 운영의 철학과 깊은 연관이 있다. 그리고 어떤 지표를 기준으로 성능을 가늠할 것인지 그리고 이러한 방향에서 성능을 개선시키는 노력을 지속할 이러한 지표의 선택은 WAS 운영에 있어 다른 양상을 보이게 된다. 그렇기 때문에 성능을 판단하기에 앞서 이를 평가하는 지표의 선정은 향후 성능 관리의 방향을 결정짓는 중요한 단계라고 있다.

그렇다면 어떠한 지표를 선정해야 하는 것일까? 대부분의 경우 성능이라는 관점에 있어서는 처리 속도를 기준으로 보아야 한다. 이유는 서비스 관점에서 WAS 속도는 서비스의 속도이며 이는 결국 비즈니스의 속도와 관련이 있기 때문이다. 처리 속도가 떨어지면 서비스를 이용하는 사용자의 불만이 증대될 것이고 사용자의 불만이 누적되면 이는 사용자의 이탈로 이어져 비즈니스에 악영향을 주는 것은 자명한 사실이다. 또한 앞서 WAS 시스템의 목적 서비스를 제공한다는 부분을 감안하면 처리 속도를 기준으로 성능을 평가하는 것은 지극히 당연하다고 있다.

하지만 지금까지 WAS성능에 있어 처리 속도보다는 동시 사용자 또는 처리량을 기준으로 삼아왔던 것도 사실이다. 그러나 동시 사용자나 처리량은 시스템의 초기 도입 시에 중요한 지표이기는 하지만 이후 운영에 있어 성능을 가늠하는 지표로는 부적절한 부분이 있다. 지표는 사실 성능 보다는 용량 산정을 위한 기준이기 때문이다.

이러한 예를 생각해 보자. 가령 놀이 공원과 같은 시설을 하나 계획을 하고 있는데 얼마만큼의 면적에 어느 정도의 시설을 갖추어야 할지를 예측하고 있는 단계라고 가정해 보자. 사실 공원 부지야 크면 클수록 좋겠지만 투자 비용이 너무 많이 들게 되고 그렇다고 부지를 최소화 한다면 시설물들이 빡빡하게 들어서서 고객들로 하여금 쾌적함을 느끼기 힘들어져 이용객의 소로 연계될 것이므로 적절한 크기의 부지를 확보해야만 한다.

공원 측에서 적절한 크기의 부지를 확보하기 위해 놀이 공원을 이용하는 사람들의 수치를 산정하기 시작했다. 어린이날 같은 특별한 명이 것이고 한파가 몰아치는 시기에는 명이 것인지에 대한 시뮬레이션을 통해 사람들이 불편함을 느끼지 않고 즐겁게 놀고 있을 만큼의 시설물을 판단하여 적정한 부지의 크기와 비용을 산출해 내었다. 이것이 바로 용량 산정인 셈인데 공원의 입장에서 동시 이용객의 수치는 시설물을 확보하는 시점에서 가장 필요한 정보가 된다.

이번에는 이미 개장을 하여 운영에 돌입한 예로 바꾸어 생각해 보도록 하자. 놀이 공원의 매표소에 명의 매표원을 것인가에 대한 것은 이미 앞서 시설물의 용량을 판단하는 방식을 통해 결정을 내렸다. 이제 공원을 개장하여 어느 정도 운영을 하고 있는 시점이었는데 고객들 사이에서 놀이 공원은 쾌적하고 좋은데 매표를 하는데 너무 오래 기다린다는 불만이 쌓여가고 있었다. 역시 매표소에는 사람들의 행렬이 점점 길어지고 있는 실정이었다.

경우 공원 측에서는 동시 사용자가 많으니 무작정 매표소를 확장하고 매표원을 고용하는 방식을 취해야 하는 것일까? 다시 말해 이번에도 용량관점으로 접근이 아직도 유효한지에 대한 판단이 필요한 것이다. 용량을 늘려나가는 문제는 비용이 수반되고 이러한 성능 문제가 비단 리소스의 부족이라고 확신할 수는 없다. 그렇기 때문에 이번에는 이러한 문제를 판단할 있는 지표가 필요하다. 그것은 바로 우선 고객 명당 매표 시간을 측정하는 것이다. 이를 통해 매표 과정에서 불필요한 일을 하고 있는지를 판단하고 만약 불필요한 일을 수행하고 있다면 이를 개선하여 고객당 매표 시간을 줄여 고객들의 불편을 덜어주어야 한다. 만약 불필요한 일이 수행되고 있지 않음에도 사람들이 너무나 몰려들고 있다면 이는 리소스의 부족으로 판단하여 매표소를 늘리고 매표원을 고용하는 방법과 같은 용량을 증대시키는 쪽으로 문제를 해결하여야 것이다.

위의 예는 현실에서 빈번하게 일어나는 일이고 또한 WAS시스템에서도 마찬가지이다. 성능 문제가 발생하고 있을 단순히 처리량 또는 동시 사용자 보다는 처리 시간을 통해 상황을 판단하고 분석하는 것이 더욱 적절하다. 처리시간에 입각한 분석 개선활동은 결국 단위시간당 처리량을 증가시키게 되고 한계시점이 바로 리소스를 추가 해야 시점이기 때문에 기존 처리량, 동시 사용자 기준으로 얻으려는 효과를 수렴하게 되는 부가 이익도 누릴 있게 된다.

 

3)      Transaction인가?

위의매표소의 예에서는 처리 시간으로 고객 매표시간을 사용했다. 이유는 고객 매표시간이 매표에 있어서 쪼갤 없는 업무 처리의 단위이기 때문이었다. 이미 우리는 WAS 시스템에서 쪼갤 없는 업무처리의 단위 Transaction임을 알고 있다. 그렇기 때문에 처리시간이라는 지표를 사용하기 위해서는 Transaction 수행시간을 측정하면 된다.

Transaction 수행시간이 WAS 성능을 가늠하는 중요한 것이라면 우리는 이제 WAS에서 Transaction 무엇이며 어떻게 수행되는지를 알아야 필요성이 생긴 셈이다. 전에 우선 WAS 어떠한 구조로 사용자의 요청을 처리하는지를 알아보도록 하자.

사용자가서비스를 요청하면 요청은 네트워크를 타고 WAS Request Processor에게 전달된다. Listener라고도 불리는 Request Process 요청을 Execution Queue 적재하고 Thread Pool에서 가용한 Thread 할당 받아 Application 접근하게 된다. Thread 할당 받으면 요청은 Execution Queue에서 제거 된다. Execution Queue Thread 할당 받기 위한 대기열인 셈이고 Thread 할당 받는 것은 Execution 수행하는 것의 의미한다.

Thread Pool Thread 모아 놓은 곳으로 이해 있다. Thread 생성하고 제거하는 것이 Resource 많이 사용하는 작업이기 때문에 미리 Thread 생성해 놓고 요청이 있을 사용이 가능한 Thread 할당 받아 사용하게 된다. 그리고 작업이 끝난 후에는 Thread 다시 Thread Pool 반환하는 작업을 하게 된다.

Application에서 DB 같은 Data Source 데이터를 조회, 갱신, 삭제 등의 작업이 필요하게 때는 Connection Pool에서 Connection 객체를 할당 받아 Data Source 접근하게 된다. Connection Pool Thread Pool 마찬가지로 Connection 생성 부하를 줄이기 위해 Connection 미리 생성하여 모아 놓고 필요할 할당 받아 사용하게 된다. 이도 또한 사용이 끝나면 Pool 반환하게끔 되어 있다.

이러한과정을 통해 WAS에서는 사용자의 요청에 대해 응답을 하게 된다. Transaction이라고 하는 것은 이런 요청과 응답을 의미한다. 사용자가 번의 요청을 하고 응답을 받는 것을 통틀어 하나의 Transaction이라고 있다. WAS 이용한다고 하는 것은 결국 이러한 Transaction 발생시키는 것이고 WAS 성능을 관리한다는 것은 Transaction 대해 합당한 시간을 보장한다는 것이다.

결국 WAS에서는 Transaction 시간의 기준으로 하여 단위 시간을 측정함으로써 WAS 성능을 가늠해야 하는 것이 가장 합리적인 방법인 것이다.

 

4)     Transaction 어떻게 분석할 것인가?

     Layer 통한 성능 분석 모델

그렇다면 WAS 성능, 범위를 좁혀서 말하자면 Transaction 성능을 어떻게 파악하여야 할까? 전통적으로 성능 분석을 수행함에 있어서 가장 기본적인 핵심은 바로 불필요한 일을 하지 않게끔 하는 것이다. 그래서 응답시간은 항상 일을 수행하는 주체가 Active하게 일을 하는 시간인 Service Time 대기 시간인 Wait Time으로 구성이 되어 있으며 응답시간을 줄이기 위한 방법은 Wait Time 요소를 찾아 이를 제거하는 것이다. 이런 련의 작업들이 바로 성능을 개선하는 것이라고 있다.

 

 

Elapsed Time  = Service Time + Wait Time

 

Transaction 성능 개선을 하는 방향도 여기서 크게 다르지 않다. 앞서 나누어 놓은 Transaction 수행 영역별 구분에서 각각 Wait, 병목, 지연이 발생할 있는 부분을 찾아 원인을 개선하는 것이 바로 그것이다. 다시 말해 Transaction에서 Service Time Wait Time 각각 측정하여 Wait 분류하고 Wait 해결하는 방법으로 성능을 개선하면 되는 것이다.

그러나여기서 문제는 WAS에서 Service Time Wait Time 각각 측정하는 것이 쉽지 않다는 것이다. Application에는 별도의 로직을 추가하면 어느 정도 가능하다고는 있겠지만 JVM 내부에서 수행되는 이면에서 발생하는 Wait Time Service Time 측정은 JVM 뜯어 고치지 않고서는 거의 불가능하다고 밖에 없을 것이다.

그러나위의 성능 모델에서 Elapsed Time 증가하는 것은 Service Time보다도 Wait Time 기인한다는 관점은 아주 활용도가 높다고 있다. 비록 Wait Time 측정하여 Elapsed Time에서 비율을 정확하게 알아낼 수는 없을 지라도 Elapsed Time 비정상적으로 증가하는 경우는 Wait Time 원인일 것이라고 미루어 짐작할 있기 때문이다. 

이러한관점에서 생각해 Transaction 성능 분석에 있어서 관심을 기울여야 부분은 성능이 좋지 않은 Transaction 수행할 어느 영역에서 가장 많은 시간을 할애하고 있는지를 판단하는 것이라 생각해 있다.

이러한차원에서 일단 Transaction이라는 것을 분해해서 생각을 해볼 필요가 있다. 앞서 WAS 구조를 단순화한 그림에서 Transaction Request Process에서 받아 Execution Queue 통해 Thread Pool에서 Thread 할당 받아 Appplication 수행하게 된다. 이러한 과정에서 Data Source로의 접근이 필요하게 되면 Connection Pool 이용하게 된다. 경우 Transaction에서 시간이 소요되는 부분을 나누어 보면 우선 Request 받아 Thread 할당하는 과정, 그리고 Application 수행하는 과정으로 생각해 있다. Application 수행하는 과정에서는 Application 자체를 수행하는 드는 시간과 더불어 Data Source 사용하기 위해 Connection 얻어오는 부분, 그리고 Data Source에서 사용하는 시간으로 나누어 있다. 이렇게 Transaction 수행하는 과정을 기준으로 생각을 해본다면 아래와 같은 그래프로 나타낼 있다.

그런데 Transaction 수행 과정을 기준으로 생각할 우리가 놓치는 부분이 하나 있다. Java 기반의 WAS 기본적으로 Java Virtual Machine위에서 WAS 자신뿐만 아니라 Application 수행하기 때문에 JVM에서 소요되는 시간도 반드시 존재할 것이다. 바로 시간도 Transaction 수행 시간에 포함 해야 한다.

그래서다시 Transaction 수행 영역별로 시간을 구분해 보면 JVM WAS Thread, 그리고 Data Source 나누어 있다. JVM에서 사용하는 시간을 JVM Work, Thread 할당 받고 Application 수행하는 부분을 WAS Thread Work, 그리고 Data Source 대상으로 하는 부분을 Data Source Work라고 한다면 아래와 같은 수식으로 표현이 가능하다.

 

 

Transaction  = JVM Work + WAS Thread Work + Data Source Work

              = JVM Work
+( Thread Pool + Application + Connection Pool)
+ Data Source Work

 

Transaction 수행 영역별 구분에 다시 병목이 발생할 만한 요소들을 추가하여 Transaction 성능 분석을 위한 Layer 나누어 보기로 하자. Layer 보다 체계적인 분석을 위해 Transaction Request에서 Response까지 진행되는 동안의 수행 과정과 수행 영역을 통틀어 보다 성능 문제 중심적으로 영역을 재분류 하여 하나의 성능 분석의 모델로 재구성한 요소로 생각해 있다.

Transaction 수행 동안 Request Application Layer, Connection Layer,Data Source Layer 거쳐 Response 주게 되고 Application Layer Connection Layer 거치는 동안에는 JVM Issue 존재할 있다는 것이 성능 분석 모델의 요체이다.

Application Layer에는 Application 수행 중에 발생할 있는 Thread Pool관련 이슈, Application 관련 이슈, 그리고 OS 네트웍 등의 리소스의 부족으로 지연이 되는 이슈 등이 성능 문제로 나타날 있다. 그리고 Connection Layer Data Source 접근하거나 사용하는 과정에서 발생할 있는 Connection Pool 관련 이슈, JDBC 관련 이슈 등을 다루게 된다. 사실 Connection관련한 부분은 Application이나 Data Source 양쪽에 모두 발을 걸치고 있고 또한 WAS전체로 부분이 아니기 때문에 따로 떼어내는 것이 적합하지 않다고 생각이 될지 모르나 WAS 운영하는 환경에서 성능 문제를 빈번하게 발생하는 영역이기도 하여 이렇게 하나의 Layer 구분을 놓았다.

Data Source Layer 실제 DB에서 발생하는 성능 문제를 다루게 되는데 사실 WAS 시스템에는 속하지 않는 부분이라고 생각하는 것이 일반적이기는 하다. 그렇지만 WAS 시스템에 물리적 논리적으로 포함되어 있지 않다 하더라도 작업은 Transaction 일부이고 사실상 SQL 수행이라는 것이 경우에 따라 Transaction 시간의 많은 부분을 차지하고 있기 때문에 이는 당연히 분석의 대상에 포함시켜야만 한다고 생각한다. 그래서 모델의 부분을 차지하고 있다[1].



     Layer 성능 문제 분석

이렇게수립된 모델에서 성능분석을 수행할 해야 일은 성능 문제가 있는 Transaction 어느 Layer에서 시간을 많이 소요하고 있는지를 알아내는 것이고 시간을 많이 사용하고 있는 Layer 있다면 어떤 이유로 시간을 많이 사용하고 있는 지를 알아내는 것이다.

만약 Application Layer에서 시간을 많이 사용하고 있다면 이것은 Application 문제라고 보는 것이 무방할 것이다. 경우 문제를 제대로 파악하기 위해서는 문제를 야기하고 있는 Class Method 정확하게 구분하여 알아낼 필요가 있다. 그렇기 때문에 해당 Transaction 수행하고 있을 당시의 Stack Trace 추출해 내거나 Method 수행 횟수나 수행 시간을 알아내는 방법이 필요하다.


   InterMax에서는 이러한 Method 수행이력을 참조 관계를 기반으로 Tree형태로 보여주는 Call Tree화면이 존재한다. 화면에서는 Method 참조 이력뿐만 아니라 Method 수행횟수, 수행 시간, 예외 발생 횟수를 제공하고 있고 또한 수행시간의 분포를 그래프 형태로 제공하고 있기 때문에 수행시간이 Method 빠르게 찾아낼 있다.

  또한
성능 문제를 내포하고 있다고 생각하는 Method 대상으로 분석을 진행하기 위해서는 어쩔 없이 Method Source Level 분석의 깊이를 더해야 한다. 보통 WAS에는 class파일로 컴파일 형식으로 deploy 되기 때문에 Source 개발자를 통해 수집을 하거나 Class 찾아서 역어셈블링 하는 과정을 거쳐서 분석을 수행할 있다.

  InterMax
에서는 현재 WAS에서 수행되고 있는 Class파일을 그대로 찾아와 Java Source Code 형태로 보여주기 때문에 Source Level 분석에 보다 쉽게 접근할 있게 된다.


또한 Connection Layer에서 성능 문제가 발생하고 있는 경우는 이것은 Connection Pool 등의 자원 배분에 문제가 있는지 아니면 Connection 자체의 문제가 있는지 아니면 WAS에서 어떤 문제가 야기되고 있는지를 판단해야 한다.

Connection Pool 자원 배분의 문제가 있다는 것은 Connection Pool별로 Connection 최대 개까지 맺을 있는지, 현재 Connection 맺어져 있는지, 그리고 현재 개의 Connection 사용하고 있는지를 모니터링 하고, 추이를 살펴보아 적정한 수의 Connection Pool 운용하고 있는지를 판단해야 한다. InterMax에서는 이에 대해 개별 Connection Pool 대한 모니터링이 가능하도록 화면을 제공하고 있다.


또한 Connection Pool 병목으로 인해 WAS전체의 성능 문제가 야기되고 있다면 이것이 Data Source에서 문제가 발생하고 있는지를 판단해 보아야 한다. 이는 Data Source DB Connection 맺을 없는 정도의 장애 상태인지를 관찰하여 만약 Data Source 문제라고 판단이 되면 DBA 통해 문제가 조속히 해결되도록 해야 한다. InterMax 메인 화면에서 간단하게나마 Data Source 대한 모니터링이 가능하도록 하여 Data Source 문제로 말미암아 Connection Pool 문제 상황이 전이 되었는지를 판단할 있게 하고 있다.

WAS 특정 Transaction Connection 점유하고 오랜 시간 지속함으로써 Connection Pool 있는 Connection 고갈되는 경우에는 Long Transaction SQL 수행하고 있음을 확인함으로써 상황을 감지할 있게 된다. 이를 위해 현재 오랜 시간을 지속하고 있는 Transaction 어떠한 일을 하고 있는 지를 알아야 하는데 이도 역시 Stack trace 통해 Transaction 수행하고 있는 Thread SQL Execute 같은 작업을 수행하고 있는지를 보고 판단해 있다.

InterMax에서는 Active Transaction List 통해 현재 수행 중인 Transaction 어떠한 상태에 있으며 전체 수행시간 Data Source에서 사용하고 있는 시간 현재 사용하고 있는 Connection 어느 Pool인지를 한번에 알려준다. 그래서 Connection Pool 문제가 Application에서 잘못된 SQL 수행하여 오랜 시간 점유하고 있는지의 여부를 쉽게 판단할 있게 준다.

그리고 Application에서 Connection 사용할 Pool에서 가져온 Connection 사용이 끝난 후에 반환하지 않아 Connection 활용도가 떨어지게 하는 Connection Leak현상도 InterMax 통해 알아 있다.

Data Source에서 성능 문제가 발생하고 있는 경우는 보통 SQL 수행하는 과정에서 나타난다. 이러한 성능 이슈는 지금까지는 DBA 소관으로 치부하고 넘어가는 경우가 많았지만 Data Source WAS Application 내장된 SQL 통해 실행되기 때문에, 그리고 무엇보다도 Transaction내에 일부로 포함되어 수행시간에 영향을 주기 때문에 WAS 분석에서 중요한 자리를 차지한다.

그러나 Data Source 성능 문제는 사실 여기서 간단하게 얘기할 성질의 것은 아니다. 왜냐하면 부분은 이미 OWI SQL Tuning 등의 영역으로 크게 확장되어 있는 상태이고 SQL 야기한 문제를 분석하고 해결하는데 있어 이러한 영역에서 벗어나는 부분은 없다고 해도 무방하기 때문이다.

Data Source Layer에서 SQL 문제임을 판단하는 것은 Connection Pool Application문제를 분석하는 방식과 동일하다. 일단 수행중인 Long Transaction 경우 Stack Trace 통해 SQL 수행 중인지를 확인하는 방법 등이 있다.

InterMax에서도 마찬가지로 Active Transaction List에서 Long Transaction SQL Execute상태로 지속이 된다면 문제에 해당한다고 있다. InterMax 경우 실시간으로 Transaction SQL 수행 중이라면 해당 SQL 수행하면서 어떠한 Wait Event 겪고 있는지를 보여주기 때문에 SQL 넓은 범위의 IO때문에 지연되고 있는지 아니면 경합에 따른 대기인지를 판단할 있게 된다.

또한 이미 수행된 Transaction에서 SQL 어느 정도의 분포를 가지고 있는지도 판단의 근거가 있다. 이미 수행된 Transaction Long Transaction인데 SQL 수행시간의 비율이 상당히 크다고 하면 Transaction 당연히 Data Source Layer 지연의 요인이 있는 것이므로 부분을 해결하는데 노력을 기울여야 한다는 것이다.

Data Source Layer 문제가 있다고 밝혀 지면 문제의 원인이 무엇인지를 밝혀 내야 한다. Oracle 경우 Wait Event 대한 Interface 기본적으로 제공하고 있고 이를 활용한 OWI라는 방법론이 나와있는 상태이기 때문에 이를 이용하는 것이 좋다. Transaction 수행 중일 나타나는 Wait Event 종류를 보고 이것이 Oracle Session간의 경합에 따른 것인지 아니면 SQL 자체의 결함인지를 판단한다. [2] 만약 SQL 대한 Tuning이슈가 있다고 생각이 든다면 연계되는 LitePlus 이용하여 튜닝을 있다.

밖에도 JVM Issue 있을 . JVM Issue 발생할 경우는 영향이 개별Transaction 범위를 넘어서는 경우 있다. 이러한 문제는 Heap Memory관련 이슈라든가 과다한 Garbage Collection 수행, 리소스 부족 등으로 생각해 있는데 이러한 성능 문제가 발생하여 전반적인 WAS 성능을 저하시킬 때는 이러한 문제가 Application에서 야기된 것인지를 우선적으로 분석을 시도해 보아야 한다.

만약 Application에서 이러한 문제의 원인을 제공하고 있다면 Application 수정을 통해 이러한 문제를 해결할 있으나 간혹 JVM 자체의 버그로 인해 성능문제가 야기될 수도 있기 때문에 이점을 염두에 두어야 한다.

 



[1] 현재 대부분의 사이트에서 Data Source로 사용하고 있는 것이바로 Oracle Database Server이기 때문에 성능 사례도Oracle에 맞추어져 있다.

[2] Oracle Session 간의 경합은 Lock, Latch에 관련된 event로 표현이 되고, 그 밖의 경우인 넓은 범위의 IO나 비효율적인 Index, 불필요한 수행 등의 원인으로 발생하는여러 가지 event는 각각의 경우에 따라 해결책이 다양하다. 이에대한 정보는 엑셈 Wiki 백과사전(http://wiki.ex-em.com)을 참조하여 찾아보는 것을 권장한다. 

'기술이야기' 카테고리의 다른 글

성능에서의 풍선효과  (0) 2009.04.14
Transaction 중심의 성능 분석법  (0) 2009.04.01
SSD와 Performance...  (0) 2009.04.01
Sun JVM의 HEAP의 구조와 Garbage Collection  (4) 2008.08.04
댓글
댓글쓰기 폼