Day 1 - 프로세스 관리: PID부터 시그널·우선순위까지

프로세스의 신원 — PID와 PPID

• 프로그램 vs 프로세스: 프로그램은 명사(디스크에 잠자는 실행 파일), 프로세스는 동사(메모리에 올라와 CPU를 받아 도는 것). ls를 치면 셸이 새 프로세스를 만들어 그 안에서 ls를 돌린다.
• PID(Process ID): 모든 프로세스가 태어날 때 부여받는 고유 번호.
• PPID(Parent PID): 자신을 만든 부모 프로세스의 번호. 이 연결 때문에 리눅스의 모든 프로세스는 가계도(tree)를 이룬다.
• 나무의 뿌리는 PID 1번 — 전통적 init 시스템에서는 init, 현대 시스템에서는 systemd. 부팅 직후 커널이 직접 띄우는 첫 사용자 공간 프로세스이며, 모든 프로세스의 조상이다.

echo $$        # 현재 셸 자신의 PID
echo $PPID     # 현재 셸의 부모 PID
ps -p 1        # PID 1번이 무엇인지 확인 (systemd 또는 init)

PID 1번(init/systemd)은 절대 죽지 않는다. 부모가 먼저 종료된 자식(고아 프로세스)은 자동으로 1번에게 입양되어 정리된다. 이 입양 메커니즘이 시스템이 좀비로 가득 차지 않게 막는 핵심이다.

• 새 프로세스는 부모를 fork()해서 복제된 뒤 exec()로 다른 프로그램으로 갈아탄다(fork-exec 모델은 Day 2에서 자세히).
• 오늘의 요점: 자식은 부모와 PPID로 연결되며, 부모 환경(변수·작업 디렉터리 등)을 물려받는다.

직접 쳐보기: bash를 한 번 더 실행해 서브셸로 들어간 뒤 echo $$로 PID를 확인하고, echo $PPID가 바깥 셸의 PID와 같은지 비교해 본다. exit로 나오면 다시 원래 PID로 돌아온다. 프로세스 계층이 눈에 보인다.

프로세스 목록 보기 — ps의 두 얼굴

• ps(process status)는 현재 프로세스의 스냅샷을 보여준다.
• 헷갈리는 이유: 역사적으로 BSD 스타일과 UNIX 스타일 두 옵션 문법을 모두 지원한다. 실무·시험에서 압도적으로 많이 쓰는 두 조합만 익히면 된다.

ps aux                 # 전체 프로세스 + CPU/메모리 사용률
ps -ef                 # 전체 프로세스 + PPID(부모 추적에 유리)
ps -ef | grep nginx    # 특정 프로그램 프로세스만 추리기
ps aux --sort=-%cpu    # CPU 사용률 내림차순 정렬

• ps aux의 STAT(상태) 컬럼은 각 글자의 의미를 알아야 읽을 수 있다.

⚠️ 함정: ps aux에는 하이픈을 붙이지 않고, ps -ef에는 붙인다. ps -aux처럼 섞어 쓰면 일부 시스템에서 경고가 뜨거나 다르게 해석된다. "aux는 맨몸, ef는 하이픈"으로 구분한다. 그리고 Z(좀비)는 종료된 자식을 부모가 회수(wait)하지 않아 PID만 남은 상태다 — Day 2 핵심.

ps aux의 BSD 문법은 버클리 유닉스에서, ps -ef의 UNIX 문법은 AT&T 시스템 V에서 왔다. 리눅스의 procps는 둘을 모두 받아들이기 때문에 같은 정보를 두 방식으로 볼 수 있다. 시험에서는 "aux는 사용률, ef는 부모 추적"이라는 용도 차이로 출제되는 경우가 많다.

실시간 모니터링 — top과 htop

• ps가 정지 사진이라면 top은 동영상이다. 기본 3초마다 갱신되며 CPU·메모리를 많이 먹는 프로세스를 위에서부터 보여준다.

top              # 실시간 프로세스 모니터 진입

• top 화면 안에서 쓰는 단축키가 실기에 나온다.

• 상단 요약줄의 load average(1·5·15분 평균 부하)도 읽어야 한다. CPU 코어 수보다 큰 값이 지속되면 과부하 신호다.
• htop: top의 개선판. 색상·마우스·코어별 막대그래프를 제공하고, 화살표로 프로세스를 직접 골라 F9로 kill할 수 있다.
• 단 htop은 배포판 기본 설치가 아닌 경우가 많아 별도 설치(yum install htop 또는 apt install htop)가 필요하다.

top은 모든 배포판에 기본 탑재되지만 htop은 별도 설치가 필요한 외부 도구라는 점이 시험 포인트다. 둘 다 "k"로 시그널을 보내고 "r"(top)/F9(htop)로 우선순위를 바꾼다.

직접 쳐보기: top을 실행한 뒤 대문자 M을 눌러 메모리 정렬로 바꿔 보고, 1을 눌러 코어별 사용률이 펼쳐지는지 확인한다. q로 빠져나온다. 단축키가 대소문자를 구분한다는 점에 주의(P는 정렬, 소문자 p는 다른 동작).

프로세스 찾기와 가계도 — pgrep·pstree

• ps -ef | grep 조합은 흔하지만 검색용 grep 프로세스 자신까지 결과에 끼어드는 단점이 있다.
• pgrep은 이름으로 PID만 깔끔하게 뽑아준다.

pgrep sshd          # sshd 프로세스들의 PID만 출력
pgrep -l sshd       # PID + 프로세스 이름 함께
pgrep -u root cron  # root 소유의 cron 프로세스 PID
pgrep -c bash       # 조건에 맞는 프로세스 개수

• pstree는 프로세스를 부모-자식 트리 형태로 그려준다. 누가 누구를 띄웠는지 한눈에 보인다.

pstree              # 전체 프로세스 트리
pstree -p           # 각 프로세스의 PID 함께 표시
pstree -p 1         # systemd(1번) 아래 트리만

직접 쳐보기: pstree -p | head -20으로 시스템 최상단 트리를 본다. 맨 위에 systemd(1) 또는 init(1)이 있고, 그 아래로 모든 서비스가 가지처럼 뻗어 있다. PID 1번이 모든 것의 조상임을 눈으로 확인할 수 있다.

프로세스에 말 걸기 — 시그널과 kill

• 프로세스를 멈추거나 재시작시키는 유일한 통신 수단이 시그널(signal)이다.
• kill은 "죽이는" 명령이 아니라 "지정한 번호의 시그널을 보내는" 명령이다. 시그널 종류에 따라 종료·재설정·일시정지 등 동작이 달라진다.
• 핵심 시그널의 번호와 의미는 반드시 외운다.

kill 1234            # PID 1234에 기본 시그널 15(SIGTERM) 전송
kill -9 1234         # 9번(SIGKILL) 강제 종료
kill -15 1234        # 15번(SIGTERM) 정상 종료 명시
kill -1 1234         # 1번(SIGHUP) — 보통 데몬 설정 재읽기
kill -HUP 1234       # 이름으로도 지정 가능
kill -l              # 시그널 번호↔이름 전체 목록

• 기본값은 15번(SIGTERM) — kill에 옵션 없이 PID만 주면 이게 간다. "정리할 시간을 줄 테니 곱게 종료하라"는 정중한 요청이라, 프로세스가 열린 파일을 닫고 임시 파일을 지운 뒤 종료할 수 있다.
• 9번(SIGKILL)은 통보 없이 커널이 즉시 메모리에서 제거한다. 가로채거나 무시할 수 없어 확실히 죽는다.
• 대신 SIGKILL은 정리 작업을 못 하므로 임시 파일·잠금 파일이 남거나 데이터가 손상될 수 있다.

⚠️ 함정: 항상 9번부터 쓰면 안 된다. 15번(정상 종료)을 먼저 시도하고, 그래도 안 죽으면 9번(강제)을 쓰는 것이 올바른 순서다. SIGKILL(9)과 SIGSTOP(19)만이 무시·차단이 불가능한 두 시그널이라는 점도 알아 둔다.

• 이름으로 한꺼번에 죽이려면 killall(이름 기준)이나 pkill(패턴 기준)을 쓴다.

killall httpd        # httpd라는 이름의 모든 프로세스에 시그널 15
killall -9 httpd     # 강제 종료
pkill -u alice       # alice 사용자의 모든 프로세스
pkill -HUP sshd      # sshd에 HUP 전송(설정 재읽기)

kill은 PID로, killall/pkill은 이름/패턴으로 시그널을 보낸다. SIGHUP(1)은 데몬에게 "죽지 말고 설정 파일만 다시 읽어라"는 의미로 자주 쓰인다(예: kill -HUP $(pgrep -x sshd)). 그래서 1번은 "재시작 없는 리로드"의 대명사다.

SIGHUP의 H-U-P은 "Hang Up"(전화 끊기)의 약자다. 옛날 모뎀 터미널 연결이 끊기면 커널이 그 터미널에 붙은 프로세스에 SIGHUP을 보냈다. 오늘날 데몬들이 이 신호를 "설정 재읽기"로 재해석하면서, 서비스 무중단 리로드의 표준 신호가 되었다. nohup(no hang up) 명령이 바로 이 SIGHUP을 무시하게 만들어 로그아웃 후에도 프로세스를 살려두는 도구다.

우선순위 조정 — nice와 renice

• CPU가 한정된 상황에서 어떤 프로세스를 먼저 돌릴지 정하는 값이 nice 값이다.
• 이름이 "친절함(nice)"인 이유: 값이 높을수록 다른 프로세스에게 CPU를 양보하는 "착한" 프로세스가 된다.
• 범위는 -20부터 19까지, 기본값은 0.

nice -n 10 ./backup.sh     # nice 10으로 낮춰서 실행(양보)
nice -n -5 ./urgent.sh     # nice -5로 높여 실행(우선)
nice ./job.sh              # -n 생략 시 기본 +10 적용

• 이미 실행 중인 프로세스의 우선순위는 renice로 바꾼다.

renice 15 -p 1234          # PID 1234의 nice를 15로 변경
renice -n 5 -p 1234        # -n 옵션으로도 지정
renice 10 -u alice         # alice의 모든 프로세스 nice를 10으로

음수 nice(우선순위 상승)는 root만 설정할 수 있다. 일반 사용자는 자기 프로세스의 nice를 올릴(숫자를 키울) 수만 있고, 한 번 양보한 우선순위를 다시 끌어올리지 못한다. 또한 nice는 "새로 실행할 때", renice는 "이미 도는 프로세스"라는 점이 다르다. nice의 기본 적용값(-n 생략 시)은 +10이다.

nice 값과 실제 스케줄링 우선순위(PRI)는 반대 방향처럼 보이지만 연동된다. nice가 낮을수록(-20에 가까울수록) 우선순위가 높아 CPU를 더 자주 받는다. top에서 NI 컬럼이 nice 값, PR 컬럼이 커널 우선순위다.

직접 쳐보기: nice -n 19 sleep 100 &로 가장 양보하는 프로세스를 띄운 뒤 ps -o pid,ni,cmd -p $!로 NI 컬럼이 19인지 확인한다. 이어 renice 5 -p $!로 바꾸고 다시 확인하면 NI가 5로 줄어든다(일반 사용자는 올리기만 가능).

성능 분석 — 어느 자원이 병목인가

• top은 "지금 누가 CPU를 먹고 있나"는 알려주지만 "어젯밤 3시에 무슨 일이 있었나"는 답하지 못한다.
• 실시간 관찰과 과거 이력 수집은 쓰는 도구가 다르다.

sysstat과 sar — 성능 이력을 남기는 표준 도구

• sysstat 패키지가 시스템 활동을 주기적으로 수집해 파일로 남기고, sar(System Activity Reporter)가 그 이력을 다시 읽어 준다.
• 수집은 cron이 담당한다. /etc/cron.d/sysstat에 등록된 sa1이 기본 10분마다 스냅숏을 뜬다.
• sa2는 하루치 요약 리포트를 만들며, 원본은 날짜별 파일 sa01, sa02…로 쌓인다.

• sar는 옵션 한 글자로 볼 자원을 고른다.

sar -u 1 5                        # CPU를 1초 간격 5회 실시간 관찰
sar -r                            # 오늘 수집된 메모리 이력 전체
sar -n DEV 2 3                    # 네트워크 인터페이스별 2초 간격 3회
sar -f /var/log/sa/sa15           # 15일자 파일에서 과거 이력 조회
sar -u -s 03:00:00 -e 04:00:00    # 특정 시간대만 잘라 보기

sar의 가치는 -f로 과거를 되짚는 것이다. 장애가 지나간 뒤 접속해 top을 봐야 이미 정상이지만, sar 데이터가 쌓여 있으면 그 시각의 CPU·메모리·디스크·네트워크를 나란히 놓고 무엇이 먼저 튀었는지 볼 수 있다.

데비안·우분투는 sysstat을 설치만 해서는 수집이 시작되지 않는다. /etc/default/sysstat의 ENABLED를 "true"로 바꾸고 서비스를 다시 시작해야 데이터가 쌓인다.

vmstat·iostat·mpstat·pidstat — 무엇을 답해 주는가

• 패키지 소속도 시험 포인트: sar·iostat·mpstat·pidstat는 sysstat 패키지, vmstat·free·uptime은 procps(procps-ng)의 기본 도구다.

load average 읽는 법

• top·uptime 상단의 세 숫자는 1분·5분·15분 평균 부하다.

• 리눅스에서의 정의: "실행 중이거나 실행을 기다리는(R) 프로세스 + 인터럽트 불가 대기(D, 대개 디스크 I/O) 프로세스"의 평균 개수.

• 판단 기준은 CPU 코어 수다. 코어가 4개면 4.0이 "빈틈없이 꽉 찬" 상태이고 8.0이면 절반이 순서를 기다리는 과부하다. 코어 수는 nproc으로 확인한다.

• 세 숫자의 기울기를 본다. 10.0 4.0 2.0이면 부하가 급격히 오르는 중이고, 2.0 4.0 10.0이면 이미 지나간 사건이다.

• 리눅스의 load average에는 디스크 I/O 대기(D 상태)가 포함되므로 CPU가 한가해도 스토리지가 느리면 값이 치솟는다.

병목 판단 흐름 — CPU인가, I/O인가, 메모리인가

• load average가 높다는 사실만으로는 무엇을 늘려야 할지 알 수 없다. 세 갈래를 지표로 갈라낸다.

nproc                # 코어 수 — load average 해석의 기준
vmstat 1 5           # r / b / si / so / wa 를 한 화면에서 비교
iostat -x 1 3        # await·%util 로 디스크 포화 확인
pidstat -d 1 3       # I/O를 실제로 일으키는 프로세스 지목

free의 free(여유) 값이 작다고 메모리 부족이 아니다. 리눅스는 남는 메모리를 버퍼·캐시로 최대한 써 두었다가 필요하면 즉시 돌려준다. 실제 여유는 available 열로 판단하고, 진짜 부족의 증거는 스왑 in/out(si·so)이 계속 발생하는 것이다. 스왑 사용량이 높아도 유입·유출이 없으면 이미 잠든 페이지일 뿐 병목이 아니다.

직접 쳐보기: vmstat 1 10을 돌려 두고 다른 터미널에서 dd if=/dev/zero of=/tmp/t bs=1M count=1000 oflag=direct로 디스크 부하를 준 뒤 b와 wa가 함께 오르는지 본다. iostat -x 1에서 그 장치의 %util이 100%에 붙으면 "I/O bound"의 지표 조합이다. 끝나면 rm /tmp/t.

📖 용어

• PID / PPID : 프로세스 고유 번호와 그 부모의 번호. 이 둘로 프로세스 트리가 만들어진다.
• PID 1번(init/systemd) : 커널이 부팅 직후 띄우는 첫 사용자 공간 프로세스. 모든 프로세스의 조상이며 고아 프로세스를 입양한다.
• STAT 컬럼 : ps aux가 보여주는 프로세스 상태. R(실행) S(대기) D(I/O 대기) T(정지) Z(좀비).
• 좀비(Z) 프로세스 : 자식이 끝났는데 부모가 종료 상태를 회수하지 않아 PID만 남은 상태.
• 시그널(signal) : 프로세스에 말을 거는 유일한 수단. 번호로 종류를 지정한다.
• SIGTERM(15) : "정리하고 곱게 나가라"는 정상 종료 요청. kill의 기본값이며 무시할 수 있다.
• SIGKILL(9) : 커널이 즉시 메모리에서 지워버리는 강제 종료. 가로채거나 무시할 수 없다.
• SIGHUP(1) : 원래는 "전화 끊김". 지금은 데몬에게 "죽지 말고 설정만 다시 읽어라"는 리로드 신호로 쓰인다.
• nice 값 : CPU를 얼마나 양보할지 정하는 -20~19 값. 낮을수록 우선순위가 높고, 음수는 root만 설정한다.
• load average : 1·5·15분 평균 부하. 실행 대기(R) + I/O 대기(D) 프로세스 수이며 코어 수와 비교해 읽는다.
• sar : sysstat이 모아 둔 성능 이력을 되짚어 보는 도구. -f로 과거 날짜 파일을 열 수 있다.
• %iowait : CPU가 디스크 응답을 기다리며 논 비율. 높으면 I/O 병목 신호다.