리눅스 htop/top에 보이는 숫자들, 대충 보지 말고 제대로 읽기

htop 숫자는 그냥 UI가 아니라 커널 상태를 읽은 결과임

• htop/top에 보이는 값 대부분은 리눅스 커널이 노출한 정보를 사람이 보기 좋게 바꾼 것임

  • 예를 들어 uptime은 /proc/uptime을 읽고, load average는 /proc/loadavg를 읽음
  • 작성자는 strace uptime으로 uptime 프로그램이 실제로 어떤 파일을 여는지 확인함
  • /proc/uptime의 첫 번째 숫자는 시스템이 켜져 있던 전체 초, 두 번째 숫자는 idle 시간인데 멀티코어에서는 코어별 idle 합산이라 전체 uptime보다 커질 수 있음

• 그래서 htop을 제대로 읽으려면 /proc를 같이 이해해야 함

  • /proc/<pid>/cmdline은 프로세스를 실행한 명령을 보여줌
  • /proc/<pid>/cwd는 현재 작업 디렉터리, /proc/<pid>/exe는 실행 바이너리로 연결되는 심볼릭 링크임
  • htop, top, ps 같은 도구는 결국 이런 커널 노출 정보를 조합해서 보여주는 뷰어에 가까움

Load average는 CPU 사용률이 아님

• 많은 사람이 load average 1.0을 “CPU 100%”나 “2코어면 50%”처럼 외우는데, 이건 반만 맞음

  • load average는 실행 중이거나 실행 대기 중인 프로세스, 그리고 uninterruptible 상태의 프로세스 수를 기반으로 계산됨
  • 1분, 5분, 15분 값은 단순 구간 평균이 아니라 지수적으로 감쇠되는 이동 평균임
  • 위키피디아 기준으로 1분 load average도 최근 1분 활동을 많이 반영할 뿐, 과거 값이 완전히 사라지는 구조는 아님

• CPU bound 작업 하나를 1코어 머신에서 돌리면 load average가 1.00 근처로 올라가고 CPU는 사실상 꽉 참

  • 같은 상황에서 2코어 머신이면 load 1.00은 대략 한 코어만 바쁜 상태로 볼 수 있음
  • 하지만 D 상태 같은 I/O 대기 프로세스도 load에 들어가서, CPU는 한가한데 load만 높은 상황도 가능함
  • 그래서 순간 CPU 사용률은 mpstat 1 같은 도구로 따로 보는 게 더 정확함

프로세스는 PID 하나로 끝나지 않음

• 리눅스 커널은 프로세스를 task라고도 부르고, htop의 Tasks 표기도 여기서 나옴

  • 프로세스마다 PID가 있고, 새 프로세스가 뜰 때 보통 증가하는 ID를 받음
  • PID 1은 부팅 시 시작되는 init 또는 systemd가 차지함
  • 스레드는 htop에서 Shift+H, 커널 스레드는 Shift+K로 표시 여부를 바꿀 수 있음

• 프로세스는 부모와 자식 관계를 만들고, 이 구조가 트리로 이어짐

  • bash에서 date를 실행하면 bash가 fork로 자기 복사본을 만들고, exec로 /bin/date를 메모리에 올림
  • 부모 bash는 자식 프로세스가 끝날 때까지 wait 계열 호출로 기다림
  • htop에서 F5를 누르면 이 부모-자식 계층을 트리로 볼 수 있음

sequenceDiagram
    participant 셸
    participant 커널
    participant 자식프로세스
    participant 실행파일
    셸->>커널: fork 호출
    커널-->>자식프로세스: 셸 복사본 생성
    자식프로세스->>커널: exec 호출
    커널->>실행파일: 바이너리 로드
    셸->>커널: wait 호출
    자식프로세스-->>커널: 종료 코드 반환
    커널-->>셸: 자식 종료 상태 전달

R, S, D, Z 상태는 장애 분석의 기본 언어임

• R은 실행 중이거나 실행 대기 중인 상태임

  • CPU가 실제로 명령을 실행 중이거나, 실행할 차례를 기다리는 run queue에 있다는 뜻임
  • cat /dev/urandom > /dev/null 같은 CPU를 계속 쓰는 작업을 돌리면 R 상태와 높은 CPU 사용률을 보기 쉬움

• S는 interruptible sleep, 즉 이벤트를 기다리는 일반적인 대기 상태임

  • sleep 1000은 CPU를 쓰는 게 아니라 시간이 지나길 기다리므로 S 상태로 보임
  • SIGINT, SIGTERM 같은 signal을 보내면 깨어나거나 종료될 수 있음
  • CTRL+C는 foreground 프로세스에 SIGINT를 보내는 동작임

• D는 uninterruptible sleep이라서 운영 중에 보면 꽤 찝찝한 상태임

  • 보통 디스크나 네트워크 파일시스템 I/O를 기다릴 때 잠깐 나타남
  • signal로 깨울 수 없어서 kill -9도 바로 먹히지 않음
  • NFS가 멈췄거나 swap이 심하게 발생하는 상황에서 오래 보이면 원인 추적이 필요함

• Z는 좀비 프로세스, 이미 종료됐지만 부모가 아직 회수하지 않은 상태임

  • 메모리는 거의 안 먹고 PID 정도만 차지함
  • 짧게 생겼다 사라지는 건 정상임
  • 오래 남아 있으면 부모 프로세스가 wait 처리를 제대로 안 하는 버그일 수 있음

VIRT, RES, SHR은 전부 다른 메모리 숫자임

• VIRT는 프로세스가 가진 가상 메모리 전체라서 대개 과장돼 보임

  • 1GB를 요청만 하고 실제로 1MB만 써도 VIRT는 1GB처럼 보일 수 있음
  • mmap으로 큰 파일을 매핑만 해도 VIRT가 크게 잡힘
  • 그래서 평소 장애 판단에는 단독으로 믿기 애매한 숫자임

• RES는 실제 물리 메모리에 올라와 있는 non-swapped 메모리라 VIRT보다 현실적인 지표임

  • 다만 swap으로 빠진 메모리는 빠져 있음
  • 공유 메모리까지 포함될 수 있어 프로세스별 RES를 단순 합산하면 실제 사용량보다 커질 수 있음
  • fork 이후 Copy-on-Write 때문에 부모와 자식 RES가 각각 크게 보여도 물리 메모리는 공유될 수 있음

• SHR은 다른 프로세스와 공유될 수 있는 메모리 크기임

  • 공유 라이브러리나 공유 메모리 영역 때문에 생김
  • “이 프로세스만 독점적으로 먹는 메모리”를 알고 싶다면 RES와 SHR의 의미 차이를 같이 봐야 함
  • MEM%는 대체로 RES를 전체 RAM으로 나눈 비율임

우선순위와 niceness는 CPU 경합 때 의미가 커짐

• CPU 코어보다 실행할 작업이 많으면 커널 스케줄러가 다음에 뭘 실행할지 골라야 함

  • 사용자가 직접 커널 스케줄러를 마음대로 조종하긴 어렵지만, niceness로 힌트를 줄 수 있음
  • NI 값은 -20부터 19까지이며, -20이 높은 우선순위, 19가 낮은 우선순위임
  • 이름 때문에 헷갈리지만 “더 nice한 프로세스는 더 많이 양보한다”고 보면 됨

• PRI는 커널이 쓰는 우선순위 값이고, 일반 사용자 프로세스 영역은 보통 100-139에 매핑됨

  • 글에서는 PR = 20 + NI 관계를 통해 nice 값이 커널 우선순위에 어떻게 반영되는지 설명함
  • 실행 전에는 nice -n, 실행 중에는 renice -n -p PID로 조정할 수 있음
  • htop CPU 바의 색도 low priority thread, normal thread, kernel thread 등을 구분해서 보여줌

기술 맥락

• 이 글의 핵심 선택은 htop 화면을 외워서 설명하지 않고, 각 값이 어디서 오는지 /proc와 strace로 역추적한 거예요. 그래서 단순 사용법이 아니라 리눅스 관찰 도구들이 커널과 어떻게 연결되는지 감이 생겨요.

• load average를 CPU 사용률로 뭉개지 않은 것도 중요해요. 실무 장애에서는 CPU가 한가한데 load가 치솟는 경우가 있고, 그때 D 상태 I/O 대기나 NFS, swap 같은 쪽을 봐야 하거든요.

• 프로세스 상태 설명도 명령어와 연결돼 있어서 좋아요. R, S, D, Z를 표로 외우는 대신 sleep, kill, fork, wait, NFS mount 예제로 확인하니 운영 중에 htop을 봤을 때 바로 해석할 수 있어요.

• 메모리 지표는 특히 오해가 많아요. VIRT가 크다고 메모리 누수라고 단정하면 안 되고, RES도 공유 메모리와 Copy-on-Write 때문에 합산하면 틀릴 수 있어요. 그래서 리눅스 서버에서는 숫자 하나보다 커널이 어떤 기준으로 그 숫자를 만들었는지를 아는 게 더 중요해요.