sar

sar 는 서버가 지난 시간에 얼마나 바빴는지 다시 보여 주는 명령입니다. 평소에 몇 분마다 자원 상태를 파일에 적어 둡니다. 나중에 그 기록을 꺼내 시각별로 찍습니다. 「어젯밤 새벽 세 시에 왜 느렸나」처럼 이미 지나간 일을 따져야 할 때 꺼내는 진단 명령입니다.

상세

sar 는 system activity report(시스템 활동 보고)를 줄인 이름입니다. 옛 유닉스에서 온 명령입니다. 리눅스에서는 sysstat 라는 도구 묶음에 들어 있습니다. CPU(Central Processing Unit, 중앙 처리 장치), 메모리, 디스크, 네트워크 인터페이스가 어떻게 쓰였는지를 한 명령으로 모두 볼 수 있습니다.

sar 가 하는 일은 둘입니다. 하나는 지금 상태를 몇 초마다 찍는 일입니다. 다른 하나는 미리 쌓아 둔 기록을 꺼내 지난 시각의 상태를 찍는 일입니다.

앞의 일은 다른 명령도 합니다. 디스크 입출력을 지금 찍는 iostat, 메모리와 CPU 를 한 줄로 찍는 vmstat 가 그렇습니다. 뒤의 일이 sar 를 따로 찾는 까닭입니다.

지금 상태를 찍는 쓰임

간격과 횟수를 주면 sar 는 iostat 처럼 지금 상태를 찍습니다. 첫 숫자가 간격(초)이고 둘째 숫자가 횟수입니다.

sar 1 3        # CPU 를 1초마다 세 번
sar -r 5 2     # 메모리를 5초마다 두 번

옵션 글자를 안 주면 CPU 를 봅니다. 무엇을 볼지 고르는 옵션은 아래 「무엇을 볼지 고르는 옵션」 소절에 모았습니다.

기록을 쌓는 수집기

sar 의 쓸모는 아무도 안 보는 동안에도 기록이 쌓인다는 데 있습니다. 기록을 쌓는 일은 sar 가 아니라 sadc 라는 수집 프로그램이 합니다. 이름은 system activity data collector(시스템 활동 자료 수집기)의 줄임입니다.

sadc 는 혼자 돌지 않습니다. 정해진 시각에 프로그램을 띄워 주는 cron 이나 systemd 타이머가 흔히 10분마다 sadc 를 깨웁니다. 깨워진 sadc 는 커널이 켜진 뒤로 계속 더해 온 숫자를 읽어 파일에 적고 끝납니다.

적는 파일은 하루에 하나입니다. 이름은 sa 뒤에 그달의 날짜 두 자리를 붙인 꼴이라, 16일 치는 sa16 입니다. 레드햇 계열 배포판은 /var/log/sa/ 에, 데비안 계열은 /var/log/sysstat/ 에 둡니다. 사람이 읽는 글이 아니라 이진 파일이라 cat 으로 열면 깨져 보입니다.

누적 숫자가 구간 평균이 되는 법

sadc 가 적는 숫자는 커널이 켜진 뒤로 쌓인 합계입니다. 「지금까지 디스크를 몇 번 읽었나」 같은 값이라 그 자체로는 바쁜 정도를 말해 주지 않습니다. sar 는 앞뒤로 적힌 두 값의 차이를 그 사이 시간으로 나눕니다. 그렇게 나온 값이 그 구간의 평균입니다.

서버가 다시 켜지면 커널은 이 합계를 0 부터 다시 셉니다. 그대로 차이를 내면 엉뚱한 값이 나옵니다. 그래서 다시 켜진 시각에는 기록에 LINUX RESTART 라는 줄이 끼어 있습니다. sar 는 이 줄을 넘어가며 차이를 내지 않습니다.

아래 그림은 수집과 읽기가 서로 다른 때 돈다는 것을 보입니다.

flowchart TD
    subgraph S1["평소 · 아무도 안 볼 때"]
        A["타이머가 10분마다 sadc 를 깨운다"] --> B["sadc 가 누적 숫자를 읽어 sa16 에 덧붙인다"]
    end
    subgraph S2["나중 · 사람이 sar 를 칠 때"]
        C["sar 가 sa16 을 읽는다"] --> D["앞뒤 값의 차이로 구간 평균을 내 표로 찍는다"]
    end
    S1 -->|"파일만 남는다"| S2

수집하는 쪽은 화면을 안 띄우고 파일만 남깁니다. 장애가 지나간 뒤에 sar 를 쳐도 장애 시각의 숫자가 남아 있는 까닭입니다.

수집이 꺼져 있는 서버

sysstat 를 깔았다고 기록이 쌓이는 것은 아닙니다. 배포판에 따라서는 수집이 꺼진 채로 깔립니다. 이런 서버에서 지난 기록을 보려 하면 기록 파일이 없다는 에러가 납니다.

데비안 계열이라면 /etc/default/sysstat 에서 수집을 켜야 합니다. 켠 뒤부터 쌓이므로 켜기 전의 일은 볼 수 없습니다. sar 는 미리 켜 둔 서버에서만 쓸모가 있는 명령입니다.

지난 기록 꺼내기

간격을 안 주고 sar 를 치면 오늘 치 기록 파일을 읽습니다. 다른 날을 보려면 -f 로 그날 파일을 고릅니다.

sar -u                      # 오늘 치
sar -u -f /var/log/sa/sa15  # 15일 치
sar -q -s 02:00:00 -e 04:00:00

마지막 줄의 -s 와 -e 는 보고 싶은 시간대의 시작과 끝입니다. 위 예는 새벽 두 시부터 네 시까지의 기록만 찍습니다.

같은 줄의 -q 는 실행 큐를 보는 옵션입니다. 실행 큐는 CPU 를 받으려고 줄 선 프로세스들의 줄입니다. 이 줄이 길면 CPU 가 모자랐다는 뜻입니다.

기록을 다른 도구로 넘기고 싶을 때는 같은 묶음의 sadf 를 씁니다. 같은 기록 파일을 CSV(Comma-Separated Values, 쉼표로 구분한 값)나 JSON(JavaScript Object Notation) 꼴로 바꿔 줍니다.

무엇을 볼지 고르는 옵션

옵션 글자 하나가 자원 하나를 고릅니다. 지금 상태를 볼 때나 지난 기록을 볼 때나 같은 글자를 씁니다.

출력에는 칸이 많습니다. 아래는 진단에서 자주 보는 칸만 하나씩 풉니다.

-q 의 첫 칸 runq-sz 는 실행 큐에 줄 선 프로세스 수입니다. 그 시각에 CPU 를 기다리던 프로세스가 몇이었나를 말합니다.

ldavg-1 은 실행 큐 길이를 지난 1분에 걸쳐 평균 낸 값입니다. 이 값을 로드 애버리지라고 합니다. 순간값보다 덜 출렁여서 추세를 보기 좋습니다.

blocked 는 디스크 응답을 기다리며 멈춘 프로세스 수입니다. runq-sz 가 CPU 를 기다린 줄이라면 blocked 는 디스크를 기다린 줄입니다.

-w 의 cswch/s 는 CPU 가 돌리던 프로세스를 다른 것으로 1초에 몇 번 바꿨나입니다. 이 바꿈이 컨텍스트 스위치입니다. 바꿀 때마다 품이 들어서, 너무 잦으면 일보다 바꾸기에 시간을 씁니다.

메모리가 모자라면 운영체제는 당장 안 쓰는 내용을 디스크의 스왑 공간으로 내보냈다가 필요할 때 들여옵니다. 이렇게 오가는 일을 스와핑이라 합니다. -W 의 pswpin/s 와 pswpout/s 가 1초에 들여오고 내보낸 양입니다. 이 값이 꾸준히 오르면 메모리가 모자라다는 신호입니다.

-B 의 majflt/s 는 필요한 내용이 메모리에 없어 디스크에서 읽어 와야 했던 횟수입니다. 이런 일을 메이저 페이지 폴트라고 합니다. 디스크를 거치므로 한 번 한 번이 느립니다.

-d 의 await 는 디스크에 요청을 낸 뒤 끝나기까지 걸린 평균 시간입니다(밀리초). 디스크가 밀리면 요청이 줄을 서므로 이 값이 늘어납니다.

-d 로 디스크를 볼 때는 -p 를 같이 붙입니다. 붙이지 않으면 장치가 dev8-0 같은 번호로 찍힙니다. 붙이면 sda 처럼 익숙한 이름으로 찍힙니다.

CPU 기록 한 장 읽기

아래는 sar -u 의 출력에서 칸 일부만 추린 모양입니다. 값은 예로 지어낸 것입니다.

          %user %system %iowait %idle
02:50:01   12.1     3.0     0.8  84.1
03:00:01   10.4     4.2    41.7  43.7
03:10:01   11.0     3.9    38.2  46.9
03:20:01   12.6     3.1     1.0  83.3
Average:   11.5     3.6    20.4  64.5

줄 맨 앞의 시각은 그 10분 구간이 끝난 시각입니다. 03:00:01 줄은 두 시 오십 분부터 세 시까지의 평균입니다. 맨 끝 Average: 줄은 위에 찍힌 줄 전부의 평균입니다.

칸은 CPU 시간을 쓰임새별로 나눈 비율(%)입니다. %user 는 프로그램 자신의 코드를 돌린 시간입니다. %system 은 커널이 일한 시간입니다. %idle 은 할 일 없이 쉰 시간입니다.

%iowait 도 쉰 시간의 한 갈래입니다. CPU 는 할 일 없이 쉬고 있었습니다. 다만 그동안 끝나지 않은 디스크 요청이 걸려 있었습니다. 그런 시간의 비율이 %iowait 입니다. 자세한 사정은 입출력 대기 편이 다룹니다.

이 출력에서 눈에 띄는 것은 %iowait 입니다. 두 시 오십 분부터 세 시 십 분 사이에만 41.7, 38.2 로 뛰었다가 다시 내려왔습니다. 다만 이 값은 쉬는 시간의 한 갈래라 이것만으로 디스크가 밀렸다고 단정하지 않습니다. 같은 시간대의 sar -d -p 를 열어 디스크 대기 시간(await 칸)이 함께 늘었는지 봅니다.

기록 간격이 감추는 것

기록 한 줄은 그 간격 동안의 평균입니다. 10분 간격이라고 해 봅시다. 1분만 CPU 가 꽉 찼고 나머지 9분은 한가했다면, 그 줄의 CPU 사용률은 10% 남짓으로 찍힙니다. sar 기록에서 평탄해 보인다고 그 시간대가 무사했다고 볼 수는 없습니다.

간격을 좁히면 덜 묻힙니다. 대신 기록 파일이 그만큼 커집니다. 수집기도 더 자주 깹니다. 짧은 순간을 잡아야 한다면 sar 기록보다 촘촘하게 모으는 모니터링 도구가 맞습니다.

진단 장면

새벽 세 시쯤 API(Application Programming Interface) 응답이 느렸다는 알림이 왔고, 아침에 확인하니 지금은 멀쩡하다고 해 봅시다. sar 로 그 시간대를 되짚는 순서는 아래와 같습니다.

flowchart TD
    A["sar -q -s 02:30:00 -e 03:30:00 · 줄이 길었나"] --> B{"runq-sz 나 blocked 가 평소보다 컸나"}
    B -->|"아니다"| C["서버 안쪽은 한가했다 · 네트워크나 바깥을 본다"]
    B -->|"runq-sz 가 컸다"| D["sar -u 로 CPU 가 꽉 찼는지 본다"]
    B -->|"blocked 가 컸다"| E["sar -d -p 로 어느 디스크가 밀렸는지 본다"]
    E --> F["sar -W 로 스와핑이 원인이었는지 본다"]

첫 갈림에서 -q 를 먼저 여는 까닭은 CPU 와 디스크 가운데 어느 쪽에 줄이 섰는지를 한 장에서 가를 수 있기 때문입니다. runq-sz 는 CPU 를 기다린 줄입니다. blocked 는 디스크를 기다린 줄입니다. 「평소보다」를 판단하려면 비교할 시간대가 있어야 합니다. 전날 같은 시각의 파일을 -f 로 열면 됩니다.

디스크가 밀린 시간대에 스와핑도 함께 늘었다면, 원인은 디스크보다 메모리 쪽일 수 있습니다. 메모리가 모자라 스왑을 오가느라 디스크가 바빠진 것입니다.

여기까지 오면 무엇이 막혔는지는 압니다. 하지만 어느 프로세스가 그랬는지는 sar 기록에 없습니다. 그건 그 시각의 로그나 배치 작업 일정에서 찾아야 합니다.

iostat · vmstat · pidstat 과 나눠 맡는 일

sar 가 다른 진단 명령과 다른 점은 시간 축입니다. 같은 서버를 보는 명령들은 아래처럼 일을 나눕니다.

iostat 와 pidstat 는 sar 와 같은 sysstat 묶음에 들어 있습니다. sar 가 있는 서버에는 대개 둘도 있다는 뜻입니다. 지금 일어나는 일은 iostat · vmstat · pidstat 로 보고, 이미 지나간 일은 sar 로 봅니다.

관련 항목

sar 가 기록하는 자원

CPU · 코어 · 메모리 · 디스크 · 네트워크 인터페이스 · 스왑 · 블록 장치

sar 칸이 재는 지표

iowait · 입출력 대기 · 로드 애버리지 · 실행 큐 · 컨텍스트 스위치 · 페이지 폴트 · 스와핑 · 사용률 · 포화 · IOPS · 처리량

sar 기록을 쌓고 내보내는 부품

sysstat · sadc · sadf · cron · systemd · systemd 타이머 · procfs · 커널

sar 와 진단을 나눠 맡는 명령

iostat · vmstat · pidstat · mpstat · top · iotop · netstat · free

sar 기록을 해석하는 방법론

USE 방법 · 성능 · 병목 · 성능 분석 · 리틀의 법칙

sar 기록보다 촘촘하게 모으는 수단

모니터링 · 시계열 · Prometheus · 메트릭 · 경보