동시접속 성능튜닝을 위한 테스트 TNS-12535: TNS:operation timed out [펌]

[출처] http://blog.naver.com/k65fac?Redirect=Log&logNo=40031513314

오라클 동시접속 성능 테스트를 진행한 내용입니다.

 

정확한 임계치를 표현 할 수가 없어서 답답하기만 했던 내역을 대략적으로만

 

기록해 두는것이니 참조용으로만 보시길 바랍니다.

 

서버 및 APP 구성
application server 3대 + DB Server 1대. application demon은 각 트랜젝션마다 Fock 방식으로

 

각각 DB Connection을 맺고 처리후 종료하는 형태로 개발되어 있어서 평소에는 원할하게

 

처리가 되지만 매월 1일 트랜젝션이 급격하게 증가함에 따라 DB Conntion을 하는데

 

20~ 60초 이상 걸리는 경우가 발생하여 app daemon에서 TimeOut을 발생시켜 강제로

 

처리를 중지하는 문제가 생긴다.

리스너 로그를 통해 확인한 트랜젝션은 평일 초당 10 ~ 15개의 Connection Transaction이 발생.

 

APP 서버의 로그를 통해 확인한 결과 매월 1일 00시~ 01시사이 각 서버마다 초당 70~100의 동시

 

Transaction이 발생함에 따라 application 서버의 데몬에서 처리를 못하는 문제가 발생하여

 

관련 해결책을 찾고 있는 상황임.

 

앞서 말한바 정확한 임계치를 찾지 못해 유사한 테스트를 만들어 진행했으나 만족할 만한

 

수준(10초이내 처리완료)의 결과는 얻지 못하고 있다.

 

 

1.문제원인 파악

 - App Daemon의 Fock 방식의 각 트랜젝션 마다 DB 접속에 대한 처리

 - 단일 리스너의 임계치를 초과하는 동시 접속 요청발생
   -> 단일 리스너 처리 임계치 : 초당 17~20개

 - DBMS의 Ora-**** 메시지 발생안함(APP 데몬에서 20초 이상 지연시 강제종료)

 - Client 에러 메시지
 
   VERSION INFORMATION:
 TNS for Solaris: Version 8.1.6.0.0 - Production
 TCP/IP NT Protocol Adapter for Solaris: Version 8.1.6.0.0 - Production
  Time: 01-NOV-2006 00:07:07
  Tracing not turned on.
  Tns error struct:
    nr err code: 0
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505
    TNS-00505: Operation timed out
    nt secondary err code: 145
    nt OS err code: 0
  
   => nt secondary err code:시스템 에러 메시지이지만 connection 관련 특별한 내용없음.
   /usr/include/sys/errno.h
   #define ETIMEDOUT       145     /* Connection timed out */
   #define ECONNREFUSED    146     /* Connection refused */

   => 리스너는 정상적으로 떠 있으나 app 데몬에서는 인식 못함.

- APP 데몬에서는 접속이 불가능하나 해당 시간 sqlplus에서 접속은 이상없음.

 

2.실 상황과 유사한 상황 재연

 - 동시접속 Process 350
   -> 미리 350개의 프로세스를 띄운뒤 signal에 의해 동시 접속진행

 - listener.ora 및 tnsnames.ora 파일 재설정

 

 

3.오라클 Client , Server 설정변경

 -오라클에서 동시 트랜젝션의 성능을 향샹시키는 방법으로 listener quesize라는
  파라메터가 있는데 이를 정적 수준으로 증가한다. default = 17

 -테스트 데몬에서 명시적으로 2개의 리스너에 분산시켜 접속하도록 테스트를
  진행해봤으나 load balancing 세팅을 하는것과 차이가 없고, APP 데몬을 수정
  하는데 장시간이 소요. load balancing 처리를 적용하는것이 실서버 환경에
  적합하다고 판단됨.

----------------------------------------------------------------------------------
- tnsnames.ora
 TEST1 =
   (DESCRIPTION =
     (ADDRESS_LIST =
     (LOAD_BALANCE = ON)
     (FAILOVER = ON)
       (ADDRESS = (PROTOCOL = TCP)(HOST = TEST)(PORT = 1521)(QUEUESIZE = 32))
       (ADDRESS = (PROTOCOL = TCP)(HOST = TEST)(PORT = 1522)(QUEUESIZE = 32))
     )
     (CONNECT_DATA =
       (SERVICE_NAME = MCASH)
     )
   )

- listener.ora

 TEST1 =
   (DESCRIPTION_LIST =
     (DESCRIPTION =
       (ADDRESS_LIST =
         (ADDRESS = (PROTOCOL = TCP)(HOST = TEST)(PORT = 1521)(QUEUESIZE = 32))
       )
     )
     )
   )
 
 SID_LIST_mercury_TEST1 =
   (SID_LIST =
     (SID_DESC =
       (GLOBAL_DBNAME = TEST)
       (ORACLE_HOME = /data1/oracle/app/oracle/product/8.1.7)
       (SID_NAME = TEST)
     )
   )

 TEST2 =
   (DESCRIPTION_LIST =
     (DESCRIPTION =
       (ADDRESS_LIST =
         (ADDRESS = (PROTOCOL = TCP)(HOST = TEST)(PORT = 1522)(QUEUESIZE = 32))
       )
     )
     )
   )
 
 SID_LIST_mercury_TEST2 =
   (SID_LIST =
     (SID_DESC =
       (GLOBAL_DBNAME = TEST)
       (ORACLE_HOME = /data1/oracle/app/oracle/product/8.1.7)
       (SID_NAME = TEST)
     )
   )
 
4.테스트 결과

 

DBMS 동시접속 테스트결과
NO	서버 (리스너개수)	클라이언트	큐사이즈	로드발랜싱	프로세스 개수	시간(초)	설명
1	1	1	17(default)	N	350	300이상	3분이후 접속안된 Process는 Time out 발생
2	1	1	32	N	350	35
3	1	1	64	N	350	30
4	1	1	128	N	350	28
5	2	1	17(default)	Y	350	257
6	2	1	32	Y	350	22
7	2	1	64	Y	350	21
8	2	1	128	Y	350	23
9	2	2	32	N	350	22	프로그램소스내부에서 2개의 tns명을 명시적으로 분리해 접속 시간 측정함
10	4	1	17(default)	Y	350	115
11	4	1	32	Y	350	21
12	4	1	64	Y	350	21
13	4	1	128	Y	350	21

 

 

위 동시접속 테스트 결과는 APP의 로그를 기록한 것으로 접속 시그널을 받고 나서

 

350개의 프로세스들이 접속종료을 할때까지 걸린 시간을 나태낸것이다.

 

개별 PID별 접속시그널접수 -> 접속ok ->종료 되는 타임을 기록하는것이 보다 명확하나

 

이는 추후 기회가 생길때 업데이트 하도록 함.

 

위 표를 보면 한가지 결론을 내릴수 있다. queue size 세팅으로 인해 default 보다는 월등한 성능

 

을 나타내고 있으나 queue size가 증가 한다고 해서 성능이 비례해서 증가하지 않는다는 것이

 

단번에 나타난다. 따라서 반복되는 테스트를 통해 개별 시스템 환경에 맞는 수준으로 세팅하는

 

것이 옳은 것이라 생각된다.

 

참고로 오라클에서의 세팅이외 시스템에서의 네트웍 관련 시스템 파라메터를 증가시켜 줄 필요가

 

있다. 즉.. 문제의 원인이 순순하게 DB에서의 문제인지, 시스템 단에서 폭주하는 트래픽을 감당

 

못하는것인지 분명치 않기 때문에 시스템설정과 병행해서 진행할시 더 큰 성능향상을 볼수 있다

 

고 돼어 있으나, 

 

임계치 이런내용은 전혀없다~  젠장..

 

아래는 Sun Solaris에서 사용되는 시스템 파라메터의 값을 조정하는 내용이다.

-----------------------------------------------------------------------------

tcp_conn_req_max_q,tcp_conn_req_max_q에 대한 파라미터값은

tcp_conn_req_max_q default값으로 128  (최소 1 ~ 최대 4,294,967,296)

tcp_conn_req_max_q default값으로 1024 입니다. ( (최소 0 ~ 4,294,967,296)

이 부분에 대해서 Sun에서는 권장하는 값은 현재 디폴트 값이고 시스템 Service에 맞게

connection이 많다면 수치를 증가 시키는 방법입니다. 정확한 수치 값은 없습니다.

 

 

==============  Unix System parameter 확인 =====================

아래는 오라클 세미나 2003년 5월 22일

Oracle Developer Conference에서 찾은 내용입니다.

Unix Performance 섹션에 보시면 아래와 동일한 내용을 확인하실수 있습니다.

 

 

tcp_conn_req_max_q[
  /usr/sbin/ndd –set /dev/tcp/ tcp_conn_req_max_q 1024
  /usr/sbin/ndd –set /dev/tcp/ tcp_conn_req_max_q0 1024
  tcp_conn_req_max_q0 governs the max length of the queue for
incomplete handshakes

– Default is 1024
  tcp_conn_req_max_q governs the max length of the queue for
requests with completed handshakes

– Default is 128
  If you have several hundred concurrent users, connections can be
dropped in the handshake state because the queues are full
  Can determine if that is the case with `netstat –s` by inspecting the
values for tcpListenDrop, tcpListenDropQ0 and tcpHalfOpenDrop

– If either of the first two values are nonzero, increase the maximums