SQL*Net more data from client - 성능테스트에서 만나다

Updated:

SQL*Net more data from client 대기 이벤트

성능테스트는 언제나 흥미있다. AP 를 통해 부하를 쏘고 DB 에서는 모니터링을 한다. 부하가 증가한다. 증가하다가 어느 한계지점에 이르면 더이상 오르지 못하고, APM 에서는 응답시간이 늦어지는 그래프가 지저분하게 나타나기 시작한다. DB가 병목일수도 또는 AP가 병목일 수도 있다. 일반적으로는 그렇다. 하지만 가끔은 네트웍이 병목일 때도 있다.

SQL*Net more data from client 이벤트는 이를 나타내 준다. SQL 수행에 필요한 정보들(SQL 문장 자체 또는 수행에 필요한 데이터 등)이 아직 client 로부터 도착하지 않아서 DB 가 기다리고 있는 상황을 나타낸다. 우리나라처럼 좋은 네트웍 환경에서는 잘 경험하기 어려운 이벤트인데 네트웍 속도가 느린 환경에서는 종종 경험하는 것 같고, 따라서 그 처방도 네트웍 튜닝에 주로 맞추어지게 된다.

이번 OOO 차세대 프로젝트 성능테스트에서 이 현상을 만났다. 부하를 증가시키다가 한계지점에 이르자 활성 트랜잭션 갯수는 2~3 정도에서 20 정도로 증가해서 유지되었다. 성능지표 bytes received via SQL*Net from client [mb/s] 는 10 mb 에서 더 이상 증가하지 못하고 있었다. 이때 wait event 는 거의 SQL*Net more data from client 들 뿐이었다.

정리해 보면, client 에서 DB 로 보내는 네트웍 속도는 최대 10 megabytes/sec 정도인데 부하를 더 높이니까 AP 에서는 대기 call 들이 쌓이기 시작했고, call 들이 늘어나니까 call 들의 네트웍 대기시간이 증가했고 이 때문에 DB 에서는 SQL*Net more data from client 이벤트가 발생되면서 활성 트랜잭션 수가 증가한 것이다.

병목이 네트웍인 것으로 나타났으니 이제 원인만 찾으면 되었다. 여러가지 테스트를 거쳐서 결국 원인을 찾았는데, 놀라지 마시라. 원인은 바로 네트웍 케이블 때문이었던 것이다. 아.. 케이블이 찍혀서 꼬여 있었다나!
하여튼 WAS 와 스위치간 케이블을 교체한 후 현상은 없어지고 TPS 는 바로 두배로 뛰었다!

병목 상황에서 DB 에서 다른 대기 이벤트가 없고 오직 SQL*Net more data from client 이벤트가 압도적이라면 AP 와 DB 사이의 네트웍 병목을 의심해 보길 바란다.

이번 성능테스트도 재미있는 추억을 남기고 잘 끝나서 감사하다.