이전 포스팅인 Part 1에서는 OID의 기본 개념과 처리 경로를 살펴봤습니다. 이번 글은 메모리·연결 관리와 서버 배치의 검토 기준을 정리합니다. 아래 설정은 그대로 실행할 권장 명령이 아니므로, 지원 버전·변경 조건·복구 계획을 확인하고 시험 환경에서 비교한 뒤 운영 적용을 판단하세요.
메모리 최적화: OID 성능의 핵심
메모리 계획에서는 실제로 함께 실행되는 프로세스를 구분합니다.
- Oracle Database의 SGA·PGA와 백그라운드 프로세스
- OID LDAP 서버 프로세스와 운영체제
- WebLogic 애플리케이션·관리 도구가 배치된 경우 해당 JVM
System Global Area(시스템 글로벌 영역, 이하 SGA) 구성과 튜닝
아래는 기존 글의 32GB 서버 설정 예시이며 검증된 권장 명령이 아닙니다. 그대로 실행하지 마세요.
특히 SGA_MAX_SIZE는 정적 파라미터이므로 아래 SCOPE=BOTH 구문을 그대로 적용할 수 없습니다. 설치 버전, SPFILE 사용 여부, 재기동 계획과 전체 메모리 예산을 먼저 검토해야 합니다.
-- 기본 메모리 아키텍처 설정 ALTER SYSTEM SET sga_target = '24G' SCOPE=BOTH; ALTER SYSTEM SET sga_max_size = '24G' SCOPE=BOTH; -- 버퍼 캐시 설정 -- SGA의 약 2/3를 버퍼 캐시에 할당 ALTER SYSTEM SET db_cache_size = '16G' SCOPE=BOTH; -- 공유 풀 설정 -- 초기 설정은 4GB, 실제 사용량에 따라 조정 ALTER SYSTEM SET shared_pool_size = '4G' SCOPE=BOTH;
24GB·16GB·4GB는 이 글의 예시 값입니다. 전체 RAM의 75%를 SGA에 할당하는 보편적인 Oracle 규칙으로 해석하면 안 됩니다. OS, PGA, OID 및 함께 실행되는 프로세스의 사용량을 합산해 메모리 예산을 정합니다.
SGA 구성 검토
- 버퍼 캐시는 읽기 패턴과 I/O 관측값을 기준으로 검토합니다.
- 공유 풀은 SQL·메타데이터 사용량과 메모리 관리 방식을 함께 확인합니다.
- 자동 SGA 관리 사용 시 개별 구성 요소 설정의 의미는 해당 버전 문서에서 확인합니다.
DB와 OID를 분리하면 호스트별 자원 경쟁을 따로 측정할 수 있습니다. 분리 자체가 성능 향상을 보장하지는 않습니다.
OID 호스트에도 LDAP 프로세스와 OS 메모리가 필요하며, JVM 예산은 WebLogic이 실제로 함께 배치된 경우에만 포함합니다.
금융 서비스 기업의 성능 개선 사례
아래 값은 메모리 진단 절차를 설명하는 예시입니다.
초기 상황 분석
현재 파라미터와 같은 시간대의 요청량·지연·I/O를 함께 기록합니다.
-- 현재 메모리 파라미터 설정 확인 SELECT name, value, display_value, description FROM v$parameter WHERE name IN ( 'sga_target', 'db_cache_size', 'shared_pool_size' );
기존 글에 제시된 초기 설정 예시:
sga_target = 8G db_cache_size = 4G shared_pool_size = 1G
설정값만으로 원인을 단정하지 말고 다음 현상을 같은 시간대에 대조합니다.
- 물리 읽기와 디스크 대기 증가 여부
- 피크 시간대의 요청량·응답 지연
- 세션 타임아웃과 관련 로그
시스템 개선 과정
기존 글에 제시된 변경 후 메모리 값입니다. 32GB 서버에서 안전한 구성인지 별도로 검증해야 하며, 측정 없이 적용해서는 안 됩니다.
-- 최적화된 메모리 설정 sga_target = 24G db_cache_size = 16G shared_pool_size = 4G
변경 전후의 같은 부하 구간에서 지표를 비교합니다. 아래 조회 예시의 권한·뷰·지표 이름은 설치 버전 문서에서 확인하세요.
-- 주요 성능 지표 모니터링 SELECT metric_name, value, metric_unit FROM v$sysmetric_history WHERE group_id = 2 AND metric_name IN ( 'Physical Read Total IO Requests Per Sec', 'Response Time Per Txn', 'Session Count' );
효과 판정 메모리 값을 늘렸다는 사실만으로 성능이 개선됐다고 판단해서는 안 됩니다. 같은 요청 유형과 부하에서 응답 지연·오류·물리 읽기·메모리 압박을 비교합니다.
연결(Connection) 관리: 안정적인 OID 운영의 핵심
연결 문제를 진단할 때는 클라이언트 LDAP 풀, OID의 DB 연결, 데이터베이스 프로세스·세션 한도를 구분합니다. 각 구간의 사용량과 대기를 같은 시간대에 비교해야 합니다.
데이터베이스 연결 설정의 이해
다음 조회로 현재 시스템의 연결·프로세스 설정을 확인합니다:
-- 현재 연결 및 프로세스 설정 확인 SELECT name, value, display_value, description FROM v$parameter WHERE name IN ( 'processes', 'sessions', 'transactions' );
아래는 기존 글의 연결 설정 예시이며 바로 실행할 권장안이 아닙니다. Oracle Database 19c의 non-CDB와 CDB$ROOT에서는 PROCESSES, SESSIONS, TRANSACTIONS를 ALTER SYSTEM으로 즉시 바꿀 수 없으므로 SCOPE=SPFILE로 지정하고 재기동해야 합니다.
SESSIONS의 기본값은 (1.5 × PROCESSES) + 22, TRANSACTIONS는 SESSIONS에서 파생됩니다.
-- 연결 파라미터 설정 예시 (재기동 후 적용) ALTER SYSTEM SET processes = 500 SCOPE=SPFILE; ALTER SYSTEM SET sessions = 750 SCOPE=SPFILE; -- 기본 파생식: (1.5 × PROCESSES) + 22 ALTER SYSTEM SET transactions = 825 SCOPE=SPFILE; -- 기본값은 SESSIONS에서 파생(약 1.1배)
연결 한도 해석
- PROCESSES는 사용자 접속뿐 아니라 백그라운드 작업 등에 필요한 프로세스를 포함합니다. 500이라는 값만으로 동시 사용자 300~400명을 보장할 수 없습니다.
- SESSIONS의 기본 파생식과 하한은 버전별로 확인합니다. 750은 이 글의 예시이며 보편적인 1.5배 규칙이 아닙니다.
- WebLogic 실행 스레드 수, 애플리케이션 연결 풀, OID DB 풀은 서로 다른 한도입니다. 스레드 50개가 DB 세션 50개를 뜻하지 않습니다.
- 허용 한도에서 현재 사용량을 뺀 값은 미리 점유된 세션 수가 아닙니다. 사용량·대기·오류로 실제 제약을 확인합니다.
LDAP 서버 연결 관리
OID의 LDAP 처리와 DB 연결 설정은 역할이 다릅니다. DB의 실제 수용 여력과 OID 프로세스별 연결 사용량을 함께 확인합니다.
아래 LDIF는 조회가 아니라 설정 변경 예시입니다. 실행하지 말고 설치 버전의 DN·속성·재시작 요구사항을 먼저 확인하세요.
# LDAP 연결 설정 변경 예시 dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclmaxcc orclmaxcc: 10 - replace: orclserverprocs orclserverprocs: 8 - replace: orclldapconntimeout orclldapconntimeout: 60
설정 의미와 적용 조건
- orclmaxcc는 OID 서버 프로세스별 DB 연결 수입니다. 10은 예시이며 LDAP 클라이언트 접속 한도와 구분합니다.
- orclserverprocs는 OID LDAP 서버 프로세스 수입니다. 8개가 모든 8코어 환경에서 최적이라는 뜻은 아닙니다.
- OID 12.2.1.4 문서(관리 가이드 Table 9-1)에서 orclldapconntimeout의 단위는 분입니다. 값 60을 60초로 해석하지 마세요. 설치된 버전 문서와 통계 수집 사용자 예외를 확인합니다.
- 프로세스·DB 연결 설정 변경에는 재시작이 필요할 수 있습니다. 운영 적용 전에 버전별 절차를 확인합니다.
다음 조회 예시는 연결 관측용이며, 사용 가능한 속성·권한과 placeholder를 확인해야 합니다.
연결 사용량 모니터링:
# 연결 통계 조회 (orclstatsflag=1 필요) ldapsearch -h <host> -p <port> -D cn=orcladmin -q \ -b "cn=client connections,cn=monitor" -s base "(objectclass=*)" \ open_connections new_connections closed_connections
대형 리테일 포털의 연말 쇼핑 시즌 대응 사례
기존 글의 리테일 사례는 연결 타임아웃 진단을 설명하는 예시입니다. 원본 로그·변경 이력·측정 조건이 없으므로 실제 기업에서 재현된 결과로 단정하지 않습니다.
초기 상황 분석
현재 연결 사용량과 과거 최대 사용량을 따로 확인합니다. 아래 비율은 현재값/과거 최대값이며 구성 한도 대비 포화율이 아닙니다. MAX_UTILIZATION이 0인 경우도 별도로 처리해야 합니다.
-- 연결 상태 확인 SELECT resource_name, current_utilization, max_utilization, ROUND(current_utilization/max_utilization * 100, 2) as usage_percentage FROM v$resource_limit WHERE resource_name IN ('processes', 'sessions');
기존 글의 초기 설정 예시:
processes = 200
sessions = 300
orclmaxcc = 5
orclserverprocs = 4
함께 조사할 현상
- 피크 시간대의 연결 타임아웃과 요청량
- 로그인·결제 요청의 대기 구간
- 오류·재시도·사용자 영향
설정값만으로 장애 원인이나 매출 영향을 입증할 수는 없습니다.
시스템 최적화 과정
기존 글의 변경 예시입니다. PROCESSES와 SESSIONS는 즉시 바꿀 수 없으므로 SCOPE=SPFILE로 지정한 뒤 재기동해야 하며, DB 파라미터와 OID 설정의 적용·재시작 조건을 각각 확인해야 합니다.
-- 데이터베이스 연결 용량 확장 (재기동 후 적용) ALTER SYSTEM SET processes = 500 SCOPE=SPFILE; ALTER SYSTEM SET sessions = 750 SCOPE=SPFILE;
# LDAP 서버 설정 변경 예시 dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclmaxcc orclmaxcc: 10 - replace: orclserverprocs orclserverprocs: 8
결과 검증 같은 요청 유형·부하·측정 구간에서 변경 전후의 타임아웃, 인증 대기 시간, 오류를 비교해 효과를 판단합니다.
연결 설정 변경이 장애를 해결했다고 판단하려면 변경 전후 자료가 필요합니다. DB·OID 연결 대기와 네트워크 지연을 구분하고, 연결 누수·느린 쿼리·클라이언트 재시도도 함께 조사합니다.
확장 전략 구현: 체계적인 접근법
변경 전에 현재 병목과 적용 조건을 확인합니다. 변경 범위, 측정 기준과 복구 절차를 정하고 시험 환경에서 효과를 비교한 뒤 운영 적용을 판단합니다.
초기 시스템 분석
현재 요청량과 지연 구간을 기준으로 메모리·CPU·프로세스 사용량을 수집합니다.
메모리 사용량 확인
같은 호스트에 DB·OID·WebLogic이 있는지 먼저 확인합니다. 실제 배치된 프로세스별 메모리와 OS 사용량을 기록하고, 서버가 분리돼 있으면 노드별로 측정합니다. 아래는 Linux 출력 예시입니다.
$ free -m total used free shared buff/cache available Mem: 32000 24000 1000 1000 6000 7000
위 출력의 free는 1000MB, available은 7000MB입니다. 두 값을 혼동해 가용 메모리가 1GB라고 해석하면 안 됩니다.
available의 추이, swap I/O와 프로세스 사용량을 함께 확인해야 메모리 압박을 판단할 수 있습니다.
CPU 부하 분석
$ top %Cpu(s): 85.2 us, 10.3 sy, 0.0 ni, 4.1 id, 0.0 wa, 0.0 hi, 0.4 si
위 출력에서 us는 85.2%, sy는 10.3%, idle은 4.1%입니다. 단일 시점의 높은 사용률만으로 장애나 증설 필요성을 단정하지 않습니다. 지속 시간, 프로세스별 부하, 요청 지연을 함께 확인합니다.
데이터베이스 프로세스 상태 확인
-- 데이터베이스 연결이 제한에 근접 SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name = 'processes'; RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION processes 450 500
CURRENT_UTILIZATION은 현재 사용량, MAX_UTILIZATION은 기동 이후 최대 사용량입니다. 예시의 450/500을 구성 한도 대비 90%로 해석하면 안 됩니다. 실제 한도는 LIMIT_VALUE와 대조해야 하며, 해당 조회 예시에는 한도 열이 빠져 있습니다.
단계별 변경 적용: 안전하고 효과적인 시스템 개선
한 번에 여러 설정을 바꾸면 원인과 효과를 구분하기 어렵습니다. 변경마다 측정 구간과 복구 기준을 유지하고 다음 변경 여부를 판단합니다.
1단계: 메모리 최적화
아래 SGA 값은 예시입니다. 현재 상한과 메모리 예산을 확인한 후 시험 환경에서 비교하세요. SCOPE=SPFILE 변경은 현재 메모리에 즉시 반영되는 변경과 구분해야 합니다.
-- 단계적 SGA 증가 ALTER SYSTEM SET sga_target = '16G' SCOPE=SPFILE; ALTER SYSTEM SET db_cache_size = '10G' SCOPE=SPFILE;
SGA 목표값은 OS·PGA·OID 등 실제 프로세스의 메모리 사용량을 고려해 정합니다. 기존 상한, 변경 범위와 재기동 절차를 확인하지 않고 크기만 늘리지 않습니다.
2단계: 연결 풀(Connection Pool) 최적화
아래 값은 DB 연결 한도 변경 예시이며 즉시 실행할 권장안이 아닙니다. 현재 한도와 사용량·대기를 대조하고 SPFILE 적용 및 재기동 조건을 확인합니다.
-- 연결 용량의 단계적 확장 ALTER SYSTEM SET processes = 750 SCOPE=SPFILE; ALTER SYSTEM SET sessions = 1125 SCOPE=SPFILE;
연결 용량 변경을 판단하는 순서
- DB 프로세스·세션 한도와 실제 사용량·대기·오류를 비교합니다. 사용률이 높다는 이유만으로 한도를 늘려서는 안 됩니다.
- OID 프로세스별 DB 연결 사용량과 연결 누수·느린 처리 여부를 확인합니다.
- 클라이언트 LDAP 풀과 WebLogic 실행 스레드는 별도로 측정합니다. 변경 후에는 DB·OID 부하가 함께 늘어나는지도 비교합니다.
파라미터 표기: processes, sessions, transactions, orclmaxcc, orclserverprocs
3단계: 모니터링과 검증
변경 전후 같은 부하에서 비교할 항목
- CPU·메모리·swap I/O
- 디스크 I/O와 DB 대기
- LDAP 요청 유형별 지연·처리량·오류
- 클라이언트 풀·OID DB 연결의 사용량과 대기
- 분리된 서버 사이의 지연·재전송
연결 누수와 네트워크 지연은 서로 다른 원인이므로 로그와 관측값으로 구분합니다.
사례에서 확인해야 할 점
아래는 기존 사례 서술에서 검증이 필요한 항목과 운영상 점검 기준입니다. 원본 측정 자료 없이 실제 개선 성과를 확정하지 않습니다.
성능 개선 결과의 검증 지연·오류·처리량을 같은 부하에서 비교한 자료로 효과를 판단합니다.
운영 검토 기준
변경과 측정 기록을 남깁니다.
- DB·OID·애플리케이션의 제약을 따로 조사하고 상호 부하를 비교합니다.
- 같은 구간의 CPU·메모리·연결 사용량·로그를 보관합니다.
- 변경마다 결과와 복구 기준을 기록하고, 확인되지 않은 원인은 미결로 남깁니다.
OID 서버 분리 구성 고려 사항: 성능과 안정성의 균형
DB와 OID를 같은 호스트에 둘지 분리할지는 자원 경쟁, 네트워크 지연, 지원 구성과 비용을 함께 검토해 결정합니다. 모든 기업의 일반적인 배치를 단정하거나 분리만으로 개선을 보장하지 않습니다.
호스트별 관측 대상을 구분합니다.
- OID: LDAP 프로세스의 메모리·CPU와 DB 연결 대기
- DB: SGA·PGA, I/O와 백그라운드 작업
- WebLogic: 실제 애플리케이션·관리 도구가 배치된 호스트의 JVM·실행 스레드
분리 구성은 자원을 따로 조정할 여지를 주지만 무중단 변경이나 독립적인 성능 개선을 보장하지 않습니다. 서버 추가·RAC 도입은 지원 토폴로지, 라이선스와 장애 전환 조건을 별도로 검토합니다.
네트워크 설계와 검증
- OID와 DB 사이의 지연·재전송·대역폭을 피크 요청 구간에서 측정합니다.
- 1ms나 평상시 3배 대역폭은 보편적인 합격 기준이 아닙니다. 실제 요청 유형과 허용 지연에 따라 목표를 정합니다.
- 배치 위치와 장애 영역을 함께 검토합니다. 가까운 배치만으로 가용성이 확보되지는 않습니다.
- 이중 경로와 장애 전환은 지원 구성과 시험 결과를 확인하고 판단합니다.
연결 대기와 네트워크 지연을 구분하고, 변경 전후 오류·처리량까지 비교합니다.
비용·라이선스 검토
- 서버·네트워크·전원·운영 인력 비용을 비교합니다.
- Oracle Database 과금 기준을 CPU 코어만으로 단정하지 않습니다. 제품·에디션·Processor 또는 Named User Plus 등 계약 조건을 확인합니다.
- OID와 DB의 배치·가상화·클러스터 구성에 따른 라이선스 범위는 계약과 공식 정책으로 별도 검토합니다.
- 응답 시간 개선이 매출 증가로 이어졌다는 판단에는 별도의 사업 지표가 필요합니다.
서버 분리 여부는 측정된 병목, 지원 조건, 복구 절차와 총비용을 근거로 결정합니다.
Quick Parameter Reference Table
아래 표는 기존 글의 파라미터 예시를 요약한 것입니다. 현재 버전의 권장값이나 검증된 설정으로 취급하지 마세요. 단위·기본값·변경 가능 범위·재시작 요구사항은 설치 버전의 공식 문서로 확인해야 합니다.
| 구분 | 파라미터 | 본문에서 확인할 항목 |
|---|---|---|
| 데이터베이스 연결 | processes, sessions, transactions | 현재 사용량·과거 최대 사용량·구성 한도를 구분하고, 설치 버전의 변경·재기동 조건을 확인합니다. |
| 데이터베이스 메모리 | sga_target, db_cache_size, shared_pool_size | 전체 RAM과 OS·PGA·OID 등 실제 프로세스의 메모리 사용량을 함께 확인합니다. |
| OID LDAP | orclmaxcc, orclserverprocs, orclldapconntimeout | OID 프로세스별 DB 연결과 프로세스 수를 구분하고, 설치 버전의 단위·재시작 조건을 확인합니다. |
| WebLogic·JVM | 실행 스레드·JVM 메모리 | WebLogic 애플리케이션·관리 도구가 실제로 배치된 경우 해당 JVM과 실행 스레드를 따로 관측합니다. |
운영 팁: 사용할 수 있는 OS·OID·DB 지표와 라이선스가 허용하는 도구부터 확인합니다. 같은 부하에서 변경 전후를 비교하고, 측정 없이 파라미터나 용량을 늘려서는 안 됩니다.
구현 전략 요약
OID 확장 계획은 요청 부하와 실제 병목, 지원 구성, 복구 절차와 비용을 함께 검토하는 작업입니다. 메모리와 연결 한도의 숫자만으로 성능을 판단하지 마세요.
이 글의 설정 값은 예시입니다. 운영 적용 전에는 설치 버전의 문서와 시험 결과가 필요합니다.
Part 3에서는 실제 배치된 WebLogic 애플리케이션·관리 도구의 JVM과 스레드 관측을 OID LDAP 처리와 구분해 살펴봅니다.