Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 5개 있습니다.)
.NET Framework: 442. C# - 시스템의 CPU 사용량 및 프로세스(EXE)의 CPU 사용량 알아내는 방법
; https://www.sysnet.pe.kr/2/0/1684

Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법
; https://www.sysnet.pe.kr/2/0/13215

Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)
; https://www.sysnet.pe.kr/2/0/13582

Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
; https://www.sysnet.pe.kr/2/0/13583

닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API
; https://www.sysnet.pe.kr/2/0/13589




리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법

아래의 글에 보면,

Calculate the Total CPU Usage of a Process From /proc/pid/stat
; https://www.baeldung.com/linux/total-process-cpu-usage

다음과 같은 스크립트를 소개하고 있습니다.

#!/bin/bash
PID=$1
if [ -z "$PID" ]; then
    echo Usage: $0 PID
    exit 1
fi

PROCESS_STAT=($(sed -E 's/\([^)]+\)/X/' "/proc/$PID/stat"))
PROCESS_UTIME=${PROCESS_STAT[13]}
PROCESS_STIME=${PROCESS_STAT[14]}
PROCESS_STARTTIME=${PROCESS_STAT[21]}
SYSTEM_UPTIME_SEC=$(tr . ' ' </proc/uptime | awk '{print $1}')

CLK_TCK=$(getconf CLK_TCK)

let PROCESS_UTIME_SEC="$PROCESS_UTIME / $CLK_TCK"
let PROCESS_STIME_SEC="$PROCESS_STIME / $CLK_TCK"
let PROCESS_STARTTIME_SEC="$PROCESS_STARTTIME / $CLK_TCK"

let PROCESS_ELAPSED_SEC="$SYSTEM_UPTIME_SEC - $PROCESS_STARTTIME_SEC"
let PROCESS_USAGE_SEC="$PROCESS_UTIME_SEC + $PROCESS_STIME_SEC"
let PROCESS_USAGE="$PROCESS_USAGE_SEC * 100 / $PROCESS_ELAPSED_SEC"

echon TCK == ${CLK_TCK}, The PID $PID has spent ${PROCESS_UTIME_SEC}s in user mode, ${PROCESS_STIME_SEC}s in kernel mode. Total CPU usage is ${PROCESS_USAGE_SEC}s
echo The process has been running for ${PROCESS_ELAPSED_SEC}s. So, the process has used ${PROCESS_USAGE}% of CPU

그런데, 이게 좀 말이 안 됩니다. 프로세스가 구동된 시간(PROCESS_ELAPSED_SEC) 대비 CPU를 소비한 시간(PROCESS_USAGE_SEC)을 계산하고 있는데요, 그럼, 프로세스를 실행한 지 오래될수록 CPU 소비 시간이 줄어드는 계산밖에는 안 나옵니다. 그런데 달리 생각해 보면 말이 되기도 합니다. 프로세스가 실행된 이후로 시스템의 프로세스를 얼마나 소비했느냐를 알 수 있다는 것인데... 대개의 경우 별 쓸모없는 데이터에 불과합니다.

위와 같은 계산에 따르면, CPU 100%를 자주 치는 프로세스가 아닌 다음에야, 대부분의 경우 시간이 지날수록 출력 결과는 1%에 가까워지게 됩니다. 게다가 오래된 프로세스에 CPU 100%를 치는 코드를 돌려도 이미 지난 시간의 값이 크기 때문에 1%에서 2%로 가는 것조차 시간이 걸립니다. 실제로 위의 코드를 while 루프로 바꾸게 되면,

while [ -z "" ];
do
    sleep 1

    ...[생략]...
    echo The PID $PID has spent ${PROCESS_UTIME_SEC}s in user mode, ${PROCESS_STIME_SEC}s in kernel mode. Total CPU usage is ${PROCESS_USAGE_SEC}s
    echo The process has been running for ${PROCESS_ELAPSED_SEC}s. So, the process has used ${PROCESS_USAGE}% of CPU
done

화면에는 이런 식의 출력만 보게 됩니다.

The process has been running for 942s. So, the process has used 1% of CPU
TCK == 100, The PID 21702 has spent 8s in user mode, 9s in kernel mode. Total CPU usage is 17s
The process has been running for 943s. So, the process has used 1% of CPU
TCK == 100, The PID 21702 has spent 8s in user mode, 9s in kernel mode. Total CPU usage is 17s
The process has been running for 944s. So, the process has used 1% of CPU
TCK == 100, The PID 21702 has spent 8s in user mode, 9s in kernel mode. Total CPU usage is 17s
The process has been running for 945s. So, the process has used 1% of CPU
TCK == 100, The PID 21702 has spent 8s in user mode, 9s in kernel mode. Total CPU usage is 17s
The process has been running for 946s. So, the process has used 1% of CPU




그렇다면, 위의 코드를 우리가 잘 알고 있는 "작업 관리자"처럼, 혹은 "top"처럼 보고 싶다면 어떻게 해야 할까요? ^^

방법은 예전에 설명한 윈도우의 CPU 사용량과 유사합니다.

C# - 시스템의 CPU 사용량 및 프로세스(EXE)의 CPU 사용량 알아내는 방법
; https://www.sysnet.pe.kr/2/0/1684

즉, 시간 차에 따른 증가량을 CPU 사용량으로 보면 되는 건데요, 이를 위해 위의 코드에서 /proc/[pid]/stat 파일로부터 구한 user(PROCESS_UTIME), kernel(PROCESS_STIME) 시간을 1초마다 바뀐 차이를 계산하면 됩니다.

#!/bin/bash
# proc_cpu.sh

let OLD_PROCESS_TIME=0

while [ -z "" ];
do
    sleep 1
    
    PROCESS_STAT=($(sed -E 's/\([^)]+\)/X/' "/proc/$PID/stat"))
    PROCESS_UTIME=${PROCESS_STAT[13]}
    PROCESS_STIME=${PROCESS_STAT[14]}
    
    let PROCESS_TIME="$PROCESS_UTIME + $PROCESS_STIME"
    if [ $OLD_PROCESS_TIME -eq 0 ]; then
        OLD_PROCESS_TIME=$PROCESS_TIME
        continue
    fi
   
    let ELAPSED="$PROCESS_TIME - $OLD_PROCESS_TIME"
    OLD_PROCESS_TIME=$PROCESS_TIME
    
    echo $ELAPSED
done
/* 출력 결과
0
4
0
...[생략]...
*/

저 값은 CLK_TCK가 반영된 것이니 이 값을 정식으로는 다음과 같이 계산한 다음,

x = $ELAPSED / $CLK_TCK 

퍼센트로 바꾸기 위해 이렇게 계산하면,

usage = x * 100 / 1(초)

바로 저 값이 프로세스의 CPU 사용률이 됩니다. 그런데, 대개의 경우 $CLK_TCK가 100이기 때문에 $ELAPSED 자체가 백분율로 된 값으로 나옵니다.




그런데, 실제로 저렇게 구한 값을 top과 비교해 보면 좀 맞지 않습니다.

[1초마다 $ELAPSED]
0, 0, 5, 0, 0, 3, 0, 0, 4

[top에서 보이는 값]
대체로 1.0 ~ 1.3 정도의 값

도대체 무슨 차이일까요? 위의 테스트에 사용한 응용 프로그램은 CPU 사용을 약 1초마다 한 번씩 하고 있습니다. 실제로 /proc/pid/stat 파일의 값 변화를 체크해 봐도 그렇게 나옵니다.

그리고 왠지 top의 화면 변화는 약 3초로 보이는데요, 그래서 -d 옵션을 줘서 top을 1초 갱신으로 다시 실행해 보면,

linux_cpu_usage_1.png

거의 동일한 값을 보여주고 있습니다. 그러니까 결국 top은 /proc/pid/stat 값의 변화를 설정된 refresh 주기로 나눠서 "%CPU"에 보여주는 것이었습니다. 그렇기 때문에 기본 refresh 주기인 3초마다 나온 5, 3, 4의 값을 3으로 나눈 1.0 ~ 1.3 정도의 값이 나온 것입니다.

정리해 보면, 여러분들이 /proc/pid/stat을 이용해 CPU 사용량을 구하는 경우 차등 값을 사용해야 CPU 사용량을 구할 수 있습니다. 대개의 경우, 차등 값은 1초마다 구하게 될 텐데요, 그런 경우 (기본) 3초마다 평균을 보여주는 리눅스의 top 명령어와는 결과가 다를 수 있다는 점만 알아두시면 되겠습니다.




참고로, /proc/pid/stat 파일의 갱신 주기는 어떻게 될까요? 아래의 Q&A 글에 보면,

/proc/[pid]/stat refresh period
; https://stackoverflow.com/questions/31219317/proc-pid-stat-refresh-period

문서를 인용하며, OS/kernel 데이터가 바뀌는 순간에 바로 반영된다고 하니 아마도 CPU 사용량의 경우라면 이상적인 경우 시스템 타이머의 주기에 맞춰 바뀔 듯합니다. 예를 들어, CPU 100%를 소비하는 예제를 실행한 다음 위의 proc_cpu.sh을 사용하면 구하는 시간마다 값이 바뀌는 것을 볼 수 있습니다. 반면, CPU를 거의 사용하지 않으면 해당 파일도 바뀌지 않은 채로 그 시간만큼 유지됩니다.





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 10/13/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2023-03-20 10시30분
파이썬 시스템 정보 확인 방법 (CPU, MEMORY, DISK)
; https://blog.naver.com/cjinnnn/223047217336
정성태

... 31  32  33  34  35  36  37  38  [39]  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
12677정성태6/17/20219967VC++: 144. 역공학을 통한 lxssmanager.dll의 ILxssSession 사용법 분석파일 다운로드1
12676정성태6/16/20219839VC++: 143. ionescu007/lxss github repo에 공개된 lxssmanager.dll의 CLSID_LxssUserSession/IID_ILxssSession 사용법파일 다운로드1
12675정성태6/16/20217914Java: 20. maven package 명령어 결과물로 (war가 아닌) jar 생성 방법
12674정성태6/15/20218797VC++: 142. DEFINE_GUID 사용법
12673정성태6/15/20219921Java: 19. IntelliJ - 자바(Java)로 만드는 Web App을 Tomcat에서 실행하는 방법
12672정성태6/15/202111044오류 유형: 725. IntelliJ에서 Java webapp 실행 시 "Address localhost:1099 is already in use" 오류
12671정성태6/15/202117861오류 유형: 724. Tomcat 실행 시 Failed to initialize connector [Connector[HTTP/1.1-8080]] 오류
12670정성태6/13/20219273.NET Framework: 1071. DLL Surrogate를 이용한 Out-of-process COM 개체에서의 CoInitializeSecurity 문제파일 다운로드1
12669정성태6/11/20219342.NET Framework: 1070. 사용자 정의 GetHashCode 메서드 구현은 C# 9.0의 record 또는 리팩터링에 맡기세요.
12668정성태6/11/202111029.NET Framework: 1069. C# - DLL Surrogate를 이용한 Out-of-process COM 개체 제작파일 다운로드2
12667정성태6/10/20219654.NET Framework: 1068. COM+ 서버 응용 프로그램을 이용해 CoInitializeSecurity 제약 해결파일 다운로드1
12666정성태6/10/20218202.NET Framework: 1067. 별도 DLL에 포함된 타입을 STAThread Main 메서드에서 사용하는 경우 CoInitializeSecurity 자동 호출파일 다운로드1
12665정성태6/9/20219537.NET Framework: 1066. Wslhub.Sdk 사용으로 알아보는 CoInitializeSecurity 사용 제약파일 다운로드1
12664정성태6/9/20217921오류 유형: 723. COM+ PIA 참조 시 "This operation failed because the QueryInterface call on the COM component" 오류
12663정성태6/9/20219502.NET Framework: 1065. Windows Forms - 속성 창의 디자인 설정 지원: 문자열 목록 내에서 항목을 선택하는 TypeConverter 제작파일 다운로드1
12662정성태6/8/20218533.NET Framework: 1064. C# COM 개체를 PIA(Primary Interop Assembly)로써 "Embed Interop Types" 참조하는 방법파일 다운로드1
12661정성태6/4/202119252.NET Framework: 1063. C# - MQTT를 이용한 클라이언트/서버(Broker) 통신 예제 [4]파일 다운로드1
12660정성태6/3/202110307.NET Framework: 1062. Windows Forms - 폼 내에서 발생하는 마우스 이벤트를 자식 컨트롤 영역에 상관없이 수신하는 방법 [1]파일 다운로드1
12659정성태6/2/202111559Linux: 40. 우분투 설치 후 MBR 디스크 드라이브 여유 공간이 인식되지 않은 경우 - Logical Volume Management
12658정성태6/2/20218964Windows: 194. Microsoft Store에 있는 구글의 공식 Youtube App
12657정성태6/2/202110261Windows: 193. 윈도우 패키지 관리자 - winget 설치
12656정성태6/1/20218523.NET Framework: 1061. 서버 유형의 COM+에 적용할 수 없는 Server GC
12655정성태6/1/20217950오류 유형: 722. windbg/sos - savemodule - Fail to read memory
12654정성태5/31/20217971오류 유형: 721. Hyper-V - Saved 상태의 VM을 시작 시 오류 발생
12653정성태5/31/202110649.NET Framework: 1060. 닷넷 GC에 새롭게 구현되는 DPAD(Dynamic Promotion And Demotion for GC)
12652정성태5/31/20218780VS.NET IDE: 164. Visual Studio - Web Deploy로 Publish 시 암호창이 매번 뜨는 문제
... 31  32  33  34  35  36  37  38  [39]  40  41  42  43  44  45  ...