Oracle Internet Directory(OID)의 LDAP 요청이 느리거나 연결이 끊긴다면, 요청 지표와 구성 요소별 부하를 함께 확인해야 합니다. 이 글은 메모리·CPU·데이터베이스 점검부터 연결 장애, 보안, 모니터링과 유지 보수까지 살펴봅니다.
설정값과 명령은 검증이 필요한 예제입니다. 설치 버전과 구성에 맞는지 확인하고, 운영 반영 전 시험 환경에서 변경 전후를 비교하세요.
OID 성능을 점검할 때는 LDAP 요청의 응답 시간과 처리량을 먼저 확인하고, OID 프로세스·관리 서버·데이터베이스의 부하를 나누어 살펴봅니다.
메모리: 성능의 토대
메모리는 OID 프로세스, WebLogic 관리 서버, 운영 체제의 사용량을 구분해 산정합니다. 백엔드 Oracle Database가 같은 서버에 있다면 데이터베이스 메모리도 별도로 포함해야 합니다.
- OID 프로세스의 메모리 사용량은 캐시, 연결 수, 요청 특성에 따라 달라집니다. 4GB를 모든 환경의 최소 요구사항으로 적용할 수는 없습니다.
orclmaxcc는 백엔드 데이터베이스 연결 수와 관련된 속성이며, OID 메모리 크기나 LDAP 캐시 용량을 직접 지정하는 값이 아닙니다. - WebLogic Server의 힙 크기는 관리 콘솔과 ODSM의 사용량, 지원 JDK, 도메인 구성에 맞게 정합니다. 2GB는 아래 예제의 힙 크기일 뿐, 보편적인 최소 사양은 아닙니다.
- 운영 체제와 파일 캐시에도 여유 메모리가 필요합니다. OS용 2GB를 고정 예약하는 대신 실제 사용량과 스왑 발생 여부를 확인하세요.
필요 메모리는 항목 수나 애플리케이션 수만으로 계산하지 말고, 설치 버전의 요구사항과 데이터 크기·검색 조건·동시 부하·캐시 적중률·데이터베이스 사용량을 시험 환경에서 측정해 정합니다.
아래는 WebLogic AdminServer의 JVM 옵션을 보여 주는 예제입니다. 지원 JDK와 시작 스크립트의 적용 위치를 확인한 뒤 시험 환경에서 검증하세요. 힙·메타스페이스·GC 스레드 수를 운영 환경에 그대로 적용하지 마세요.
#!/bin/bash
if [ "${SERVER_NAME}" = "AdminServer" ] ; then
# 최소/최대 힙 크기
USER_MEM_ARGS="-Xms2048m -Xmx2048m"
# 메타스페이스 설정
USER_MEM_ARGS="${USER_MEM_ARGS} -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
# 가비지 컬렉션(G1GC) 및 관련 파라미터
USER_MEM_ARGS="${USER_MEM_ARGS} -XX:+UseG1GC"
USER_MEM_ARGS="${USER_MEM_ARGS} -XX:MaxGCPauseMillis=200"
USER_MEM_ARGS="${USER_MEM_ARGS} -XX:ParallelGCThreads=4"
export USER_MEM_ARGS
fi G1GC는 사용하지 않는 객체를 회수하는 가비지 컬렉터입니다. MaxGCPauseMillis=200은 GC 중단 시간을 200밀리초로 제한한다는 보장이 아니라 목표값입니다. 실제 중단 시간은 힙 사용량과 부하에 따라 달라지므로 GC 로그와 응답 시간을 함께 확인해야 합니다.
CPU 용량과 부하
CPU 용량은 최대 부하에서 LDAP 요청을 얼마나 처리해야 하는지에 맞춰 판단합니다. OID와 백엔드 데이터베이스, 관리 서버가 CPU를 함께 사용하는지도 확인하세요.
OID 2코어, WebLogic 1코어, OS 1코어라는 구분은 예시일 뿐, 모든 환경의 최소 요구사항이나 실제 CPU 고정 할당을 뜻하지 않습니다. 설치 버전의 시스템 요구사항과 최대 부하 측정 결과를 기준으로 용량을 정하세요.
CPU 증설은 연결 수나 항목 수만으로 정하지 말고, 요청 빈도·검색 범위·응답 시간·DB 부하를 함께 측정해 판단합니다.
다음은 CPU 지표를 읽어 예시 경고값과 비교하는 스크립트입니다.
CPU_THRESHOLD=70
LOAD_THRESHOLD=$(nproc)
# CPU 사용량을 확인하고 임계값을 초과하면 경고
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')
if [ $(echo "$CPU_USAGE > $CPU_THRESHOLD" | bc) -eq 1 ]; then
echo "ALERT: High CPU usage detected: ${CPU_USAGE}%"
fi 이 예제는 top 출력에서 읽은 CPU 사용률을 70과 비교합니다. 70%는 예시 경고값이며 성능을 보장하는 임계값이 아닙니다. top 출력 형식과 파싱 결과, 의존 도구를 확인하고 지속 부하와 응답 시간에 맞게 경고 기준을 정하세요.
OID 데이터베이스 튜닝
OID는 Oracle Database를 디렉터리 저장소로 사용합니다. 아래의 6G·2G·2G는 설정 형식을 보여 주는 예제입니다. 메모리 관리 방식과 가용 RAM을 확인하고, SCOPE=SPFILE의 적용 시점과 재기동 영향을 검토한 뒤 별도의 시험 환경에서 검증하세요.
ALTER SYSTEM SET sga_target = 6G SCOPE=SPFILE;
ALTER SYSTEM SET pga_aggregate_target = 2G SCOPE=SPFILE;
ALTER SYSTEM SET db_cache_size = 2G SCOPE=SPFILE; - SGA는 데이터베이스가 공유하는 메모리 영역입니다. 특정 비율을 그대로 적용하기보다 데이터베이스에 사용할 수 있는 RAM과 다른 프로세스의 사용량을 확인합니다. Oracle의 OID 12.2.1.4 가이드에 제시된 비율도 해당 조건에서 읽어야 합니다.
- PGA는 프로세스 작업에 쓰이는 메모리입니다. SGA의 25%로 고정 산정하지 말고 실제 작업량과 메모리 사용량을 기준으로 조정하세요. 자동 SGA 관리와 DB_CACHE_SIZE의 관계도 확인해야 합니다.
옵티마이저 통계가 오래되면 실행 계획에 영향을 줄 수 있습니다. OID 12.2.1.4 문서에는 oidstats.sql과 OIDMON의 자동 통계 수집이 설명되어 있습니다. 아래 DBMS_STATS 호출을 정기 작업으로 추가하기 전에 실제 ODS 스키마명, 설치 버전의 지원 절차와 기존 자동 수집을 확인하세요.
-- OID 스키마 통계 분석
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
'PREFIX_ODS',
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt => 'FOR ALL COLUMNS SIZE AUTO',
cascade => TRUE
); 통계 수집은 옵티마이저가 데이터 분포를 파악하는 데 사용됩니다. 통계를 갱신했다고 성능이 항상 좋아지는 것은 아니므로 변경 전후의 실행 계획과 응답 시간을 비교합니다.
성능 문제를 조사하는 순서
장애를 조사할 때는 먼저 연결 실패인지 응답 지연인지 구분합니다. 발생 시각과 영향을 받는 클라이언트를 기록하고, 같은 시간대의 OID·운영 체제·데이터베이스 지표를 비교하세요.
연결 실패 점검
연결 실패는 네트워크 도달성, 서비스 상태, 인증, TLS 설정을 나누어 확인합니다. 한 단계의 점검이 통과했다고 전체 연결 경로가 정상이라고 판단하지 마세요.
LDAP 클라이언트 연결 불가
먼저 서버 도달성과 서비스의 수신 상태를 확인합니다. 아래 명령의 결과만으로 LDAP 인증이나 실제 요청 처리가 정상이라고 단정할 수는 없습니다.
# 서버 연결 가능 여부 확인
ping <oid_server>
# 서비스 리스닝 여부 확인
netstat -tlnp | grep oidldapd
기본 점검에서 원인을 찾지 못했다면 OID 프로세스 상태와 서버 로그를 장애 발생 시각 기준으로 확인합니다. OID 12c의 서버 로그는 $DOMAIN_HOME/servers/OID/logs/<컴포넌트_이름>/에 있습니다(서버 프로세스는 oidldapd01s<PID>-*.log, 디스패처는 oidldapd01-*.log).
12c 인스턴스 관리는 WLST나 Fusion Middleware Control을 권장하며, oidctl을 쓸 때는 DB 접속 문자열을 지정합니다.
# OID 프로세스 상태 확인 (oidctl에는 DB 접속 문자열이 필요)
oidctl connect=<db_connect_string> status
# OID 12c 서버 로그 위치: $DOMAIN_HOME/servers/OID/logs/<컴포넌트_이름>/
ls -lt $DOMAIN_HOME/servers/OID/logs/oid1/
tail -f $DOMAIN_HOME/servers/OID/logs/oid1/oidldapd01s*.logSSL/TLS 연결 실패
SSL/TLS 연결 실패가 발생하면 먼저 인증서 파일의 내용을 확인합니다. 이는 진단 과정의 한 단계이며, 실제 연결이 정상이라는 증거는 아닙니다.
# 인증서 유효성 확인
openssl x509 -text -noout -in <certificate_file>이 명령은 인증서의 세부 정보를 표시합니다. 파일 내용을 읽었다고 클라이언트의 신뢰 설정이나 TLS 연결 성공까지 확인한 것은 아닙니다.
성능 문제 (속도 저하)
응답 지연이 나타나면 영향을 받는 LDAP 작업과 시간대를 먼저 좁힙니다. 클라이언트의 응답 시간과 서버 지표를 같은 구간에서 비교해 병목 후보를 찾습니다.
느린 LDAP 작업
OID 프로세스의 CPU·메모리 사용량을 확인하고 요청량 변화와 비교합니다. 아래의 단일 시점 출력만으로 지속적인 병목을 확정하지 마세요.
# 시스템 리소스 사용량 확인
top -b -n 1
# OID 프로세스 모니터링
ps -eo pid,ppid,%cpu,%mem,cmd | grep oidldapd백엔드 데이터베이스도 함께 확인해야 합니다. 다음 쿼리는 대기 이벤트를 살펴보는 예제이며, 관찰 구간과 지표의 의미를 확인한 뒤 해석합니다.
-- 데이터베이스 병목 현상 확인
SELECT event, total_waits, time_waited
FROM v$system_event
WHERE wait_class != 'Idle'
ORDER BY time_waited DESC;이 쿼리는 인스턴스의 누적 대기 시간을 보여 줍니다. 누적값만으로 현재 느린 LDAP 요청의 원인을 확정하지 말고, 같은 관찰 구간의 변화량과 OID 요청 지표를 함께 비교하세요.
모범 사례 — 안정적 OID 환경 구축
장애 대응 후에는 같은 증상을 다시 발견할 수 있도록 점검 지표와 변경 기록을 남깁니다. 보안 정책, 감사 기록, 모니터링과 유지 보수 절차도 함께 검토하세요.
보안 강화
OID 보안은 인증·암호 정책·접근 권한·감사 기록을 함께 검토해야 합니다. 아래 예제를 적용하기 전에 현재 정책과 설치 버전의 지원 기능을 확인하세요.
강력한 암호 정책
아래는 OID 12.2.1.4의 디렉터리 기본 암호 정책(cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext)에서 최소 길이를 바꾸는 예입니다. 정책은 orclpwdpolicyenable이 켜져 있을 때만 적용됩니다. -q는 비밀번호를 명령행에 남기지 않고 프롬프트로 받습니다. 구문 검사(pwdCheckSyntax: 1)는 이미 기본값입니다.
ldapmodify -h <hostname> -p <port> -D cn=orcladmin -q << EOF
dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext
changetype: modify
replace: pwdMinLength
pwdMinLength: 12
EOF암호 길이와 구문 검사 설정만으로 인증 보안이 완성되지는 않습니다. 지원되는 정책 속성, 적용 대상과 기존 클라이언트에 미치는 영향을 시험 환경에서 확인하세요.
감사 추적(로그)
OID 12c는 감사 기록을 ODS 테이블에 두지 않습니다. Fusion Middleware Audit Framework를 쓰며, 감사 수준은 orclaudfilterpreset(None, Low, Medium, All, Custom)으로 정하고, 기록은 감사 파일이나 감사 DB 저장소를 구성한 경우 IAU 스키마(예: IAU_BASE)에 쌓입니다.
자세한 내용은 OID 12.2.1.4 관리 가이드의 Managing Auditing을 참고하세요.
# OID 12c audit settings (Fusion Middleware Audit Framework)
orclaudfilterpreset # None | Low | Medium | All | Custom
orclaudcustevents # events to audit when the preset is Custom
orclaudsplusers # users that are always audited감사 기록에는 누가 언제 어떤 작업을 했는지 조사할 수 있는 정보가 필요합니다. 실제 기록 항목과 보존 정책을 확인해야 하며, 예시 쿼리만으로 감사나 규정 준수가 충족된다고 볼 수는 없습니다.
사전 예방적 모니터링
통계 수집을 켜면(orclstatsflag=1, 주기는 orclstatsperiodicity) cn=monitor 아래에서 연결 통계를 볼 수 있습니다. 문서에 있는 범주는 cn=system information, cn=work queue, cn=client connections, cn=version입니다.
# 연결 통계 조회 (open_connections, new_connections, closed_connections 등)
# 통계 수집이 켜져 있어야 함: orclstatsflag=1, 주기는 orclstatsperiodicity
ldapsearch -h localhost -p 3060 -D cn=orcladmin -q \
-b "cn=client connections,cn=monitor" -s base "(objectclass=*)"open_connections를 서버 프로세스당 한도 orclmaxldapconns(기본 1024)와 비교합니다. 이전 버전의 스크립트는 oidctl status에서 “Current Connections” 줄을 읽었지만, 이 명령은 프로세스 표를 출력하며 그런 항목이 없습니다.
정기 점검과 유지 보수
점검 주기는 서비스 중요도와 변경 빈도에 맞게 정합니다. 아래 일별·주간·월간 항목은 운영 점검을 구성하는 예시이며, 명령을 해당 주기로 자동 실행하라는 뜻은 아닙니다.
일별 점검
매일 확인할 운영 지표는 다음과 같습니다:
- 경고 로그 검토
- 연결 통계 확인
- 리소스 사용량 모니터링
주간 점검
성능 추세와 보안 기록을 검토합니다:
- 스키마 통계의 최신 상태와 자동 수집 여부 확인
- 성능 추세 분석
- 보안 로그 검토
월간 점검
용량 계획과 운영 절차를 함께 검토합니다:
- 전체 시스템 성능 검토 수행
- 용량 계획 업데이트
- 상세 보안 감사 실시
결론 (Conclusion)
OID 성능 관리는 요청 지표를 확인하고, 구성 요소별 병목을 좁힌 뒤 변경 전후를 비교하는 과정입니다. 이 글의 점검 항목을 바탕으로 운영 환경에 맞는 절차를 정리하세요.
예제 설정은 보편적인 최적값이 아닙니다. 설치 버전과 부하에 맞는지 시험 환경에서 검증하고, 적용·복구 절차와 측정 결과를 기록한 뒤 운영 반영 여부를 판단합니다.
OID 운영의 다음 단계: 성장을 위한 확장
OID 운영에서는 설정을 한 번 조정하는 데 그치지 않고, 부하와 응답 시간을 계속 확인해야 합니다. 이 글의 점검 항목을 바탕으로 병목을 찾고, 변경 전후를 비교하면서 운영 요구사항에 맞게 구성을 조정하세요. 확장이 필요할 때도 측정 기록이 판단 기준이 됩니다.
관련 [Oracle Internet Directory (OID) Enterprise Scaling, Part 1: Fundamentals & Core Architecture] 가이드에서는, 구성 원리와 측정 기준을 바탕으로 OID 확장에 관한 중요한 다음 단계를 살펴볼 수 있습니다. 특히 다음과 같은 항목을 현재 환경과 대조해 보세요:
- 최적화된 시스템이 어느 시점에서 확장이 필요한지 판단하는 방법
- 사용자 수와 디렉터리 크기가 급격히 늘어날 때의 관리 전략
- 성능을 유지하면서 고가용성 솔루션을 구현하는 요령
- 확장 사례의 적용 조건과 현재 환경의 차이
각 예제는 설치 버전과 부하 조건이 현재 환경에 맞는지 확인한 뒤 참고하세요.
확장과 튜닝 모두 시험 환경에서 검증하고, 운영 반영 전 변경 범위와 복구 방법을 확인하세요.