プロセスのサンプルを収集

プロセスを選択し、ウインドウ上部のその他ボタン（3つの点）をクリックして“プロセスのサンプルを収集”を選びます。プロセスをダブルクリックし、開いたウインドウで“サンプルを収集”をクリックする方法もあります。

レポートが表示されたら、テキストファイルとして保存し、不具合の報告やサポートへの問い合わせに添付できます。

sample <PID> 5を実行すると、プロセスのサンプルを5秒間収集します。PIDの代わりにプロセス名の一部を使うこともできます。レポートは画面に出力されるとともにファイルに保存され、終了時にそのパスが表示されます。

レポートの冒頭にはヘッダがあり、プロセス名とPID、パス、親プロセス、コードの種類、macOSのバージョンが並びます。大事なのはその次、“Call graph”の下の部分です。

コールグラフには各スレッドが並びます。クリックやキー入力を処理するメインスレッドにはcom.apple.main-threadというラベルが付いています。各スレッドの下では、どの関数がどの関数を呼び出したかがわかるように、関数が字下げされています。行頭の数字は、サンプルを取ったときにその関数がスタック上にあった回数です。

• 数字がいちばん大きい行を、いちばん深い字下げまでたどっていきます。そこが、スレッドが最も多くの時間を使った場所です。
• メインスレッドのいちばん深い行がmach_msg、__psynch_cvwait、__semwait_signalのような待機の呼び出しなら、そのスレッドはほかの何かを待ってブロックされていました。
• いちばん深い行がアプリ自身の関数で、回数が大きいなら、そのスレッドは忙しく仕事をしていました。
• 終わり近くにある“Sort by top of stack”のセクションには、最も頻繁に実行されていた関数が並び、同じデータを手早くまとめたものになっています。
• 最後にある“Binary Images”の一覧には、そのプロセスに読み込まれたフレームワークとライブラリの名前が並びます。

sampleコマンドなら、アクティビティモニタより細かく制御できます。デフォルトの長さは10秒で、変更もできます。

1. “アプリケーション > ユーティリティ”からターミナルを開きます。
2. pgrep -lx SafariでプロセスIDを調べます。Safariの部分はプロセス名に置き換えてください。
3. 問題が起きている最中にsample <PID> 10 -file ~/Desktop/sample.txtを実行します。
4. デスクトップにできたファイルを開くか、不具合の報告に添付します。

サンプルは1つのプロセスのスナップショットです。どのアプリに問題があるかがすでにわかっているときに使いましょう。

• 役立つ: アプリが固まっている、1つのプロセスの“% CPU”が高いまま、再現できる特定の作業でアプリが遅い。
• あまり役立たない: Mac全体が遅く、理由がわからない。この場合は、すべてのプロセスを対象にするspindumpのほうが適しています。
• 役立たない: 問題がすでに過ぎ去っている。サンプルに現れるのは、収集している間に起きたことだけです。

サンプルだけでも役に立ちますが、短いメモを添えると、ずっと対応してもらいやすくなります。

1. アプリが回復した後ではなく、固まっているか忙しい最中にサンプルを収集します。
2. レポートは一部をコピーするのではなく、テキストファイルとして保存します。開発者には、コールグラフ全体と“Binary Images”の一覧が必要です。
3. 開いたファイルやクリックしたボタンなど、問題が起き始めたときに何をしていたかを書き留めます。
4. アプリのバージョンとmacOSのバージョンを含めます。どちらもレポートのヘッダの“Version”と“OS Version”の横にも記載されています。
5. アプリのサポートページや不具合管理システムから送ります。Apple製のアプリなら、フィードバックアシスタントからAppleに送ります。