[김종민]다시 한번 돌아보자, 뮤텍스

얼마 전 모 고객사에 DB 장애로 인한 MAXGAUGE LOG 분석 의뢰가 들어왔다.

 

업무가 많아 달갑지는 않았지만 급한 상황이라 먼저 일을 처리 해야겠다는 생각으로 로그를 받아 로그에 남아있는 현상을 살펴 보기 시작하였다. 비교적 문제 시점은 빨리 확인을 할 수가 있었다.

 

장애 시점으로 보이는 구간에 CURSOR PIN S WAIT ON X 대기 이벤트가 대량 발생하고 있었고, 담당자의 말에 의하면 이 시점에 DB에 HANG이 걸린 것 같은 현상이 있었다는 것이었다.

 

단순히 파라미터 수정을 통해 문제는 해결이 된다는 것으로 답변을 하였지만, 담당자가 원하는 답변은 그런 것이 아니었고 CURSOR PIN S WAIT ON X 대기에 대한 구체적인 내용을 원하는 것이었다. 하지만 아직 이 문제에 대해 나름대로 정리를 해본 적이 없었고 설명을 대략적으로 하려 하였으나 결국 제대로 이해시키지 못하였다.

 

업무가 많아 일을 빨리 처리 하려다 제대로 된 지원을 하지 못하게 되었던 것이었다. 그래서 다른 업무를 미루고 관련 정보를 찾을 수 밖에 없었다.

내가 알게 된 정보는 아래와 같다.

 

해당 대기 이벤트는 ORACLE에서 LOCK 메커니즘 중 MUTEX라는 기능을 10R2부터 디폴트로 사용함으로써 발생되는 문제이며, 현재 내가 지원하는 고객사 중 ORACLE 10.2.0.3을 운영하는 곳에서 종종 발견되는 이벤트였다. (물론 장애를 포함하여서..)

 

근본적인 해결 책을 아닌 것 같지만 현재 해당 문제는 _kks_use_mutex_pin 라는 ORACLE 히든 파라미터의 수정을 통해 이벤트를 해소 할 수 있는 것으로 알려져 있다.

뮤텍스란 무엇인지 살펴보면,  

뮤텍스(MUTual EXclusion)(상호배제)
Critical Section을 가진 Thread들의 running time이 서로 겹치지 않게, 각각 단독으로 실행되게 하는 기술이다.
* Critical Section : 프로그램 상에서 동시에 실행될 경우 문제를 일으킬 수 있는 부분.
만약 어느 Thread에서 Critical Section을 실행하고 있으면 다른 Thread들은 그 Critical Section에 접근할 수 없고 앞의 Thread 가 Critical Section을 벗어나기를 기다려야 한다. 

뮤텍스의 특징

 

-       다수의 프로세스가 동일한 리소스를 공유할 수 있게 해줌

-       시스템으로부터 프로그램이 요청한 리소스를 위한 mutex을 하나 생성하고

-       시스템이 고유id를 부여한다. ( no wait mode 의 latch와 비슷함)

-       latch와 달리 mutex은 시스템이 관장

-       latch의 spin을 수행하지 않기 때문에 가벼울 수 있다.

-       문제발생시 oracle해결범위를 넘어선다.

-       mutex의 경우 복구가 안 된다.

 

아마도 뮤텍스라는 기능을 이용함으로 인해 mutex pin을 사용하는 과정에서 아래와 같은 현상이 발생하였고 mutex pin을 exclusive로 획득 중인 세션이 비정상적인 이유로 인해 계속해서 pin을 획득하게 되어 mutex pin을 획득하기 위해 다른 세션의 대기가 지속 되는 것으로 예측이 되었다.

 

오라클 버그에도 등록이 되어 있는 내용을 보면 특정 hp장비에 (CAS기능을 지원하지 않는 장비) 드물게 이러한 문제가 있으며, 아직 해당 문제는 해결이 되지 않았으며 근본적으로 11g에서 해결이 된다고 한다.

 

시간을 투자하여 나름대로 관련 정보를 검색한 후 정리를 하고 나니 비로소 담당자가 이해를 잘 하였다. 그리고 고객사 담당자의 DB HANG이라는 말은 확인을 해본 결과 개발자의 얘기였으며, 엄밀히 말하면 HANG의 상태는 아니었고 CURSOR PIN S WAIT ON X 대기 이벤트를 대기하는 세션의 작업이 수행이 되지 않아 그렇게 얘기 한 듯 하였다. 담당자에게 TOTAL SESSION의 증가 구간을 확인 할 것을 권고 하였고 실제로 맥스게이지 로그를 통해 확인해 보니 문제 발생 이 후 세션의 증가 구간이 있었다.

 

결국 이와 같은 문제는 _kks_use_mutex_pin = false 로 설정하면서 mutex 기능을 사용 해제 하면 해결이 되나 히든 파라미터인 관계로 oracle에 확인 후 설정을 하시는 것이 좋다는 권고만 할 수 있었다.

 

지원은 시간이 많이 걸리긴 했지만 답변을 줄 수 있었고 이러한 경험을 통해 명확히 문제에 대한 지식이 없을 경우, 지원의 시간이 많이 걸릴 뿐 아니라 담당자가 이해하기까지도 어려움이 많음을 느꼈다.

 

오늘의 교훈은 급한 길일수록 여유를 갖고 주어진 상황을 처리하는 것이 결과적으로 고객사에게 더욱 믿음을 줄 수 있는 방법임을 알게 되었다.