通常レポートするアプリケーションがあります (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 とメモリをより有効活用するためにプログラムを最適化すると、複雑なタスクにアクセスしますが、コードがなければ、より詳細な回答は不可能です。