システム内でコアを指す言い方が混乱を招くし、標準的じゃないね。著者は5900Xを24コアのマシンとして話してるけど、実際には12コアの上に12個のスレッドが乗っかってるって感じで説明してる。実際には、24のハイパースレッドがほぼ対称的に動いてて、12コアの上で実行されてるんだ。2つの命令パイプラインが同じ機能ユニットを共有してるってわけ。

利用率は嘘じゃなくて、ちゃんと定義された量の測定なんだ。ただ、人々はそれを元にキャパシティモデルを推測しようとするから、現実と期待がずれてくる。ハイパースレッディング（SMT）やターボ（クロックスケーリング）は、非線形を引き起こす要因の一部に過ぎない。他にも、コア間で共有されるリソースがあって、負荷が増えると「枯渇」するものがある。例えば、メモリ帯域幅やインターコネクトのキャパシティ、プロセッサキャッシュなどだ。ボトルネックはソフトウェアから来ることもあって、スピンロックみたいなものは利用率に非線形の影響を与える。さらに、ほとんどのCPU利用率の指標は、数秒から1分の長い時間で平均を取るけど、レイテンシに敏感なサーバーのパフォーマンスに本当に重要なのは、数十ミリ秒から数百ミリ秒のスケールで起こることなんだ。数秒の平均では、バースト的な動作とスムーズな動作を区別できない。後者はスケールアップのキャパシティがずっと大きい可能性がある。残念ながら、提案されたアプローチもあまり正確じゃない。なぜなら、2つの本質的に不安定な概念に依存してるからだ。>「サーバーがエラーや許容できないレイテンシを出す前に、どれだけの作業ができるかをベンチマークしよう。」この測定は非常にノイズが多い。サーバーが不安定になり始めるポイントを検出したいからだ。非常にシンプルなキューイング理論モデルを見ても、飽和に近い導関数は爆発的になるから、非決定的なノイズは極端に増幅される。>「現在サーバーがどれだけの作業をしているかを報告しよう。」「作業」の安定した定義はほとんどない。RPSなのか？リクエストコストは日中でも変動する。命令数なのか？同じく、典型的なIPCも変わる。結局、負荷テストアプローチから得られる信頼区間は、利用率測定から経験モデルを構築するのと同じくらい大きくなるかもしれない。正しく利用率を測定すればだけど。

これ、めっちゃ共感できる。昔、60%の利用率のサーバーには全く余裕がないってマネージャーに説明しようとしたら、まるで二つの頭があるかのように見られた。あの頃、この記事があったらよかったのに！

その通りだね。ハイパースレッドをパフォーマンスの2倍としてカウントするのは無理がある。実際には、うまくいけば15-30%しか効果がないし、使うとレイテンシが倍増する。コアの利用率が上がるにつれてクロックスピードの損失を考慮しないのも、非線形な理由の一つだ。デスクトップ向けの現代のソフトウェアでは、特に注意が必要だよ。OSから得られる情報を使って、少なくともこの2つの要素を含む利用率をより良く推定することは可能だと思う。キャッシュや利用可能なメモリ帯域幅を超えた場合のパフォーマンスの低下や、増加するパイプラインスタールによる既存スレッドへの影響を考慮するのは少し難しくなるけど、今よりは確実に改善できるはず。

5年前の面接でこれを説明しようとしたんだけど、相手は俺が嘘つきだと思ったみたい。

ベンチマークは基本的にアプリケーションのパフォーマンステストで、これが最も正確な表現だよ。サーバーが実行している特定のアプリを、実際のデータやシナリオでテストして、リクエストをどんどん増やしていくんだ。サーバーが落ちるまでね。それ以外の方法では、そのアプリでのサーバーの実際の最大パフォーマンスを正確に示すことはできないよ。リクエスト数やペイロードサイズ、パラメータ数など、関連するすべての変数についてこれを行って、観測モニターを設定するための複数の実世界の最大パフォーマンス指標を持つようにしよう。信頼できるパフォーマンスに近づくための一つの方法は、アプリケーションを実行する際にCPUスケジューラの制限を適用して、特定の閾値を下回るようにすることだよ。そうすれば、一定のパフォーマンスを維持できる可能性が高くなる。特にディスクI/Oが妨げられたり、システム負荷が急上昇したり、可用性が低下したりする場合、長時間100%のCPUで運用するのは避けたいよね。システム負荷のせいで2000台のサーバーが5000msのpingタイムになるのは、楽しい日ではないよ。（実際、完全に正確なビューは得られないけどね。パフォーマンスはサーバーごとに変わるから。2つの同じサーバーを異なるラックに置いて、同じアプリを実行すると、実際のパフォーマンスが異なることもある。片方のラックがもう片方より熱いかもしれないし、隠れたハードウェアやファームウェアの違いがあるかもしれないし。サーバー内でも、あるCPUが別のサーバーのより熱いコンポーネントに近いだけで、影響が出ることもあるからね。）

CPU利用率が期待通りに機能しない方法はたくさんあるよ。こんなスタイルの記事は予想してなかった。普通のLinux/Windowsの利用率を期待してたのに、何だかRAMがボトルネックになってて、CPUは実際には静かで、もしかしたらダウンクロックしてるかも。CPU利用率は、OS（WindowsでもLinuxでも）がスレッドをどれだけコアに割り当てるかだけなんだ。スレッドがmemcpyで100%ブロックされていても、それはCPU利用率としてカウントされる。------- ハイパースレッドは助けになるよ：もし1つのスレッドが本当にCPUバウンド（もっと具体的にはAVX / ベクターユニットバウンド）で、2つ目のスレッドがハイパースレッドでmemcpy / RAMバウンドなら、リソースの利用率が高くなることでマジックのようにパフォーマンスが向上するんだ。（ロード/ストアユニットはAVX計算ユニットとは別だからね）。いずれにせよ、これは常に新しい発見があるテーマで、CPU利用率が多くの人が考えるよりもはるかに直感的ではないことが分かる。新しい視点を学ぶのは面白いよね。

嘘かもしれないけど、実用的なものではあるよ。サイト信頼性エンジニアリングにちょっと関わったとき、CPU利用率（CPUバウンドタスクの）をキューイング理論と組み合わせて、大きなイベントの前にサーバーをスケールする方法を選んだんだ。%CPUの提案は「古い知恵」とは逆行していて、ずっと保守的だった。結果的に、他の方法よりもずっと低コストでうまくいったよ。言いたいのは、半端な指標だからって使うのを恐れないでほしいってこと。もしそれが一番の指標なら、十分かもしれないからね。ただ、CPU利用率に関しては、いろんな理由で生産環境では40%を超えない方がいいよ。40%なら、通常はまだ少し余裕があるから。著者のミスは、利用率が高くなるのを避けるためにキューイング理論の基本を使わなかったことだね！

ブレンダン・グレッグの「CPU利用率は間違っている」を思い出すけど、このブログはその重要なポイントを話してないね。CPU利用率はCPUが忙しいかどうかを測る指標で、待機しているかどうかも含まれてるんだよね。[0] そのブログでは、IPC（サイクルあたりの命令数）指標が、実際にはその忙しい状態の中に隠れた有用な作業を測るものだって説明してる。[0]: https://www.brendangregg.com/blog/2017-05-09/cpu-utilization...

最近はCPU使用率を単なるヒントとして捉えてる。結論じゃなくてね。レスポンスタイムやキューの長さも見て、アプリがアイドル状態に見えるときに何をしてるのかを考えるようにしてる。