Table of Contents

Solving Oracle OID Connection Limits: Breaking Through the 1024 Barrier

Oracle OID 연결 한계(1024) 극복 가이드 — 5,000 동시 접속까지 단계 확장

    Summary: “Exceeding maximum number of connections … Num Conns = 1024, Max Conns = 1024” 오류의 원인과, PID별 모니터링/튜닝을 통해 ~5,000 동시 접속까지 확장하는 실무 가이드.
  

Oracle OID 연결 한계

현장에서 다음과 같은 OID 연결 한계 오류가 보고되었습니다.

Error: “Exceeding maximum number of connections … Num Conns = 1024, Max Conns = 1024”
External Count: 855–893 수준으로 관측
Puzzle: 왜 1024에 도달하기 이전에 막혔는가?

    수신 정보 요약
    프로세스 수: ps … | wc -l = 2 → 컨트롤 1 + 서버 1 ⇒ 런타임 orclserverprocs=1 정황
FD 한도/사용: nofile 65536/65536, 현재 FD = 277 → OS FD 병목 아님
pgrep -a 미지원: 전체 커맨드라인은 pgrep -fl oidldapd로 확인
ldapsearch(3060) 실패: 3060 비SSL 접속 불가 → LDAPS(3131) 또는 StartTLS 강제/정책 차단 가능
OID UI(엑셀) 설정:
        
— Max per proc = 1024
        
— orclserverprocs = 1, Idle(min) = 60
        
— Dispatcher/proc = 5, DB Conn/proc = 4
      

  

현행 시스템 구성 - orclserverprocs = 1

    Key OID Settings:

    • orclserverprocs = 1 (Number of server processes)

    • Max LDAP Connections per Server Process = 1024

    • Total Connection Capacity = 1 × 1024 = 1024

연결 한계 극복 과정 과정에서 받은 질문

Q1: 왜 1024 이전에 오류가 발생했나요?

답변: OID는 전역이 아니라 프로세스당 상한(1024)을 적용합니다. orclserverprocs=1이면 단일 서버 프로세스가 먼저 1024에 도달합니다.

외부 집계가 낮게 보이는 흔한 이유:

LDAPS(3131) 미포함
CLOSE_WAIT, TIME_WAIT 등 상태 누락
IPv6 미포함

Q2: 최대 5,000으로 설정하고 실제 사용된 연결 수를 확인하는 방법?

답변: 총 용량은 orclserverprocs × orclmaxldapconns입니다. per-process 상한을 1024로 유지한 상태에서 orclserverprocs를 단계적으로 늘리고, 부하 중 PID별 합계와 TOTAL 피크를 기록해 실제 최대 동시 사용량을 확인합니다.

Step 1: 엔드포인트 확인

Bash • Port listening check

# 3060(Non-SSL), 3131(LDAPS) 리스닝 확인
$ ss -lntp | grep -E "\b:(3060|3131)\b"

UI에서도 확인하기

ODSM → Connections: Host/Port 및 SSL/StartTLS 여부
EM(Fusion Middleware Control) → Server Properties: Non-SSL/SSL Port 값

Bash • OID 데몬 커맨드라인 확인

$ pgrep -fl oidldapd

Step 2: 실시간 모니터링 (PID별 합계 + TOTAL)

Bash • Per-PID totals & TOTAL

$ sudo ss -tanp '( sport = :3060 or sport = :3131 )' 2>/dev/null \
| awk '/ESTAB|SYN-RECV|CLOSE-WAIT|TIME-WAIT/ && match($0,/pid=([0-9]+)/,m){c[m[1]]++} \
       END{tot=0; for(p in c){printf "PID %s %d\n",p,c[p]; tot+=c[p]} printf "TOTAL %d\n",tot}'

Step 3: ~5,000 달성

보수적: orclserverprocs를 5로(5×1024=5120)
검증: 위 모니터링을 1–5초 간격으로 수분간 실행 → TOTAL 피크 기록

연결 문제 극복 모범 사례

    부하 테스트 중: 모니터링 원라이너를 주기적으로 실행
피크 기록: TOTAL 최대값을 기록
점진 확장: 프로세스 2 → 3 → 5
리소스 관찰: CPU/메모리/DB 세션/FD 함께 모니터링

  

Important Considerations

프로세스 수 증가 = 메모리/CPU/DB 세션 총량 증가
DB 커넥션 풀 및 WLS JDBC 풀 설정 동시 점검
변경 후 반드시 성능 검증
피크 시간대 자원/슬롯 관찰

5,000 동시접속 단계 확장 플랜

Phase 1 — 우선 적용

    orclserverprocs: 1 → 2 (여유 시 3) — 단일 프로세스 1024 조기 포화 방지
Idle Connection Timeout(min): 60 → 15–30 — 유휴 슬롯 회수 가속
Dispatcher Threads/proc: 5 → 8–10 — 버스트 흡수, 수락 지연 감소
Max LDAP Conn/proc: 1024 유지 — 상향은 최종 단계에서만 검토

  

Phase 2 — 1단계로도 포화 시

    DB Connections/proc: 4 → 8(또는 12) — OID→DB 병렬성↑, 처리시간↓
orclserverprocs 추가 상향: 물리 코어 수에 근접하도록
코어 수 확인: cat /proc/cpuinfo | grep "core id" | sort | uniq | wc -l

  

Phase 3 — 필요 시 ~5,000 근접

    설계 목표: per-proc 1024 유지, orclserverprocs = 5 → 총량 5120
사전 점검: DB processes/sessions, WLS JDBC 풀(Max/Initial/Statement Cache/Test-on-Reserve), 시스템 메모리/CPU/FD 여유

Troubleshooting Tips

낮게 집계될 때 확인:

3060(Non-SSL)과 3131(LDAPS) 모두 집계
IPv4/IPv6 바인딩 및 정책 확인
ESTAB 외 SYN-RECV, CLOSE_WAIT, TIME_WAIT 포함
PID 기준 내부 카운트와 외부 합계 교차 검증