Table of Contents

Oracle OID Connection Limits: Per-Process Caps and Scaling Requirements

    Summary: Compare the 1024 limit message with external counts and assess per-process caps and scaling requirements. 5,000 connections is a test objective, not demonstrated capacity. The original command examples have unverified syntax and counting scope; do not run them as written.
  

The Problem

The original article reports the following error and observations. The installed version, timestamps and original logs are unavailable; this is not a verified incident record.

Error: "Exceeding maximum number of connections … Num Conns = 1024, Max Conns = 1024"
External Count: 855–893 connections reported in the original article; matching collection time and scope are unverified
The Puzzle: Do the internal 1024 value and external count cover the same measurement scope?

    Original observations and required checks
    Process count: ps … | wc -l = 2 alone does not identify process roles or prove the running orclserverprocs=1 value. Confirm the instance, PID and role separately
FD limits/usage: nofile 65536/65536, current FD = 277 is a snapshot. Without the failing PID’s limits and usage at the error time, it cannot exclude an FD bottleneck
pgrep -a availability depends on the tool version. Interpret pgrep -fl oidldapd output only after identifying the running instance and process roles
ldapsearch(3060) failure alone does not establish TLS enforcement or policy blocking. Separate listener, network path, TLS mode and error evidence. Ports 3060/3131 are examples
Settings recorded in the original article (not verified current values):
        
— Max per process = 1024
        
— orclserverprocs = 1, Idle timeout = 60 min
        
— Dispatcher threads/process = 5, DB connections/process = 4
      

  

Example Configuration: orclserverprocs = 1

    Key OID Settings:

    • orclserverprocs = 1 (Number of server processes)

    • Max LDAP Connections per Server Process = 1024

    • Illustrative sum of configured caps = 1 × 1024 = 1024; not users, throughput or demonstrated capacity

Questions for Connection-Limit Diagnosis

Q1: Why can internal and external connection counts differ?

Answer: orclmaxldapconns limits concurrent connections per server process. 1024 is the documented default and this example’s setting, not an immutable limit. Even with orclserverprocs=1 and the error PID confirmed, match timestamps, ports and states before inferring the cause.

Scope differences to check:

Actual SSL/non-SSL ports, timestamps and collection permissions
Different CLOSE_WAIT/TIME_WAIT populations. TIME_WAIT is not an active LDAP connection and may have no PID
IPv6 connections not counted

Q2: What is required to validate a 5,000-connection objective?

Answer: orclserverprocs × orclmaxldapconns illustrates the sum of configured caps for one instance. Distribution, per-process headroom, DB and OS resources can reduce actual capacity. Use version-specific change/restart planning and representative load testing. Until independently validated, the PID example below is not an OID internal counter or a capacity acceptance test.

Step 1: Verify Endpoints

Bash • Port listening check

# Check 3060(Non-SSL), 3131(LDAPS) listening
$ ss -lntp | grep -E "\b:(3060|3131)\b"

Also verify through UI

ODSM → Connections: Check Host/Port and SSL/StartTLS settings
EM (Fusion Middleware Control) → Server Properties: Verify Non-SSL/SSL Port values

Bash • OID daemon command line

$ pgrep -fl oidldapd

Step 2: PID-based Socket Example — Counting Requires Validation

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: Conditional Validation of the 5,000-Connection Objective

Arithmetic example: orclserverprocs of 5 gives 5×1024=5120. This is neither a conservative recommendation nor a measured result
Verification: Validate syntax, state and PID scope first; evaluate representative load, latency, errors, resources and internal counters together. A brief TOTAL peak alone cannot prove sustainable capacity

What to Record During Load Validation

    During load testing: Record synchronized observations using validated tools
Record peaks: Record the definition of TOTAL, states, missing PIDs, latency and errors
Gradual scaling: 2 → 3 → 5 is a trial sequence; define resource, performance and rollback criteria at each step
Resource monitoring: Watch CPU/memory/DB sessions/FD usage alongside connections

  

Important Considerations

More processes require additional memory and DB connection budgeting. CPU usage and throughput depend on workload and contention
Check OID’s per-process DB connections and DB session budget first. Review WLS JDBC pools separately only for applications actually in the request path
Check installed-version restart requirements and prepare a change window, rollback and performance validation
Monitor resource/slot usage during peak hours

Staged Trials for a 5,000-Connection Objective

Phase 1 — Baseline Measurement and Individual-Variable Trials

    orclserverprocs: 1 → 2 (3 if needed) is a trial example. Measure per-process distribution and resource headroom, and check restart requirements
Idle Connection Timeout (min): 60 → 15–30 is an original trial example, not a recommended value. Check client pool reconnection and idle-retention requirements; users configured for statistics tracking may be exempt
Dispatcher Threads/process: 5 → 8–10 is a trial example requiring version, wait and CPU-contention checks. It does not guarantee lower latency
Max LDAP Connections/process: 1024 is the original example setting. Decide changes from actual caps, OS FD budgets and per-process distribution

  

Phase 2 — If Phase 1 Still Saturates

    DB Connections/process: 4 → 8 (or 12) is an original trial example. Check DB sessions, waits and contention; a larger pool does not guarantee shorter processing time
Further increase orclserverprocs: Use the documented core-count guidance as a starting point, then validate version, workload and resources. The core-id uniqueness command below can undercount multi-socket or virtual systems
Check core count: cat /proc/cpuinfo | grep "core id" | sort | uniq | wc -l

  

Phase 3 — Approaching ~5,000 if needed

    Target design: 1024 per process with orclserverprocs = 5 sums to 5120. Do not claim support for 5,000 connections before distribution and representative-load validation
Pre-checks required: OID DB connections and DB processes/sessions budgets, memory/CPU/FD headroom, version-specific restart and rollback plans. Review WLS JDBC pools separately only if in the actual path

Troubleshooting Tips

When connections appear lower than expected:

Match actual SSL/non-SSL listeners rather than assuming ports 3060/3131
Verify IPv4/IPv6 bindings and policies
Interpret ESTAB, SYN-RECV, CLOSE_WAIT, TIME_WAIT separately. A mixed-state total is not an active LDAP connection count
Compare the actual OID server PIDs, internal counters and external sockets at matching times. The example can omit rows without pid attribution