안녕하세요. 서버 OS 모니터링을 공부하기 위해 ‘실무로 배우는 시스템 성능 최적화’ 책 내용을 참고하여 관심있는 내용 위주로 정리했습니다.
자원 모니터링을 통해 로그를 남겨서 분석할 때 참고사항 중,
- 주요 자원 사용률이 높을 때는 어떤 프로세스가 무슨 기능을 수행하고 있기 때문에 높게 나타난 것인지 상관관계를 분석하는 것이 중요하다. 이 상관관계를 이해하는 것이 서버 자원 측면에서 성능 개선점을 파악하는데 가장 기초적인 자료가 된다.
CPU 사용량 상세 분석
- System : 커널 모드 시스템 콜 호출에 사용된 CPU 사용량. 프로세스 제어, 장치 관리, 파일과 네트워크의 관리와 입출력 처리, 시스템 정보와 시간 관리 등에 관련된 함수. 일반적으로 System CPU 사용률은 전체 사용량 대비 30% 미만이므로 System CPU 사용률이 높게 나타난다면 시스템 콜 모니터링 도구(truss)와 스택 수집 도구(pstack/jstack)를 사용해 어떤 유형의 시스템 콜이 어느 코드에서 주로 발생하는지 확인해 적절성 여부를 판단할 필요가 있음.
- User : 시스템 콜 외 일반 함수를 실행하는데 사용된 CPU 사용량. 일반 애플리케이션 서버나 DB 서버의 경우 User CPU 사용률이 다른 부분에 비해 높게 나타나는 것은 정상적인 패턴. User CPU 사용량이 높아 개선 가능성을 검토할 때는 CPU 프로파일링 도구를 사용할 수도 있고 CPU 사용률이 높은 프로세스 내 스레드를 식별한 후 스택을 수집해서 분석할 수도 있음
- IO Wait : 프로세스나 스레드가 CPU를 할당받아 사용할 수 있는 상태가 됐으나 현재 입출력이 완료되기를 기다리고 있어 CPU를 사용할 수 없는 상태의 사용량. 일반적으로 전체 CPU의 20% 미만. IO Wait 비율이 높게 나타난다면 입출력이 과다하게 발생하는 것은 아닌지 디스크 사용률이나 서비스 시간은 적절한지 확인(netstat/iostat/sar)
- Idle : 사용하지 않는 CPU 여유율
CPU 확인
$ cat /proc/cpuinfoCPU 많이 사용하는 스레드 식별
- 프로세스가 CPU를 과점하고 있을 때 프로세스 내부의 전체 스레드에 작업량이 많을 수도 있지만 특정 스레드만이 비정상적으로 CPU를 점유하고 있는 문제일 수 있다. 이럴 경우 확인 사항,
- CPU를 많이 사용하는 프로세스 식별
- 프로세스에서 CPU를 과점하고 있는 스레드 식별
- 스택 정보와 시스템 콜 모니터링을 통해 스레드 내부 작업 내용 확인(pstack, jstack, truss)
$ top -H
top - 14:05:42 up 4:02, 1 user, load average: 0.59, 0.47, 0.46
Threads: 383 total, 2 running, 381 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.1 us, 11.2 sy, 0.0 ni, 79.1 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st
MiB Mem : 3932.0 total, 569.9 free, 858.2 used, 2504.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2819.5 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
692 root 20 0 10.8g 112712 29748 S 2.0 2.8 4:20.68 etcd
746 root 20 0 10.8g 112712 29748 S 2.0 2.8 1:39.43 etcd
1751 root 20 0 1120064 356568 76716 R 1.7 8.9 3:59.34 kube-apiserver
1 root 20 0 103996 13904 8536 S 1.0 0.3 0:31.08 systemd
9 root 20 0 0 0 0 S 1.0 0.0 1:52.66 ksoftirqd/0
# ps -eLf | grep [pid] : 스레드 정보 출력 옵션
# LWP(스레드ID), C(CPU 사용률), NLWP(프로세스 스레드 개수), TIME(누적 CPU 사용률)
$ ps -eLf | grep 692
UID PID PPID LWP C NLWP TIME
root 637 1 692 1 10 10:03 ? 00:04:21 /usr/local/bin/etcd
root 3492 1 3492 0 12 10:05 ? 00:00:00 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2db7d6b32d283ec3a941b0594a66922a9d93e09ec1ad5d612f795717b28af1a6 -address /run/containerd/containerd.sock
root 3492 1 3494 0 12 10:05 ? 00:00:04 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2db7d6b32d283ec3a941b0594a66922a9d93e09ec1ad5d612f795717b28af1a6 -address /run/containerd/containerd.sock
root 3492 1 3495 0 12 10:05 ? 00:00:02 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2db7d6b32d283ec3a941b0594a66922a9d93e09ec1ad5d612f795717b28af1a6 -address /run/containerd/containerd.sock- LWP(스레드ID)
- C(CPU 사용률)
- NLWP(프로세스 스레드 개수)
- TIME(누적 CPU 사용률) : 단, 사라진 프로세스에 대해서는 누적 CPU 사용률을 구할 수 없다. 프로그램이 프로세스 생성(fork) 방식으로 동작하면서 사용자 요청이 끝나면 프로세스가 종료되는 구조라면 ps로 특정 시점의 누적 CPU 사용률을 구해도 크게 의미가 없을 수도 있다.
CPU 많이 사용하는 모듈(코드) 식별
pstack 같은 명령으로 스택을 반복적으로 수집해서 분석하는 간단한 방법으로도 CPU를 많이 사용하는 코드를 식별할 수 있다. 스택에서 최상위에 있는 함수는 현재 수행 중인 함수다.
여기서 CPU를 거의 사용하지 않는 함수는 제외한다. 대표적인 것으로 네트워크 관련 응답 대기에 해당하는 read, recv, select, poll, connect 함수와 락 대기인 wait, lock 같은 함수, 그리고 sleep 등의 함수다.
보통 프로그램은 대기 입출력을 사용하기 때문에 문제가 없지만 비대기 입출력이나 비동기 입출력을 사용하는 경우에는 read, recv가 많이 나타난다면 함수 내에서 입출력 대기가 없으므로 이또한 CPU를 많이 사용하는 코드로 분류해야 한다.
운영체제별 CPU 프로파일링 도구
- Perf
- 리눅스 커널에 포함돼 있는 도구로 다양한 성능 측정 기법을 제공한다.
# 현재 실행 중인 프로세스의 CPU 사용 내역 확인
$ perf top
# 성능 데이터 수집한 후 report로 본 예
$ perf record -p 1234 -o java.perf.data
$ perf report -i java.perf.data2. Xperf
- 윈도우 성능 모니터링 도구
# 모니터링 가능한 Provider 확인
xperf -providersTuned 데몬을 이용한 OS 튜닝
- Tuned 는 시스템 모듈로서 시스템 사용에 대한 데이터를 모니터링 하고, 수집하여 이 데이터를 기반으로 동적으로 시스템 설정을 조절하기 위한 데몬
$ tuned-adm active
$ tuned-adm list
blog migration project
written in 2023.3.10
https://medium.com/techblog-hayleyshim/os-%EC%84%9C%EB%B2%84-os-%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-7ec6fc398bf2
'IT > OS&Middleware' 카테고리의 다른 글
| [os] 서버 OS 모니터링-Disk (0) | 2023.10.29 |
|---|---|
| [os] 서버 OS 모니터링-Memory (1) | 2023.10.29 |
| [os] eBPF (0) | 2023.10.29 |