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

사용자/커널 공간에서 프로세스가 소비한 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와 메모리 액세스를 더 잘 활용하도록 프로그램을 최적화하는 것은 복잡한 작업이며 코드가 없으면 더 자세히 답변하는 것이 불가능합니다.

관련 정보