성능 마스터하기: Sysstat 도구 모음 사용 실전 가이드

현재 순간만 볼 수 있다면 성능 작업은 지저분해집니다. 서버가 지금 느린데, 10분 전에도 느렸을까요? CPU가 올라가기 전에 디스크가 백업을 시작했을까요? 문제가 크론 작업, 배포 또는 백업 기간 이후에 시작되었을까요? sysstat 도구 모음은 실시간 판독값과 비교할 수 있는 기록을 모두 제공하기 때문에 유용합니다.

주요 도구는 시스템 활동 보고서인 sar입니다. top이 너무 짧거나, 사고가 이미 지나갔거나, 문제가 저장소, 메모리 압력, 네트워크 트래픽 또는 CPU 포화 상태였음을 증상을 추측하는 대신 보여줘야 할 때 사용합니다. 특히 iostat 및 mpstat과 같은 나머지 도구 모음은 sar이 가능성 있는 병목 현상을 가리킬 때 세부 정보를 채워줍니다.

이것은 완전한 관찰 가능성을 대체하는 것이 아닙니다. 여전히 애플리케이션 메트릭, 로그, 추적 및 외부 검사가 필요합니다. 그러나 Linux 호스트에서 sysstat은 첫 번째 실용적인 질문(머신이 실제로 무엇을 하고 있었는가?)에 답하는 가장 빠른 방법 중 하나입니다.

1. Sysstat 설치 및 초기 구성

sysstat 패키지는 일반적으로 모든 주요 Linux 배포판의 표준 리포지토리에서 사용할 수 있습니다.

1.1 설치 명령어

시스템에 맞는 패키지 관리자 명령어를 사용하세요.

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# 또는 최신 시스템의 경우 dnf 사용
sudo dnf install sysstat

1.2 기록 데이터 수집 활성화

sar이 진정으로 유용하려면 기록 데이터를 수집해야 합니다. 기본적으로 설치 시 cron 작업 또는 systemd 타이머가 설정되는 경우가 많지만 확인이 중요합니다.

최신 시스템에서는 sysstat 서비스가 활성화되어 있는지 확인하세요.

sudo systemctl enable --now sysstat

구성 파일

데이터 수집 빈도는 일반적으로 /etc/default/sysstat(Debian/Ubuntu) 또는 /etc/sysconfig/sysstat(RHEL/CentOS)에 있는 구성 파일에 의해 제어됩니다. ENABLED 또는 HISTORY 설정을 찾으세요. ENABLED="true"로 설정하면 매일 데이터 수집이 보장됩니다.

팁: 기본적으로 sysstat 데이터 파일은 /var/log/sa/에 저장되며 파일 이름은 saXX(여기서 XX는 해당 월의 일)입니다. 일부 Debian 기반 시스템에서는 /var/log/sysstat/ 아래에 보고서를 노출하기도 합니다. 경로를 가정하기 전에 패키지 기본값을 확인하세요.

수집을 활성화한 후, 최소 한 번의 간격을 기다렸다가 파일이 나타나는지 확인하세요.

ls -lh /var/log/sa/

디렉토리가 비어 있으면 systemd 타이머를 확인하세요.

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

이전 시스템에서는 수집이 여전히 cron에 의해 구동될 수 있습니다. 정확한 패키징은 배포판에 따라 다르므로 다른 서버의 기억에 의존하지 말고 확인하세요.

2. 핵심 유틸리티: 시스템 활동 보고서(`sar`)

sar은 통계를 보기 위한 기본 인터페이스입니다. 실시간 데이터를 표시하거나 이전에 수집된 기록 데이터를 분석할 수 있습니다.

2.1 실시간 모니터링을 위한 기본 구문

기본 구문은 정의된 횟수만큼 지정된 간격으로 특정 메트릭을 보고하도록 설계되었습니다.

sar [옵션] [간격] [횟수]

예시: 3초마다, 10번 일반 CPU 통계를 보고하려면:

sar -u 3 10

이 명령은 사고 중에 유용합니다. 하나의 스냅샷 대신 짧은 이동 샘플을 제공하기 때문입니다. 한 줄로 조용한 순간을 포착하여 오해를 불러일으킬 수 있습니다. 30초에 걸친 10개의 샘플은 패턴이 안정적인지, 급증하는지, 아니면 이미 사라졌는지 보여줍니다.

옵션	설명
`-u`	CPU 사용률 (기본값)
`-r`	메모리 및 페이징 통계
`-d`	블록 장치 활동 (디스크 I/O)
`-n`	네트워크 통계 (예: 인터페이스 통계의 경우 `-n DEV`)
`-q`	실행 큐 및 부하 평균
`-W`	스와핑 활동 (페이징)
`-A`	모든 메트릭 (포괄적인 스냅샷에 유용)

기록 파일의 경우 형태는 동일합니다. 데이터 파일을 선택하려면 -f를 추가하고, 시간 범위를 제한하려면 -s 및 -e를 추가하는 경우가 많습니다. 이는 장애 중에 하루 종일 출력을 읽는 것은 느리고 시끄럽기 때문에 중요합니다.

3. 주요 성능 메트릭 및 실용적인 `sar` 예제

sar의 출력을 이해하려면 어떤 메트릭이 성능 상태 또는 스트레스를 나타내는지 알아야 합니다.

3.1 CPU 사용률 (`sar -u`)

CPU 사용률은 종종 병목 현상을 찾는 첫 번째 장소입니다. 특정 범주에서 높은 사용률은 워크로드의 특성을 나타냅니다.

sar -u 5 3

메트릭	설명	병목 지표
`%user`	사용자 수준 프로세스를 실행하는 데 소요된 CPU 시간.	높음은 애플리케이션/서비스 포화를 나타냅니다.
`%system`	커널/시스템 작업을 실행하는 데 소요된 CPU 시간.	높음은 집중적인 시스템 호출 또는 드라이버 문제를 암시합니다.
`%iowait`	I/O 작업(디스크/네트워크)을 기다리며 유휴 상태인 CPU 시간.	높음은 CPU 부족이 아닌 I/O 병목 현상을 나타냅니다.
`%idle`	아무것도 기다리지 않고 보낸 CPU 시간 (사용 가능).	낮음 (예: < 5%)은 CPU 포화를 암시합니다.

%iowait에 주의하세요. "CPU가 디스크로 바쁘다"로 오해되는 경우가 많습니다. 실제로는 적어도 하나의 I/O 요청이 보류 중인 동안 CPU가 유휴 상태였음을 의미합니다. 높은 값은 스토리지 지연 시간을 가리킬 수 있지만 디스크 메트릭으로 확인이 필요합니다. 예를 들어 데이터베이스 서버에서 높은 %iowait와 높은 디스크 await는 %iowait 단독보다 훨씬 강력한 신호입니다.

또 다른 유용한 CPU 보기는 실행 큐입니다.

sar -q 5 5

runq-sz는 실행을 기다리는 작업 수를 보여줍니다. 부하 평균은 높지만 runq-sz는 적당하고 %iowait가 높으면 순수한 CPU 압력보다는 차단된 I/O를 보고 있을 수 있습니다. runq-sz가 높게 유지되고 %idle이 거의 0이면 시스템에 실행 가능한 프로세스가 더 적거나, 더 빠른 코드 또는 더 많은 CPU 용량이 필요할 수 있습니다.

3.2 메모리 및 페이징 (`sar -r` 및 `sar -W`)

메모리 통계는 소비량과 시스템이 스와핑 또는 페이징에 의존하고 있는지 여부를 모두 보여줍니다.

메모리 사용률 (sar -r):

sar -r 1 5

kbavail(사용 가능한 메모리)에 집중하세요. kbmemfree는 낮지만 kbcached 및 kbbuffers가 높으면 커널의 캐싱 메커니즘에 의해 메모리가 효율적으로 사용되고 있는 것입니다.

스와핑 활동 (sar -W):

sar -W 1 5

pswpin/s(스왑인된 페이지) 및 pswpout/s(스왑아웃된 페이지)를 살펴보세요. 여기서 0이 아닌 중요한 값은 시스템이 적극적으로 스와핑하고 있음을 나타내며, 이는 메모리 압력(강력한 병목 현상)을 의미합니다.

Linux 메모리 출력은 캐시가 낭비된 메모리가 아니라는 점을 기억할 때까지 놀랍게 보일 수 있습니다. kbmemfree가 매우 적은 서버라도 kbavail이 충분하고 스왑 활동이 조용하다면 여전히 정상일 수 있습니다. 위험한 패턴은 다릅니다. 사용 가능한 메모리가 떨어지고, 스왑인 및 스왑아웃 활동이 나타나며, 애플리케이션 지연 시간이 증가합니다. 이는 프로세스가 더 이상 RAM에 맞지 않는 메모리를 건드리고 있음을 알려줍니다.

웹 서버의 경우 작업자 수를 실수로 두 배로 늘리는 배포 후에 발생할 수 있습니다. 배치 호스트의 경우 두 개의 대규모 작업이 겹칠 때 발생할 수 있습니다. sar은 어떤 프로세스가 원인인지 알려주지 않지만 타임라인을 제공합니다. 소유자를 식별하려면 ps, top, 서비스 로그 또는 cgroup 메트릭과 함께 사용하세요.

3.3 디스크 I/O 활동 (`sar -d`)

디스크 활동 모니터링은 데이터베이스 서버나 많이 사용되는 스토리지 시스템에 중요합니다.

sar -d 3 5

이 출력은 특정 장치(예: sda, vda)를 식별해야 합니다. 주요 메트릭은 다음과 같습니다.

tps: 초당 전송 수 (높은 값은 높은 I/O 요청을 나타냄).
rd_sec/s 및 wr_sec/s: 초당 읽기/쓰기 데이터 양.
%util: 장치가 요청을 처리하는 데 바빴던 시간의 백분율. 기존 블록 장치에서 %util이 100%에 가깝게 유지되면 스토리지가 포화 상태일 수 있습니다.

최신 SSD 및 가상 디스크에서 %util은 맥락이 필요합니다. 일부 장치는 병렬 I/O를 잘 처리하며, 클라우드 볼륨은 프로비저닝된 IOPS, 처리량 또는 버스트 크레딧에 의해 제한될 수 있습니다. %util을 완전한 진단이 아닌 자세히 살펴보라는 프롬프트로 취급하세요. iostat -xd, 애플리케이션 지연 시간, AWS, Azure, GCP 또는 다른 가상화 환경에 있는 경우 플랫폼 수준 스토리지 메트릭으로 확인하세요.

한 가지 실용적인 워크플로는 다음과 같습니다.

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

sar을 사용하여 나쁜 시간을 찾은 다음, 실시간 재발 중에 iostat을 사용하여 장치 수준 지연 시간을 검사하세요.

3.4 네트워크 통계 (`sar -n`)

sar은 다양한 네트워크 계층의 활동을 보고할 수 있습니다. 가장 일반적인 검사는 인터페이스 활동(DEV)입니다.

sar -n DEV 5 1

이 명령은 각 네트워크 인터페이스에 대한 rxpk/s(초당 수신 패킷) 및 txkB/s(초당 전송 킬로바이트)와 같은 메트릭을 보여줍니다. 이를 사용하여 과부하 또는 잠재적 오류가 발생한 인터페이스를 식별하세요.

오류 카운터의 경우 EDEV를 추가하세요.

sar -n EDEV 5 3

이것은 드라이버에서 지원하는 경우 수신 오류, 전송 오류, 드롭 및 충돌을 표시할 수 있습니다. 드롭은 CPU와 디스크가 정상으로 보이지만 서비스가 간헐적 시간 초과를 불평할 때 특히 유용합니다. 트래픽 급증 중에 드롭이 증가하면 NIC 큐, 커널 네트워크 설정, 컨테이너 네트워킹 또는 로드 밸런서 경로를 검사해야 할 수 있습니다.

TCP 수준 동작의 경우 다음을 시도하세요.

sar -n TCP,ETCP 5 3

재전송, 재설정 및 실패한 연결 시도는 막연한 "사이트가 느리다"는 보고를 보다 구체적인 네트워크 또는 업스트림 문제로 바꿀 수 있습니다.

4. 기록 분석 및 기준 생성

sysstat의 진정한 힘은 장기간에 걸친 시스템 활동을 분석하는 능력에 있으며, 이는 성능 기준(시스템의 정상 상태)을 수립하는 데 필수적입니다.

4.1 이전 날짜 분석

이전 날짜에 수집된 데이터를 보려면 -f 플래그를 사용하여 일일 saXX 파일의 경로를 지정하세요.

예시: 현재 월의 10일 CPU 통계를 보려면:

sar -u -f /var/log/sa/sa10

해당 날짜의 특정 시간 범위에 걸친 통계를 검토하려면 -s(시작 시간) 및 -e(종료 시간) 플래그를 추가하세요(24시간 형식 사용).

# 10일 14:00부터 16:30까지의 네트워크 통계 보기
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 기준 수립

데이터 수집: 정상적인 부하가 높은 기간과 낮은 기간 동안 sysstat을 실행하세요.
정상치 식별: 기록 데이터(sar -f)를 분석하여 평균 CPU 사용률(%user, %system), 최대 I/O 지연 시간(%util) 및 평균 메모리 사용량을 확인하세요.
임계값 정의: 자체 기준에서 지속적인 편차가 발생하면 조사 트리거로 처리하세요. 바쁜 데이터베이스 호스트와 조용한 점프 박스는 동일한 임계값을 공유해서는 안 됩니다.

기준은 실제 비즈니스 리듬과 연결될 때 더 유용합니다. 월요일 아침 배치 가져오기, 야간 백업 및 제품 출시는 모두 서로 다른 "정상" 형태를 만듭니다. 조사할 때 메모를 남기세요: "백업 01:00에 시작", "14:30에 새 릴리스", "마케팅 이메일 09:05에 발송." 이러한 메모는 나중에 기록 sar 출력을 훨씬 쉽게 해석할 수 있게 해줍니다.

5. 지원 Sysstat 도구

sar은 포괄적인 도구이지만 sysstat 모음에는 집중적이고 상세한 보고서를 제공하는 특수 유틸리티가 포함되어 있습니다.

5.1 iostat (입출력 통계)

iostat은 특히 장치 사용률에 초점을 맞춘 상세한 메트릭을 제공하며, 특히 스토리지 병목 현상을 진단할 때 유용합니다.

# 2초마다, 4번 디스크 통계 보고, 확장 통계 포함 (x)
iostat -xd 2 4

주요 iostat 메트릭:

%util: I/O 요청이 장치에 발행된 CPU 시간의 백분율 (포화의 중요한 지표).
await: 장치에 발행된 I/O 요청의 평균 대기 시간(밀리초). 높은 await는 느린 스토리지 응답성을 나타냅니다.

처리량이 높지 않은데 await가 급증하면 작은 무작위 I/O, 파일 시스템 문제, 가상 인프라의 시끄러운 이웃 또는 동기 쓰기가 많은 애플리케이션을 찾아보세요. 처리량이 높고 그에 따라 지연 시간이 증가하면 장치가 단순히 실질적인 한계에 도달했을 수 있습니다.

5.2 mpstat (멀티프로세서 통계)

CPU 스케줄링 문제 또는 코어 간 불균일한 워크로드 분배가 의심되는 경우 mpstat은 sar -u가 집계하는 것과 달리 프로세서별 사용량 통계를 제공합니다.

# 모든 CPU (A)의 사용량을 2초마다 표시
mpstat -P ALL 2 1

이는 다른 코어는 유휴 상태인 동안 단일 코어를 포화시키는 단일 스레드 애플리케이션을 식별하거나 하이퍼스레딩 효율성을 진단하는 데 매우 중요합니다.

5.3 sadf (Sysstat 데이터 내보내기)

sadf는 sar과 동일한 수집 데이터를 읽지만 스크립트와 대시보드에서 더 쉽게 사용할 수 있는 형식으로 출력할 수 있습니다.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

-d 출력은 구분된 텍스트 처리에 유용합니다. -j 출력은 JSON이 필요할 때 유용합니다. 이는 사고 검토에 증거를 첨부하거나 터미널 출력을 수동으로 복사하지 않고 두 호스트를 비교해야 할 때 편리합니다.

6. 실용적인 사고 워크스루

10:15에 시간 초과가 발생하기 시작한 API 서버를 상상해 보세요. 애플리케이션 로그는 요청이 쌓이고 있음을 보여주지만 그 이유는 설명하지 않습니다. 기록 CPU 보기부터 시작하세요.

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

%user가 높고 %idle이 낮으면 앱이 CPU 바운드일 수 있습니다. 코어별 사용량을 확인하세요.

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

하나의 코어가 고정되어 있고 다른 코어는 조용하면 단일 스레드 작업자, 핫 잠금 또는 불균일한 프로세스 분배를 의심하세요. 모든 코어가 바쁘면 요청 속도, 최근 배포 및 비용이 많이 드는 코드 경로를 살펴보세요.

CPU가 대부분 유휴 상태이지만 %iowait가 증가하면 디스크로 전환하세요.

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

비슷한 시간에 장치 사용률이 높거나 큐 깊이가 증가하면 스토리지를 가리킵니다. 데이터베이스 기반 서비스의 경우 다음 단계는 데이터베이스 로그와 느린 쿼리 데이터입니다. 파일 제공 호스트의 경우 동시에 백업, 압축 작업 또는 로그 순환이 실행되었는지 확인하세요.

CPU와 디스크가 정상으로 보이면 메모리와 네트워크를 검사하세요.

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

요점은 매번 모든 명령을 실행하는 것이 아닙니다. 요점은 증거를 따르는 것입니다. sar은 리소스 클래스 전반에 걸친 타임라인을 제공하며, 이는 일반적으로 가장 시끄러운 증상을 쫓는 것을 멈추는 데 필요한 것입니다.

간단한 운영 습관

sysstat을 배우는 가장 좋은 방법은 문제가 발생하기 전에 사용하는 것입니다. 정상 트래픽 중에 정상 서버를 확인하세요. 백업 중에 확인하세요. 배포 후에 확인하세요. 환경에 맞는 몇 가지 명령 패턴을 저장하세요.

사고가 발생하면 정상이 무엇인지 이미 알게 될 것입니다. 그것이 도구 모음의 진정한 가치입니다. sar, iostat, mpstat 및 sadf는 애플리케이션을 마술처럼 진단하지는 않지만 대화를 증거(문제가 시작된 시기, 변경된 리소스, 호스트가 실제로 압력을 받고 있었는지 여부)에 기반하도록 유지합니다.