스트레이스와 퍼프: Linux 문제 해결 치트 시트

리눅스 문제 해결을 위한 strace 및 perf

리눅스 서버가 느려지거나, 다운되거나, CPU 사용률이 급증하는데 애플리케이션 로그만으로는 원인을 파악할 수 없을 때, 두 가지 도구가 대부분의 문제를 해결해 줍니다. strace 프로세스가 커널에 무엇을 요청하는지 알려줍니다. perf 는 CPU가 어디에 시간을 소비하고 있는지 알려줍니다. 이 두 도구는 함께 "왜 멈췄는가"와 "무엇을 하고 있는가"라는 질문에 답해 주며, 이보다 더 간편하게 이 문제를 해결해 주는 도구는 없습니다.

이 글에서는 각 도구를 언제 사용해야 하는지, 설치 방법, 실제로 실행할 명령어, 그리고 가동 중인 서버에서 오버헤드를 관리 가능한 수준으로 유지하는 방법을 다룹니다.

strace와 perf 중 언제 사용해야 하는가

구분은 간단합니다. perf CPU가 바쁘고 어떤 함수가 원인인지 파악해야 할 때 사용합니다. strace 는 프로세스가 응답하지 않거나, 충돌하거나, 이상한 오류를 반환하거나, 로그로는 설명할 수 없는 방식으로 동작할 때 사용하십시오.

perf strace는 설정 가능한 주파수로 커널의 하드웨어 카운터를 샘플링하므로 오버헤드는 대개 1% 미만이며, 프로덕션 환경에서 실행해도 안전합니다. strace 는 ptrace를 통해 모든 시스템 호출을 가로채는데, 이로 인해 대상 프로세스의 속도가 10배에서 100배까지 느려질 수 있습니다. 가동 중인 시스템에서는 신중하게 사용하고, 항상 필터를 적용하여 사용하십시오.

strace 및 perf 설치

두 도구 모두 표준 저장소에 포함되어 있습니다. strace는 ptrace syscall에 의존하며, 이는 수년 동안 모든 최신 커널의 일부였습니다. perf는 perf_events 인터페이스를 사용하며, 사용 중인 커널에 맞는 패키지가 필요합니다.

Ubuntu 또는 Debian의 경우:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

RHEL, AlmaLinux 또는 Fedora의 경우:

sudo dnf install strace perf

이 $(uname -r) 비트(bit)가 중요합니다. 다른 커널 버전으로 빌드된 perf 바이너리는 혼란스러운 출력을 생성하거나 이벤트를 무음으로 누락할 수 있습니다. 다음 명령어로 확인하십시오: perf --version 설치 후 strace -V 를 사용하여 확인하십시오.

perf가 16진수 주소 대신 함수 이름을 표시하려면 디버그 심볼이 필요합니다. 관련 -dbg 또는 -debuginfo 패키지(예: libc6-dbg Debian의 경우), 그리고 GCC에서 -g GCC에서 직접 바이너리를 컴파일하십시오.

컨테이너 내부에서는 strace 가 필요합니다 --cap-add=SYS_PTRACE 와 perf Docker로 실행할 때 --cap-add=SYS_ADMIN Docker로 실행할 때 필요합니다. 이러한 제한이 없으면 도구가 버그처럼 보이는 오류를 일으킵니다.

strace를 사용한 시스템 호출 추적

실행 strace command 를 실행하면 프로세스가 시작되는 시점부터 추적됩니다. 실행 중인 프로세스에 연결하려면 strace -p PID를 사용하십시오. 멀티스레드나 포크(fork)가 발생하는 경우, 자식 프로세스를 추적하려면 -f 를 추가하여 자식 프로세스를 추적해야 하며, 그렇지 않으면 대부분의 활동을 놓치게 됩니다.

출력 행은 반환 값으로 끝납니다. -1 ENOENT 는 프로세스가 요청한 파일이 존재하지 않음을 의미합니다. -1 EACCES 는 권한 문제를 의미합니다. 이 두 가지 오류만으로도 실제 운영 환경에서 발생하는 버그의 상당 부분을 차지합니다.

가장 유용한 플래그는 -e trace=GROUP로, 출력을 지정된 시스템 호출 범주로 제한하여 불필요한 정보를 관리 가능한 수준으로 유지해 줍니다.

부하가 많은 서버에서는 strace -c -p PID 10~20초 동안 실행해 보세요. -c 플래그는 세션을 분리할 때 시스템 호출 횟수, 총 소요 시간, 오류에 대한 요약 정보를 출력합니다. 이를 통해 터미널을 과도하게 채우지 않으면서도 어떤 범주를 자세히 살펴볼 가치가 있는지 파악할 수 있습니다. 그런 다음 필터를 좁혀서 다시 세션을 연결하세요.

알아두면 좋은 다른 플래그: -T 각 호출에 소요된 시간을 기록하고, -Z 실패한 호출만 표시하며, -o file 터미널 대신 로그 파일에 기록합니다. 이는 출력이 많은 프로세스에서 훨씬 더 빠릅니다.

perf를 사용한 CPU 프로파일링

perf에는 주로 사용하는 네 가지 명령어가 있습니다.

다음 항목부터 시작하여 perf stat -p PID 를 통해 빠르게 개요를 확인하세요. 주목해야 할 수치:

• IPC(사이클당 명령어 수)가 1.0 미만: CPU가 주로 메모리 액세스 문제로 인해 대기 상태에 있습니다.
• LLC 로드 미스(LLC-load-misses)가 높음: 작업 세트가 캐시에 들어가지 않아 CPU가 RAM을 기다리고 있습니다.
• 컨텍스트 전환 횟수가 높음: 스레드가 디스크나 네트워크에서 계속 차단되는 I/O 중심 워크로드의 전형적인 현상입니다.

무언가 이상해 보이면, 다음을 확인해 보세요 perf record -F 99 -g -p PID -- sleep 30. -F 99 99Hz로 샘플링하며, 이는 핫 함수를 찾기에 충분하고 100Hz와 같은 둥근 숫자에서 커널 타이머와 동기화되는 것을 피할 수 있습니다. -g 플래그는 호출 그래프를 캡처하므로 perf report 어떤 경로를 통해 함수에 진입했는지 보여줄 수 있습니다.

' perf report'Overhead' 열은 전체 샘플 수에 대한 비율을 나타냅니다. _int_malloc 또는 memcpy 의 오버헤드가 높으면 할당 작업이 많다는 뜻입니다. 자체 함수 중 하나에서 오버헤드가 높다면, 바로 그것이 여러분이 찾던 핫스팟입니다.

함수 이름 대신 16진수 주소가 표시된다면, 바이너리가 스트립되었거나 디버그 심볼이 누락된 것입니다. 해당 -dbg 패키지를 설치하거나, 다음 옵션을 사용하여 바이너리를 다시 빌드하십시오. -g.

실제 서버에서의 실무 워크플로우

실제 운영 중인 서버에서 발생하는 사고에 대한 대응 절차는 다음과 같습니다:

1. 먼저 간단한 도구로 증상을 확인하십시오: top, vmstat, iostat. 가상 머신(VM)을 사용 중이라면 st (steal) 열을 확인하세요. 5%를 초과하면 코드가 아니라 하이퍼바이저가 병목 현상이라는 뜻입니다.
2. CPU 사용률이 높다면 perf top 를 몇 초간 실행한 후, perf record -F 99 -g -p PID -- sleep 30 문제가 있는 프로세스에 대해 실행하세요. 99Hz로 30초간 캡처하면 약 1.7MB의 데이터가 생성됩니다.
3. 프로세스가 멈춰 있거나 느리거나 오류를 반환하는 경우, strace -c -p PID 를 10초 동안 실행하고 요약 내용을 확인하십시오. 특정 시스템 호출 범주가 압도적으로 많다면 strace -e trace=GROUP -T -p PID.
4. 의심되는 시스템 호출이나 함수를 찾았다면, 연결을 끊으십시오. 두 도구 모두 프로덕션 환경에서 필요한 시간 이상으로 실행해 두지 마십시오.

두 가지 주의 사항이 있습니다. strace 출력에는 환경 변수, 파일 경로, 소켓에서 읽은 바이트 등이 포함될 수 있으므로, 팀 외부에 공유하기 전에 로그를 정제하십시오. 또한 이 작업을 정기적으로 수행할 예정이라면, 다음 단계로 bpftrace 및 더 광범위한 eBPF 툴킷을 다음 단계로 고려해 보세요. 동일한 수준의 가시성을 제공하며, 오버헤드는 1% 미만이고, 처음부터 프로덕션 환경을 위해 설계되었습니다.

심층적인 진단 접근이 중요하지만 공유 인프라를 사용할 수 없는 워크로드를 운영 중이라면, 당사의 전용 서버를 확인해 보십시오.