強力な人々がstrace私を失望させました。どうやってこれができますか？
time fooディスプレイfooの実行には（「実際」）数秒かかりますが、ユーザースペース（「user」）とカーネル（「sys」）では無視するのに十分なCPU時間を使用します。好奇心のfoo定義は次のとおりです。
したがって、CPU命令を実行するのではなく、他のタスクを待つのにほとんどの時間を費やします。通常、どのように待っているかstrace、つまりどのシステムコールが長い間ブロックされているかを確認できます。残念ながら、このアプローチはうまくいきませんでした。
strace -ttt -T -C -w fooシステムコール、タイムスタンプ、およびシステムコールに費やされた（実際の）時間の要約を表示します。ただし、この特定のプロセスがシステムコールに費やす合計（リアルタイム）時間は無視できます。
foo実際にはjournalctl -b -u dev-hugepages.mount。ただこれを再現するために、毎回最後のパラメータを別のシステム単位に変更しなければならないということだけです。つまり、私が調査している遅延は、システムデバイスのログを最初に取得しようとしたときに発生します。 編集する：私も主な質問に答えてから気づきました。遅延の再現中にこの問題が発生する理由。
このプロセスにかかる時間は、明らかにすべてのシステムで発生しない特定の問題です。https://github.com/systemd/systemd/issues/7963
ベストアンサー1
この問題が発生する一般的な理由は、ページエラーによってプロセスがブロックされたためです。これは、メモリマッピング（別名）を介して実行されるファイルの読み取りまたは書き込みですmmap()。mmap()システムコール追跡で何かが見つかった可能性があります。
組み込みシェル/usr/bin/timeの代わりにこのプログラムを使用すると、次のことも確認できます。time
0.04user 0.10system 0:02.29elapsed 6%CPU (0avgtext+0avgdata 40464maxresident)k
73632inputs+0outputs (376major+1081minor)pagefaults 0swaps
majorページフォルトは、ファイルシステムIOが必要なエラーです。 minorページエラーははるかに重要ではありません（ただし「TLBが見つからない」かもしれません）。
inputs読んだ総ページ数のようです。現在のファイルマッピングページは常に同じサイズのようです。ほとんどの場合4096バイトですがgetconf PAGESIZE。
これは約290MBを意味し、これは毎秒100MBを超える読み取り速度であり、私のようなハードドライブの標準速度です。謎が解けました！
また、このプロセスにはフルアイドルCPUがあるとします。そうしないと、プロセスがブロックされ、他のプロセスがCPUを放棄するのを待つ可能性があります。
straceシステムコールが原因でプロセスがカーネルに入ったり出たりした場合にのみ表示されます。またはUnix信号を渡すとき。ただし、straceまったく表示されない他の種類の割り込みもあります。だからこれには
- ページエラーです。
- タイマー割り込み。これは、現在のプロセスがCPUに割り当てられているすべての時間を使い果たしたときに別のプロセスに切り替えるために使用されます。