답변:
나는 -c
플래그로 strace가 내가 아는 가장 가까운 것 같아요 . -c
플래그를 사용하지 않은 경우 다음을 시도하십시오.
$ sudo strace -c -p 12345
여기서 12345는 해당 프로세스의 프로세스 ID (PID)입니다. 프로세스를 추적하면 추가 오버 헤드가 발생하므로 추적하는 동안 프로세스가 느리게 실행됩니다.
데이터를 수집하고 싶지만 오랫동안 실행 한 후에는를 눌러 Ctrl-C
데이터 수집을 중지하고 결과를 출력하십시오. 다음과 같이 생성됩니다 :
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
31.88 0.001738 145 12 futex
16.79 0.000915 11 80 tgkill
12.36 0.000674 34 20 read
9.76 0.000532 266 2 statfs
8.42 0.000459 13 35 time
4.38 0.000239 6 40 gettimeofday
3.65 0.000199 4 48 sigprocmask
2.94 0.000160 18 9 open
2.88 0.000157 12 13 stat64
1.32 0.000072 9 8 munmap
0.90 0.000049 6 8 mmap2
0.88 0.000048 3 14 7 sigreturn
0.79 0.000043 5 9 close
0.77 0.000042 4 10 rt_sigprocmask
0.64 0.000035 3 12 setitimer
0.55 0.000030 5 6 6 rt_sigsuspend
0.53 0.000029 4 8 fstat64
0.29 0.000016 8 2 setresuid32
0.13 0.000007 4 2 _llseek
0.09 0.000005 3 2 prctl
0.04 0.000002 2 1 geteuid32
------ ----------- ----------- --------- --------- ----------------
100.00 0.005451 341 13 total
보시다시피, 이는 총 호출 시간 및 각 시스템 호출에 대한 평균 호출 수를 포함하여 총 시간별로 정렬 된 응용 프로그램에서 수행 한 모든 시스템 호출에 대한 분류입니다. 다르게 정렬하려면 몇 가지 옵션이 있으므로 strace 매뉴얼 페이지를 참조하십시오.
내가 사용하려는 strace 스위치의 유형은 다음과 같습니다.
strace -ffttT -p pid -o /tmp/strace.out
이에 대한 예는 다음과 같습니다.
19:35:57.485493 mprotect(0x7f35e7472000, 16384, PROT_READ) = 0 <0.000037>
19:35:57.485599 mprotect(0x7f35e7692000, 4096, PROT_READ) = 0 <0.000030>
19:35:57.485697 mprotect(0x7f35e78b7000, 4096, PROT_READ) = 0 <0.000030>
19:35:57.485782 munmap(0x7f35e7896000, 129588) = 0 <0.000037>
19:35:57.485875 set_tid_address(0x7f35e78949d0) = 10730 <0.000029>
19:35:57.485960 set_robust_list(0x7f35e78949e0, 0x18) = 0 <0.000024>
19:35:57.486048 futex(0x7fff8f58628c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000025>
19:35:57.486131 futex(0x7fff8f58628c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f35e7894700) = -1 EAGAIN (Resource temporarily unavailable) <0.000024>
시스템 호출의 오른쪽에 한 시스템 호출에서 다른 시스템 호출로 소요되는 시간을 보여주는 시간 차이가 표시됩니다.
시스템 호출 사이의 시차를 잡을 것입니다. 따라서 시스템 호출이 다음 시스템 호출과 상당히 몇 초 차이가 나는 경우 약간의 소음이 발생합니다.
또 다른 방법은 gcore로 코어 덤프하는 것입니다. 그러나 gdb를 탐색하는 데 약간의 경험이 필요합니다.
그러나 스레드가 커널 스레드 인 경우 스레드 또는 코어 덤프 할 수 없습니다. 이 경우 더 복잡한 것을 사용해야합니다. RHEL5 커널에서는 oprofile을 사용합니다. RHEL6에서는 perf를 사용합니다. 나는 oprofile보다 perf를 선호합니다. CPU의 최대 백분율이 사용되는 시스템 호출을 보여주는 형식과 같은 그래프로 성능 데이터를 수집 할 수 있습니다.
테스트 성능을 통해 이것을 볼 수 있습니다.
38.06% swapper [kernel.kallsyms] [k] mwait_idle_with_hints ↑
29.45% swapper [kernel.kallsyms] [k] read_hpet
4.90% swapper [kernel.kallsyms] [k] acpi_os_read_port ▒
4.74% swapper [kernel.kallsyms] [k] hpet_next_event
38 %의 CPU 시간이 소비되는 커널 기능을 보여줍니다. 이제 기능을 점검하고 기능과 기능을 확인할 수 있습니다.
몇 가지 예를 보면 그리 어렵지 않습니다.