☰

명령당 누적 CPU 시간 통계

tag-icon • tag-icon cpu-usage battery
명령당 누적 CPU 시간 통계

배터리로 시스템을 실행하기 때문에 누적된 CPU 시간 사용량이 매우 걱정됩니다.

오랫동안 실행되는 프로세스는 자주 실행되고 종료되는 프로세스에 비해 top에 많은 CPU 시간을 축적하므로 top의 TIME+ 열은 나에게 그다지 도움이 되지 않습니다.

오랜 시간 동안 명령의 모든 프로세스에 대한 CPU 시간을 기록하고 이를 모두 합산하여 지속적으로 표시하고 싶습니다. 나는 내 시스템에서 실제로 실행하는 모든 명령에 대해 이 작업을 수행합니다. 예를 들어:

bash            5:00:00
dbus-daemon     4:30:00
firefox          3:00:00
NetworkManager  1:20:00

으로 정리되어 있어요주문하다한 줄에 - 하나가 아님프로세스각 라인. 오른쪽 열은 명령의 모든 프로세스에 대한 CPU 시간을 합산하여 생성됩니다.

단일 프로세스의 CPU 시간만 계산하면 bash는 내가 설정한 것만큼 높지 않지만 모든 프로세스를 합치면 그만큼 높을 수 있습니다. Bash는 여러 번 실행되었으며 매번 #!/bin/bashshebang이 포함된 쉘 스크립트가 있었습니다.

답변1

이에 대한 좋은 견해는 다음을 통해 쉽게 얻을 수 있습니다.atop-p명령당(즉, 모든 호출에서) 누적 CPU(또는 리소스)를 표시하는 옵션이 있는 명령입니다 ssh.

이는 Normal 과 유사 top하지만 더 높은 간격(기본적으로 10초)으로 정보를 표시하므로 문제에 잘 맞습니다. 예를 들어, 달리기는 atop -p 60전체 분 요약을 제공하며 대부분의 경우 괜찮습니다.

답변2

powertop내 직감은 프로세스 시간을 실제로 계산하는 것보다 이것으로부터 더 많은 것을 배울 수 있다는 것입니다 . 그러나 어쨌든:

설치 bpftrace; 예제가 함께 제공됩니다 execsnoop.bt(/usr/share/bpftrace/tools에 설치될 수 있음). 각 PID의 시작 시간을 저장하고 다음과 같이 종료 시 차이를 인쇄하는 또 다른 프로브를 추가하십시오 tracepoint:syscalls:sys_enter_exit*(이것은 테스트되지 않았으며 현재 내가 가장 좋아하는 시스템에 있지 않으며 설명을 위해 노력 중입니다).

#!/usr/bin/bpftrace
tracepoint:syscalls:sys_enter_exec*
{
    @start[pid] = nsecs;
    printf("START;%-6d;", pid);
    join(args->argv);
}
tracepoint:syscalls:sys_enter_exit*
{
    $from = @start[pid];
    $until = nsecs;
    printf("STOP;%-5d;%-16d\n", pid, $until-$from);
}

실행 파일을 만들고 루트로 실행한 후 출력을 파일에 저장합니다.

bpftrace(내가 아는 한) 프로그램 이름 인쇄나 인수에 줄 바꿈 등을 방지할 수 있는 좋은 기능이 없기 때문에 출력을 구문 분석하는 것은 약간 짜증스러울 수 있습니다 . 그러나 본질적으로 START;or 줄을 먼저 구문 분석한 STOP;다음 PID를 구문 분석합니다. 줄바꿈은 포함될 수 있고 포함될 것이기 때문에 START;다음 줄이 실제로 or 로 시작하는 곳에서 끝납니다 .STOP;join(argv)

이를 통해 각 실행 파일의 실행 시간을 누적할 수 있습니다.

배터리로 시스템을 실행하기 때문에 누적된 CPU 시간 사용량이 매우 걱정됩니다.

이는 생각보다 적을 수 있습니다. 800MHz의 CPU 시간은 1600MHz의 동일한 CPU 시간보다 배터리를 덜 사용합니다. 주어진 문제에 800MHz의 시간이 절반이 필요한지, 더 많은지, 아니면 더 적은지 여부는 문제에 따라 다릅니다.

더 나쁜 점은 CPU 시간을 거의 사용하지 않도록 최적화된 프로그램이 종종 수율과 같은 작업을 수행하지만 운영 체제에 의존하여 빠르게 깨운 후에만 가능하다는 점입니다. 부하가 낮을 때는 훌륭하고 CPU 코어가 그 사이에 잠을 자도록 허용하지만, 부하가 높을 때는 갑자기 불필요한 컨텍스트 스위치를 많이 처리하게 되므로 끔찍합니다.그리고CPU가 더 적은 에너지를 사용하여 동일한 클록 주파수에서 동일한 작업을 수행할 수 있도록 하는 기능은 폐기됩니다.

그리고 특히 임베디드 사용 사례에서 인터럽트를 처리하고 기타 핵심 작업을 수행하는 데 소요되는 시간은 단순히 관찰할 수 없는 전력 소비와 상대적으로 상관관계가 있습니다.

하지만 나는 당신의 예를 좋아해요많은!

단일 프로세스의 CPU 시간만 계산하면 bash는 내가 설정한 것만큼 높지 않지만 모든 프로세스를 합치면 그만큼 높을 수 있습니다. Bash는 매번 #!/bin/bash shebang이 포함된 쉘 스크립트를 사용하여 여러 번 실행되었습니다.

예, 하지만 bash도 CPU 시간을 거의 차지하지 않습니다. 약간의 구문 분석을 수행한 다음 다른 프로세스를 호출하고 완료될 때까지 기다립니다. 매우 비효율적인 쉘 스크립트를 작성하지 않는 한, 반올림 오류가 발생할 때까지 입력을 기다리거나 명령이 완료될 때까지 기다립니다. 따라서 실제 쉘 스크립트 실행에 필요한 모든 시간은 에서 소비됩니다 bash.

⁰ 타이머 설정, poll/ selectfd 자주 변경, 소규모 네트워크 전송 시작...

1 대부분의 하위 캐시는 핫 상태입니다. 즉, 실제로 메모리 가져오기가 발생하지 않으며 분기 예측이 대부분 정확하므로 추측 실행이 가장 가능성이 높은 경우로 축소될 수 있습니다.

² 예를 들어, bash에서 긴 루프를 사용하여 대규모 수학 문제를 해결해 보세요.

³ 예를 들어,chmod script.bt; sudo ./script.bt > lifetimes.log

관련 정보