[실전 가이드] Solaris 11.4 서버 성능 점검: "느려터진 서버, 진짜 범인은 누구일까?"

서버 운영 중 모니터링 시스템(NMS)에서 "메모리 사용률 90% 초과" 또는 "Load Average 임계치 초과" 알람을 받고 접속해보면, 정작 CPU는 놀고 있는 기이한 현상을 마주할 때가 있습니다.

특히 Solaris 11.4 환경은 이전 버전이나 리눅스와 다른 독특한 메모리 관리 메커니즘(ZFS ARC)을 가지고 있어, 초급 엔지니어들이 오판을 내리기 쉽습니다.

오늘은 실제 현장에서 자주 발생하는 '가짜 메모리 부족' 현상과 **'Load Average의 진실'**을 파헤치고, 네트워크 병목과 과거의 장애 이력까지 추적하는 Solaris 서버 성능 점검 8단계 프로세스를 정리해 드립니다.

1. 전체 숲을 먼저 보자: prstat

가장 먼저 시스템 전반의 프로세스 상황을 확인해야 합니다. Solaris 11은 Zone(가상화) 환경이 보편적이므로 -Z 옵션이 필수입니다.

# prstat -Z -n 10 -s cpu

• -Z: Zone 별 리소스 사용량 합산 표시
• -n 10: 상위 10개 프로세스만 출력
• -s cpu: CPU 사용률 순으로 정렬 (메모리가 궁금하면 -s rss)

🚩 핵심 체크 포인트

1. 프로세스 개수 폭주: Total processes가 수천 개 단위를 넘어 1만 개에 육박한다면?
   • 이것은 CPU 사용률(%)이 낮아도 시스템을 느리게 만드는 주범입니다. (Context Switching 과부하)
   • Solution: 오라클 세션 누수(Inactive Session)나 좀비 프로세스를 의심해야 합니다.
2. LWP (Light Weight Process): 스레드 개수가 비정상적으로 많은지 확인합니다.

2. 메모리 분석: "사용률 90%"의 거대한 착시

Solaris 11 성능 분석의 최대 난관은 **ZFS ARC(Adaptive Replacement Cache)**입니다. Solaris는 **"놀고 있는 메모리는 낭비다"**라는 철학으로, 남는 메모리를 ZFS 파일 시스템 캐시로 최대한 끌어다 씁니다.

이 때문에 top이나 prstat에서 메모리가 꽉 찬 것처럼 보이지만, 실제로는 언제든 반환 가능한 여유 메모리인 경우가 90% 이상입니다.

진짜 메모리 사용량 확인하기: mdb

Solaris 엔지니어라면 free 명령어 대신 커널 디버거(mdb)를 사용해 정확한 메모리 맵을 봐야 합니다.

# echo "::memstat" | mdb -k

[출력 예시 및 해석]

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     135234              1056    2%
ZFS File Data             3824512             29879   60%  <-- [범인] 이게 높으면 정상입니다!
Anon                      1201231              9384   20%  <-- 실제 앱(Oracle 등) 사용량
Free (cachelist)            65421               511    1%

🚩 핵심 체크 포인트

• ZFS File Data: 이 비율이 높아서 전체 사용률이 높은 것이라면 절대 메모리 부족이 아닙니다.
• Anon: 오라클 SGA/PGA 등 애플리케이션이 실제로 점유하고 있는 메모리입니다. 이 수치가 물리 메모리의 80%를 넘는다면 그때는 진짜 증설이 필요합니다.

3. CPU와 부하(Load)의 진실: vmstat

"CPU 사용률은 5%인데, Load Average가 50을 넘어요." 이런 경우는 CPU 병목이 아니라 I/O 병목일 확률이 높습니다. vmstat으로 진실을 확인해 봅시다.

# vmstat 1 5

[출력 예시]

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s2 s3   in   sy   cs us sy id
 0 6 0  ...   ...    ...                0 ...          ...        ...  4  3 93

🚩 핵심 체크 포인트 (kthr & cpu)

1. sr (scan rate): 가장 중요합니다.
   • 이 값이 0이라면, 메모리는 부족하지 않습니다. 페이지 스캔이 발생하지 않고 있다는 뜻입니다.
2. b (blocked): I/O 처리를 기다리며 멈춰있는 프로세스 수입니다.
   • cpu id(idle)가 높은데 b 수치가 계속 찍힌다면? 100% 디스크 I/O가 범인입니다.
3. r (run queue): CPU를 쓰려고 줄 서 있는 프로세스 수입니다. 이 값이 높아야 진짜 CPU 부족입니다.

4. 개별 CPU 코어의 균형: mpstat

vmstat이 시스템 전체 평균을 보여준다면, mpstat은 각 코어(vCPU) 별 상태를 보여줍니다. 전체 CPU 사용률은 널널한데 시스템이 느리다면, **특정 코어 하나만 100%를 치고 있는 경우(Single Thread Bottleneck)**일 수 있습니다.

# mpstat 1 5

[출력 예시]

CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    0   342  120  400   20   10   50    0  2000   40  10   0  50
  1    0   0    0  8500 5000  300   15    5   10    0  1000   10  60   0  30

🚩 핵심 체크 포인트

1. intr (Interrupt): 특정 CPU(위 예시의 1번)에만 인터럽트가 몰리고 있지 않나요?
   • 네트워크 카드나 HBA 카드의 인터럽트가 한 코어에 집중되면 해당 코어만 과부하가 걸려 전체 성능이 저하됩니다.
2. migr (Migration): 스레드가 이 CPU 저 CPU로 자꾸 옮겨 다니는 횟수입니다.
   • 이 수치가 너무 높으면 CPU 캐시 효율이 떨어집니다. (CPU 바인딩 고려 필요)
3. smtx (Spin Mutex): 락(Lock)을 얻기 위해 CPU가 헛도는 횟수입니다.
   • 이 값이 높다면 애플리케이션(Oracle 등) 내부의 경합(Contention) 문제입니다.

5. 디스크 I/O 병목 잡기: iostat

앞서 vmstat에서 b 수치가 높게 나왔다면, 구체적으로 어떤 디스크가 느린지 색출해야 합니다.

# iostat -xnz 1 5

• -x: 확장 통계 표시
• -n: 디스크 이름(c0t0d0 등)을 보기 쉽게 표시
• -z: 활동이 없는 디스크는 제외

🚩 핵심 체크 포인트

• %w (Wait): I/O 큐에서 대기하는 비율. 0이 아니면 처리가 밀리고 있다는 뜻입니다.
• %b (Busy): 디스크가 실제 일하는 비율입니다.
• svc_t (Service Time): I/O 요청 하나를 처리하는 데 걸리는 시간(ms)입니다.
  • 일반적인 SSD/Storage 환경에서 10~20ms를 넘어간다면 심각한 성능 저하가 발생하고 있는 것입니다.

6. 네트워크 트래픽 이상 감지: dlstat & netstat

DB 서버의 응답이 느리다면 네트워크 인터페이스의 물리적 한계나 오류(Error)를 의심해야 합니다. Solaris 11.4에서는 dlstat이라는 강력한 도구를 제공합니다.

물리적 대역폭 사용량 확인: dlstat

# dlstat show-link -r

• -r: 수신(Rx) 및 송신(Tx) 속도를 실시간으로 보여줍니다.
• 10Gbps 카드인데 사용량이 한계치에 육박하는지 확인하세요.

패킷 에러 및 충돌 확인: netstat

# netstat -i

[출력 예시]

Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue
net0  1500 172.16.0.0    bssdb02       823120   0    99120    0     0      0

🚩 핵심 체크 포인트

• Ierrs / Oerrs (Input/Output Errors): 이 값이 0이 아니라면 케이블 불량, 스위치 포트 불량, 혹은 Duplex Mismatch(Speed/Duplex 설정 불일치)일 가능성이 매우 높습니다.
• Collis (Collisions): 충돌 횟수입니다. 스위치 환경에서는 0이어야 정상입니다.

7. 지난밤의 범행 현장 확인: sar

vmstat이나 iostat은 지금 이 순간의 상태만 보여줍니다. "새벽 3시에 잠깐 서버가 느렸어요"라는 리포트를 받았다면 sar (System Activity Reporter)를 써야 합니다. Solaris는 기본적으로 /var/adm/sa 디렉토리에 시스템 성능 이력을 저장합니다.

# sar -u -f /var/adm/sa/sa08

• -u: CPU 사용률 확인 (-d: 디스크, -q: Load/Queue, -r: 메모리, -n: 네트워크)
• -f /var/adm/sa/saXX: XX일의 로그 파일을 불러옵니다. (오늘 날짜면 생략 가능)

[활용 예시]

• sar -q: 과거 특정 시점의 Load Average (runq-sz)를 확인하여 부하가 튄 시점을 찾습니다.
• sar -d: 과거에 특정 디스크가 바빴는지 확인합니다.

8. 오라클 서버의 필수 블랙박스: OSWatcher

Oracle DB를 운영 중이라면 OSWatcher (현재는 ExaWatcher 또는 OSWbb로 불림) 설치는 선택이 아닌 필수입니다.

엔지니어가 24시간 모니터를 보고 있을 수는 없습니다. OSWatcher는 vmstat, iostat, mpstat, top, netstat 등의 명령어를 30초~1분 간격으로 실행하여 파일로 저장해두는 스크립트 도구입니다.

왜 필요한가요?

1. 세밀한 분석: sar는 보통 10분~20분 단위로 저장되어 순간적인 피크(Spike)를 놓칠 수 있지만, OSWatcher는 초 단위 분석이 가능합니다.
2. Oracle Support 요구: 오라클 장애 발생 시 SR(Service Request)을 올리면 엔지니어가 가장 먼저 요구하는 파일입니다.
3. 자동 정리: 오래된 로그는 알아서 지워주므로 디스크 용량 걱정 없이 켜두면 됩니다.

[설치 및 실행 확인] 보통 /opt/oswbb 등에 설치되며, 다음 프로세스가 떠 있는지 확인하세요.

# ps -ef | grep OSWatcher

9. 결론: Solaris 성능 분석 3줄 요약

서버가 느리다고 무작정 CPU나 메모리를 증설하기 전에, 다음 3가지를 먼저 확인하세요.

1. Load Average가 높다고 무조건 CPU 문제는 아니다.
   • vmstat의 b (Blocked) 컬럼을 확인하여 I/O 대기를 체크하세요.
2. 메모리 사용률이 높아도 sr (scan rate)이 0이면 괜찮다.
   • 대부분 ZFS 캐시(ARC)가 잡고 있는 것이며, 이는 정상적인 동작입니다.
3. 장애 시점을 놓쳤다면 sar와 OSWatcher를 뒤져라.
   • 실시간 모니터링만으로는 간헐적인 병목 현상을 잡을 수 없습니다.

Solaris 11.4는 강력한 OS입니다. 모니터링 툴의 단순한 수치에 속지 말고, vmstat, mpstat, iostat, dlstat, mdb 그리고 sar와 OSWatcher로 빈틈없는 성능 분석 체계를 갖추시길 바랍니다.

Reference: Oracle Solaris 11.4 Performance Management Guide

출처: https://nop3.tistory.com/414