Linux에서 atop으로 부하 모니터링하기

소개

서버 운영에서 부하(Load) 모니터링은 가장 기본적이면서도 중요한 작업입니다. 부하 모니터링은 어떤 자원이 어떻게 사용되는지 파악하게 해주고, 성능 저하 원인을 찾는 데 핵심적인 단서를 제공합니다. 이 글에서는 Linux용 모니터링 도구인 atop의 설치, 주요 출력 항목 해석, 인터랙티브 사용법, 실전 체크리스트 및 문제 해결 방법을 상세히 다룹니다.

중요 용어 한 줄 정의:

• 부하(load): CPU, 메모리, 디스크, 네트워크 등 시스템 자원의 사용 상태와 그에 따른 영향도를 포괄적으로 지칭합니다.

Atop이란

atop는 명령형 대화형 모니터로, 시스템 성능 관점에서 CPU, 메모리, 디스크, 네트워크 사용량을 보여주고 각 사용량을 발생시키는 프로세스를 식별할 수 있습니다. atop은 실시간 보기 외에 주기적으로 스냅샷을 파일로 저장해 장기 분석도 가능합니다.

참고: 원문 예제는 Ubuntu 14.04에서 테스트되었습니다. 현재 배포판과 커널 버전에 따라 일부 항목(특히 프로세스별 디스크/네트워크 정보)은 동작 방식이나 가용성에 차이가 있을 수 있습니다.

설치 방법

Debian 계열(Ubuntu, Mint 등):

sudo apt-get install atop

Red Hat 계열에서는 yum 또는 dnf를 사용하세요. 또는 공식 사이트에서 소스/바이너리를 받을 수 있습니다.

설치 후 시스템에 따라 atop 데몬/서비스로 스냅샷 기록을 자동화하도록 설정할 수 있습니다(배포판별 서비스 파일 확인).

중요: 프로세스별 디스크 및 네트워크 사용량은 커널에서 “storage accounting”이 활성화되었거나 “cnt” 패치가 적용된 경우에만 프로세스 단위로 표시됩니다. 이 점은 리눅스 배포판과 커널 설정에 따라 차이가 있습니다.

atop 실행 및 기본 출력

기본 실행:

sudo atop

아래 이미지는 일반적인 atop 출력 화면 예시입니다.

화면은 크게 시스템 레벨(System level)과 프로세스 레벨(Process level)로 구분됩니다. 시스템 레벨 주요 라인들은 다음과 같습니다.

• PRC: 전체 CPU 시간(시스템/유저), 현재 프로세스/스레드 수, 좀비 프로세스 수, 생성/종료된 프로세스 카운트 등 프로세스 집계 정보.
• CPU: 시스템(sys)/유저(user)/인터럽트(irq)/유휴(idle)/디스크 대기(wait) 등 CPU 사용 비율. 멀티프로세서이면 CPU별 하위 라인이 추가로 표시됩니다.
• CPL: 런큐에 올라온 스레드 수(실행 가능 또는 디스크 I/O 대기), 컨텍스트 스위치(csw), 인터럽트(intr), 사용 가능한 CPU 수 등.
• MEM: 총 물리 메모리(tot), 자유 메모리(free), 페이지 캐시(cache), 디스크로 플러시해야 하는 캐시(dirty), 버퍼(buff), 슬랩(slab) 등 메모리 세부 항목.
• SWP: 스왑 총량(tot), 자유 스왑(free), 커밋된 가상메모리(vmcom), 커밋 상한(vmlim).
• DSK: 디스크별 바쁜 비율(busy), 읽기/쓰기 요청(read/write), 요청당 KiB(KiB/r/KiB/w), 읽기/쓰기 처리량(MBr/s, MBw/s), 평균 큐 길이(avq), 요청 지연(avio) 등.
• NET: 전송계층(TCP/UDP), IP 레이어, 인터페이스별 네트워크 통계를 각각 보여줍니다.

시스템 레벨 정보 아래에는 프로세스 레벨 정보가 이어집니다. 프로세스 레벨은 기본적으로 최근 인터벌(기본 10초) 동안 자원 사용량이 변한 프로세스들만 표시합니다. atop는 자원 사용률 임계값에 따라 색을 칠해 강조합니다(예: 임계치 초과 시 해당 라인 전체를 빨간색으로 표시).

참고: 상세 출력 항목 및 색상 기준은 man 페이지와 atop 문서를 참조하세요.

인터랙티브 명령(핫키)

atop 실행 중 키보드로 출력을 제어할 수 있습니다. 자주 쓰는 키는 다음과 같습니다:

• m: 메모리 관련 출력
• d: 디스크 관련 출력
• n: 네트워크 관련 출력
• v: 프로세스 특성(메모리, 스레드 등) 토글
• c: 프로세스의 명령줄(command line) 출력
• t: 스레드 수준 표시 토글(가능한 경우)
• P: 프로세스 정렬 기준 변경(예: CPU, MEM, DSK 등)
• q: 종료

예를 들어 c를 누르면 각 프로세스의 전체 커맨드 라인이 화면에 표시됩니다.

기록(로깅)과 재생

atop은 실시간 관찰 외에 기록을 남겨 장기 분석에 활용할 수 있습니다. 주요 옵션:

• 기록: sudo atop -w /var/log/atop.raw 600 (600초 간격으로 스냅샷을 기록)
• 재생: sudo atop -r /var/log/atop.raw (기록 파일을 재생하여 과거 시점 분석)

로그 기록은 장애 발생 시점의 상태를 되돌아보고 원인 분석(예: 순간적인 I/O 폭주나 네트워크 플러딩)을 수행할 때 유용합니다. 기록 정책(파일 회전, 보존 기간)은 디스크 용량과 보안 정책에 따라 설계하세요.

실전 활용 방법(미니 메서드)

1. 기본 점검(문제 판단 전 빠른 스크리닝): atop 실행 → 상단 라인에서 CPU/메모리/디스크/네트워크 중 어떤 자원이 붐비는지 확인.
2. 원인 좁히기: P 또는 정렬 옵션으로 CPU 높음/메모리 높음 프로세스를 상단에 배치.
3. 상세 확인: c로 명령줄 확인, v/m/d/n을 이용해 자원별 상세 출력 확인.
4. 로그 기록 확인: 문제가 일어난 시점이 있다면 기록 파일을 atop -r로 재생해 피크 시점의 스냅샷 분석.
5. 대응: 문제가 프로세스 한두 개에서 발생하면 해당 프로세스 재시작/튜닝, 전체 자원 고갈이면 스케일 아웃 또는 자원 증설을 고려.

간단한 체크리스트(우선순위):

• CPU 사용률이 높다면: 상위 프로세스 확인 → 프로세스 코드를 검사하거나 코어 바운드 여부 판단
• 메모리 사용률이 높다면: 페이지 캐시 vs 실제 사용량 구분 → OOM 발생 가능성 확인
• 디스크 I/O가 높다면: I/O 대기 시간(avio)과 avq 확인 → 디스크 IOPS/대역폭 한계 여부 확인
• 네트워크가 병목이라면: 인터페이스별 전송량 및 연결 수 확인

역할별 체크리스트

시스템 관리자:

• atop 기록 설정 및 로그 회전 정책 수립
• 커널의 storage accounting 활성화 여부 확인(프로세스별 I/O 필요 시)
• 대량 I/O/네트워크 장애 시 스토리지/네트워크 장비 로그와 교차검증

DevOps/엔지니어:

• 배포 전 리소스 요구량 프로파일링(atop 기록 사용)
• 반복적인 피크 시간대 분석으로 자동 스케일 정책 조정
• 비정상 프로세스 자동 알림 연계(모니터링 툴과 atop 결과 연동)

애플리케이션 개발자:

• CPU/메모리 소모가 큰 코드 블록 식별
• 반복적 I/O 호출이나 대량 로그 쓰기 패턴 점검
• 프로세스별 명령 인자와 로그를 atop으로 확인해 런타임 옵션 조정

실전 예제와 사례

1. 순간적인 CPU 스파이크 원인 파악

• atop을 실행한 뒤 P(정렬)를 CPU 기준으로 설정한다.
• 상위 프로세스를 확인하고 c로 프로세스 커맨드를 본다.
• 필요하면 해당 PID를 strace나 perf로 더 조사.

2. 디스크 지연(높은 avio) 대응

• D(디스크 뷰)를 눌러 디스크별 바쁜 비율과 avio를 확인.
• 특정 디스크에서만 지연이 발생하면 하드웨어/스토리지 레이어(컨트롤러, RAID, SAN)를 점검.
• 프로세스별 I/O를 보고 특정 프로세스가 과도한 쓰기를 하는지 확인.

3. 네트워크 바닥 현상

• N(네트워크 뷰)를 눌러 인터페이스별 전송량, TCP 상태를 확인.
• 외부 공격(예: DDoS)이 의심되면 연결 수, TCP 재전송율, 소스 IP 패턴을 추가 로그에서 확인.

문제 해결 팁과 예외 사례

• 프로세스별 디스크/네트워크 데이터가 보이지 않을 때: 커널에서 프로세스별 스토리지/네트워크 회계가 비활성인 경우가 많습니다. 배포판 문서와 커널 설정을 확인하세요.
• 낮은 해상도의 수집 간격: 너무 긴 인터벌로 기록하면 짧은 스파이크를 놓칠 수 있습니다. 이벤트 성격에 따라 간격을 조정하세요(예: 10초 -> 5초).
• atop만으로는 부족할 때: atop은 시스템 레벨과 프로세스 수준 스냅샷 분석에 적합하지만, 서비스 레이어 트레이싱(Apm), 로그(애플리케이션), 인프라 장비 로그와 함께 사용해야 완전한 원인분석이 가능합니다.

중요: 상세한 대응 시나리오는 운영 환경, SLA, 보안 정책에 따라 달라지므로 변경 전 영향도 분석을 수행하세요.

대안 툴 비교(요약)

• top/htop: 가볍고 빠른 프로세스 중심 뷰, 장기 기록 기능은 제한적.
• atop: 시스템+프로세스+기록(로그) 중심, 장기 분석 용이.
• sar/sysstat: 시계열 수집에 특화되어 대시보드와 연계해 추세 분석에 유리.
• iostat, vmstat, ifstat: 특정 자원(디스크/메모리/네트워크) 상세 진단에 유용.

도구 선택은 요구사항(실시간 vs 장기, 프로세스별 I/O 필요 여부, 운영 부담)에 따라 결정하세요.

의사결정 흐름(간단한 판단 트리)

flowchart TD
  A[문제 인지: 성능 저하] --> B{상단 라인 어느 자원?}
  B -->|CPU| C[atop 실행 → P로 정렬 → 상위 프로세스 확인]
  B -->|메모리| D[atop m → MEM 항목 확인 → 스왑 여부 확인]
  B -->|디스크| E[atop d → DSK avio/avq 확인 → 프로세스별 I/O 확인]
  B -->|네트워크| F[atop n → 인터페이스별 전송량 확인]
  C --> G{한/두 프로세스가 원인?}
  G -->|예| H[프로세스 재시작/튜닝/코드검토]
  G -->|아니오| I[인프라'디스크/네트워크' 조사 또는 스케일 아웃]

보안·개인정보 고려 사항

• atop 로그에는 프로세스 커맨드라인이 포함될 수 있습니다. 이 안에 민감한 인자가 포함되어 있다면 로그 수집·저장 정책에서 암호화/접근 통제를 적용하세요.
• 장기 기록 파일은 접근 권한을 최소화하고 로그 회전과 보존기간을 명확히 설정하세요.

결론 및 권장 사항

atop은 단일 도구로 시스템 레벨과 프로세스 레벨을 함께 보면서 문제의 원인을 좁힐 수 있는 실전적인 유틸리티입니다. 장기 로그 기록과 재생 기능은 운영 중 발생한 순간적 문제를 되돌아보는 데 특히 유용합니다. 다만 커널 설정에 따라 프로세스별 디스크/네트워크 지표가 표시되지 않을 수 있으므로, 필요 시 커널 회계 기능을 활성화하거나 대안 도구와 함께 사용하세요.

요약: atop 설치 → 실시간 조사(atop) → 필요시 기록(-w) → 재생(-r)로 원인 분석 → 대응(프로세스 튜닝/인프라 조정)

중요: 항상 man 페이지(man atop)를 확인해 최신 옵션과 출력 항목을 숙지하세요.

요약

• atop은 시스템 자원과 프로세스별 사용량을 통합해 보여주는 모니터링 도구입니다.
• 프로세스별 디스크/네트워크는 커널 회계 설정에 따라 가시성이 달라집니다.
• atop의 기록 기능(-w/-r)은 장애 분석에 매우 유용합니다.
• 다른 툴(top/htop/sar)과 조합해 사용하면 더 완전한 진단이 가능합니다.

참고할 만한 다음 단계:

• 운영 환경에 맞게 atop 로그 보존 정책 설계
• 자동 알림과 연동해 임계치 기반 대응 프로세스 마련
• 정기적으로 atop 로그를 보고 성능 트렌드를 문서화