☰

사용자/커널 공간에서 프로세스가 소비한 CPU 시간 이해

tag-icon • tag-icon linux cpu x86 perf
사용자/커널 공간에서 프로세스가 소비한 CPU 시간 이해

일반적으로 보고하는 애플리케이션이 있습니다( time명령 보고서).

real 1.59
user 1.42
sys 4.73

그러나 공유 라이브러리를 로드하고 실행하면 시간이 상당히 길어집니다( time명령 보고서).

real 28.51
user 106.22
sys 5.23

공유 라이브러리 작업으로 인해 실행 시 일정 수준의 증가(예상대로 CentOS 및 Ubuntu에서 2~4배 보고됨)가 예상되는 반면, Fedora 24에서 보고된 위의 타이밍은 너무 높습니다.

나는 다음과 같이 보고된 것을 사용하려고 시도했습니다 perf.

     255352.948615      task-clock:u (msec)       #    3.895 CPUs utilized
                 0      context-switches:u        #    0.000 K/sec
                 0      cpu-migrations:u          #    0.000 K/sec
            18,127      page-faults:u             #    0.071 K/sec
   664,852,184,198      cycles:u                  #    2.604 GHz                      (50.03%)
    19,323,811,463      stalled-cycles-frontend:u #    2.91% frontend cycles idle     (50.02%)
   578,178,881,331      stalled-cycles-backend:u  #   86.96% backend cycles idle      (50.02%)
   110,595,196,687      instructions:u            #    0.17  insn per cycle
                                                  #    5.23  stalled cycles per insn  (50.00%)
    28,361,633,658      branches:u                #  111.068 M/sec                    (50.01%)
       777,249,031      branch-misses:u           #    2.74% of all branches          (50.01%)

      65.564158710 seconds time elapsed

이는 CPU가 오랜 시간 동안 유휴 상태임을 나타내는 것으로 보입니다. 하지만 코드에서 그런 일이 발생하는 위치를 찾으려고 노력 중입니다(내 애플리케이션과 문제의 공유 라이브러리 모두의 전체 소스 코드에 액세스할 수 있습니다). 또한 perf report함수/시스템 호출에 소요된 시간을 백분율로 보고하는 것도 보았습니다 . 그러나 나는 그 이유를 이해할 수 있도록 더 미세한 수준, 즉 해당 기능의 어떤 줄에 관심이 있습니다.

내 애플리케이션/공유 라이브러리에 대한 많은 정보를 제공하지 않았기 때문에 구체적인 조언을 제공하는 것이 쉽지 않다는 점에 감사드립니다. 나는 CPU가 코드에서 대부분의 시간을 보내는 곳(또는 유휴 상태)을 파악하기 위해 제안/도구/아이디어만 찾고 있습니다.

glibc 2.23이 설치된 Fedora 24 Linux/x86_64입니다(제 응용 프로그램과 공유 라이브러리는 모두 gcc 6.1.1 및 glibc 2.23으로 컴파일되었습니다).

답변1

이는 CPU가 오랜 시간 동안 유휴 상태임을 나타내는 것으로 보입니다.

예. 즉, 항상 87%입니다. 그러나 이는 프로세서가 다른 작업 및 프로세스에서 작동하지 않는다는 의미는 아닙니다.

   664,852,184,198      cycles:u                  #    2.604 GHz                      (50.03%)
    19,323,811,463      stalled-cycles-frontend:u #    2.91% frontend cycles idle     (50.02%)
   578,178,881,331      stalled-cycles-backend:u  #   86.96% backend cycles idle      (50.02%)
   110,595,196,687      instructions:u            #    0.17  insn per cycle

CPU와 메모리를 더 잘 활용하도록 프로그램을 최적화하는 것은 복잡한 작업이며 코드가 없으면 더 자세히 답변하는 것이 불가능합니다.

관련 정보