#성능최적화

JBoss EAP 7.x 성능 튜닝 완벽 가이드: 스레드·JVM·OS 통합 설정

⚙️ WAS 📅 2026. 04. 07 | ⏱ 약 2분 읽기
JBoss EAP 운영 중 응답 지연·Out of Memory·503 오류가 발생한다면 스레드 풀, JVM 힙, OS 커널 파라미터 세 가지를 함께 점검해야 합니다. 이 글에서는 JBoss EAP 6.4 / 7.x 기준으로 각 계층을 체계적으로 튜닝하는 방법을 실무 중심으로 정리합니다.
적용 버전: JBoss EAP 6.4 / 7.x  |  OS: RHEL 6/7, CentOS 7

1. Apache HTTPD 튜닝 (MPM 설정)

Apache가 JBoss 앞에서 프록시 역할을 할 경우 MPM(Multi-Processing Module) 선택이 전체 처리량에 직접 영향을 줍니다.

MPM특징권장 환경
prefork프로세스 기반, 안정성 최우선mod_php 사용 시
worker프로세스+스레드 혼합, 메모리 효율↑고트래픽 프록시
eventKeepAlive 연결 비동기 처리, 최고 효율Apache 2.4+ 권장
# /etc/httpd/conf.modules.d/00-mpm.conf
# worker MPM 예시 (JBoss 프록시 환경 권장)
LoadModule mpm_worker_module modules/mod_mpm_worker.so


    StartServers          4
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestWorkers   400
    MaxConnectionsPerChild 10000

튜닝 포인트: MaxRequestWorkers × ThreadsPerChild가 실제 최대 동시 연결 수를 결정합니다. 메모리 여유분 확인 후 설정하세요. (ab -n 1000 -c 100 http://... 부하 테스트 병행 권장)


2. JBoss Thread Pool 튜닝

JBoss EAP 7.x의 스레드 풀은 Undertow 커넥터와 IO 워커 두 계층으로 구분됩니다.

2-1. Thread Pool (standalone.xml)

<!-- EAP 6.x: threads 서브시스템 -->
<subsystem xmlns="urn:jboss:domain:threads:1.1">
  <blocking-queueless-thread-pool name="http-executor">
    <max-threads count="200"/>
    <keepalive-time time="60" unit="seconds"/>
  </blocking-queueless-thread-pool>
</subsystem>

2-2. IO Worker (EAP 7.x Undertow)

<!-- EAP 7.x: io 서브시스템 -->
<subsystem xmlns="urn:jboss:domain:io:1.1">
  <worker name="default"
          io-threads="16"
          task-max-threads="256"
          task-keepalive="60"/>
</subsystem>
파라미터기본값권장값설명
io-threadsCPU×2CPU×2 ~ CPU×4I/O 이벤트 처리 스레드. CPU 코어 수에 비례하여 조정
task-max-threadsCPU×16128~256비동기 작업 스레드 최대치. 과도하게 높이면 컨텍스트 스위칭 증가
task-keepalive6060유휴 스레드 유지 시간(ms). 기본값 유지

검증 명령어:

$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command="/subsystem=io/worker=default:read-resource(include-runtime=true)"

3. JVM 튜닝 (Heap & GC)

JBoss 성능 문제의 상당수는 잘못된 JVM 힙 설정과 GC 정책에서 비롯됩니다. G1GC는 EAP 7.x(JDK 8+) 환경에서 가장 권장되는 GC 알고리즘입니다.

3-1. 힙 크기 설정

# standalone.conf (또는 domain.conf)
JAVA_OPTS="-Xms2048m -Xmx4096m"
JAVA_OPTS="$JAVA_OPTS -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
옵션기본값권장값설명
-Xms256m서버 RAM × 25%초기 힙. -Xmx와 동일하게 설정 시 힙 조정 오버헤드 제거
-Xmx512m서버 RAM × 50%최대 힙. 물리 RAM의 50% 이상은 OS/캐시용으로 남겨야 함
MetaspaceSize21m256m초기 Metaspace 크기. OutOfMemoryError 예방
MaxMetaspaceSize무제한512m반드시 상한 설정. 무제한 시 메모리 누수로 서버 OOM 가능

3-2. G1GC 설정

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
JAVA_OPTS="$JAVA_OPTS -XX:G1HeapRegionSize=16m"
JAVA_OPTS="$JAVA_OPTS -XX:InitiatingHeapOccupancyPercent=45"
# GC 로그 (운영 환경 필수)
JAVA_OPTS="$JAVA_OPTS -Xlog:gc*:file=/app/was/logs/gc.log:time,uptime:filecount=5,filesize=20m"

주의: MaxGCPauseMillis=200은 목표값이지 보장값이 아닙니다. 실제 GC 로그를 확인하며 점진적으로 조정하세요.


4. OS 튜닝 (Linux 커널 파라미터)

고트래픽 환경에서는 OS 레벨의 네트워크 백로그와 파일 디스크립터 제한이 병목이 될 수 있습니다.

4-1. sysctl 파라미터

# /etc/sysctl.conf
net.core.somaxconn=65535
net.ipv4.tcp_max_syn_backlog=65535
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_tw_reuse=1

# 적용
sysctl -p

4-2. 파일 디스크립터 제한 (ulimit)

# /etc/security/limits.conf
jboss soft nofile 65536
jboss hard nofile 65536

# 적용 확인 (JBoss 프로세스 PID로 확인)
cat /proc/$(pgrep -f jboss.modules)/limits | grep "open files"
파라미터기본값권장값설명
somaxconn12865535소켓 연결 큐 최대 크기. 부족 시 SYN Dropped 발생
tcp_fin_timeout6030TIME_WAIT 소켓 유지 시간. 줄이면 포트 재사용 빨라짐
nofile102465536열 수 있는 파일/소켓 수. 부족 시 "Too many open files" 오류

5. 검증 체크리스트

# ① JBoss IO Worker 런타임 상태 확인
$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command="/subsystem=io/worker=default:read-resource(include-runtime=true)"

# ② JVM 메모리 현재 상태
$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command=":read-attribute(name=max-memory)"

# ③ OS 파라미터 적용 확인
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

# ④ GC 로그 실시간 모니터링
tail -f /app/was/logs/gc.log

튜닝 적용 순서 (권장)

  • ① OS 파라미터 적용 (sysctl, limits) — 재부팅 불필요, 즉시 적용 가능
  • ② JVM 힙 및 GC 옵션 조정 후 JBoss 재기동
  • ③ 스레드 풀 설정 변경 후 reload (재기동 없이 적용 가능한 항목도 있음)
  • ④ Apache MPM 변경은 httpd 재기동 필요 — 점검 시간 확보 후 진행
#WAS#JBoss#EAP#JVM#Tuning#ThreadPool#G1GC#Linux
📝 원문 노트: Notion에서 보기 →
Open Stream →
#JVM

[WebSphere/JVM] HeapDump & JavaCore 생성 옵션 및 경로 변경 가이드

WebSphere Application Server(WAS) 운영 중 Out Of Memory(OOM) 에러 발생 시, 원인 분석을 위해 힙 덤프(HeapDump)와 자바 코어(JavaCore) 파일을 생성해야 합니다. 이를 위한 JVM Custom Properties 설정 방법과 생성 경로 변경, 그리고 AIX 환경에서의 필수 설정 사항을 정리합니다.

1. JVM Custom Properties 설정

WAS 관리 콘솔에서 JVM 인수에 직접 환경 변수를 설정하여 덤프 생성 여부와 경로를 제어할 수 있습니다.

설정 경로

Application servers > [Server Name] > Process definition > Java Virtual Machine > Custom properties

주요 속성 (Key & Value)

Name Value Description
IBM_HEAPDUMP true / false 힙 덤프 생성 활성화 여부
IBM_HEAPDUMP_OUTOFMEMORY true / false OOM 발생 시 힙 덤프 자동 생성
IBM_JAVADUMP_OUTOFMEMORY true / false OOM 발생 시 자바 코어(Thread Dump) 자동 생성
IBM_JAVA_HEAPDUMP_TEXT true / false 힙 덤프를 텍스트 형식으로 생성 (phd 대신)
JAVA_DUMP_OPTS ONANYSIGNAL(JAVADUMP[5],HEAPDUMP[5]) 시그널 발생 시 덤프 생성 옵션 제어

2. 덤프 생성 위치 변경 (Dump Path)

기본 생성 위치는 WAS 버전에 따라 다르며, 디스크 공간 부족 등의 이유로 별도 경로로 변경할 수 있습니다.

기본 생성 위치 (Default Path)

  • WAS V6.0 ~ V7.0: [Profile_Root]/logs/[Server_Name]
  • WAS V5.1: [Install_Root]/logs/[Server_Name]

경로 변경 설정

위와 동일한 Custom properties 메뉴에서 아래 속성을 추가합니다.

# AIX / Linux 예시 (/waslog 디렉토리로 변경)
IBM_COREDIR       /waslog
IBM_HEAPDUMPDIR   /waslog
IBM_JAVACOREDIR   /waslog

# Windows 예시 (D:\waslogs 디렉토리로 변경)
IBM_COREDIR       D:\waslogs
IBM_HEAPDUMPDIR   D:\waslogs
IBM_JAVACOREDIR   D:\waslogs

3. AIX 환경 필수 설정 (Environment Setup)

AIX 환경에서는 OOM 분석을 위해 OS 레벨의 사용자 제한(ulimit) 해제와 메모리 세그먼트 설정이 중요합니다.

1) 사용자 프로세스 제한 해제 (ulimit)

덤프 파일이 잘리지 않도록 파일 크기(fsize), 코어 크기(core), 데이터 세그먼트(data) 제한을 해제합니다. (root 권한 필요)

# 사용자(user_id)에 대해 제한 해제
chuser fsize=-1 data=-1 core=-1 stack=-1 [WAS_USER_ID]

# 적용 확인 (WAS 사용자 계정으로 로그인 후)
ulimit -a

2) 메모리 할당 방식 설정 (LDR_CNTRL)

Java Heap과 Native Heap을 분리하고 공간을 확보하기 위해 환경 변수를 설정합니다. MAXDATA 값은 Java Heap 크기(Xmx)에 따라 계산해야 합니다.

# 계산 공식: 8 - (Xmx(MB) / 256)
# 예: Xmx가 512MB인 경우 -> 8 - (512/256) = 6 -> 0x60000000

export IBM_JAVA_MMAP_JAVA_HEAP=true
export LDR_CNTRL=MAXDATA=0x60000000

3) GC 로그 활성화

메모리 누수 패턴 분석을 위해 GC 로그를 반드시 활성화해야 합니다. JVM Generic Arguments에 추가합니다.

-verbose:gc

표준 에러(stderr)가 파일로 리다이렉션 되도록 설정되어 있는지 확인하십시오. (native_stderr.log 등)


Next Step:
생성된 .phd 또는 .txt 형식의 힙 덤프 파일은 IBM HeapAnalyzerEclipse Memory Analyzer (MAT) 도구를 사용하여 분석할 수 있습니다.

Open Stream →