「詳解システムパフォーマンス」を読んだ

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

少し前に、仕事でパフォーマンスの問題が発生したので、「詳解システムパフォーマンス」という分厚すぎる本を読んでいた。読みやすい本ではないが、面白い考え方が色々書いてあったので、記憶にあるいくつかを紹介する。

Known-Unknowns

ものごとは以下の3つに分類することができる。計算機のパフォーマンスの問題の例を一緒に挙げる。

  • Known-Knowns:知っていること
    • 例:CPUの使用率をチェックすべきということを知っていて、現在のCPU使用率がわかっているとき
  • Known-Unknowns:知らないことを知っていること
    • 例:スワッピングが発生しているかどうかを調べるべきということを知っているがまだ調べていないとき
  • Unknown-Unknown:知らないことを知らないこと
    • 例:カーネルのslab cacheが動的に増加していくということを知らないのでメモリ圧迫の原因がわからないとき

「詳解システムパフォーマンス」では、パフォーマンスは多く知らないほど知らないことが増える分野であり、これはUnknown-UnknownがKnown-Unknwonsになるということであると述べられていた。Known-Knownsは対処できている状態で、Known-Unknwonsは対処できていないがこれから対処できる状態であるが、Unknown-Unknownには対処のしようがない状態なので、パフォーマンスに限らず、自分が詳しくなりたいと思った領域においては、Unknown-Unknownを減るように勉強していきたい。

ちなみに、上の3つの分類が見るとUnknown-Knownsというものを考えたくなるが...これは「知っていることを知らないこと」なので無意識のうちに前提としている当たり前の知識みたいな感じか?

負荷とアーキテクチャどちらの問題か

パフォーマンスの問題が発生したとき、原因は負荷かアーキテクチャのどちらかにある。

  • アプリがシングルスレッドで動作していることが原因で、一つのCPUの使用率が100%で他のCPUがidle状態だとすると、これはアーキテクチャの問題
    • アプリを書き直すことで改善が可能
  • 全てのCPU使用率が100%の場合は、アプリの改善ではどうしようもなく、単に負荷が大きすぎるという問題
    • CPUの増設や処理の分散で解決できる

パフォーマンスを客観的な問題にするには

パフォーマンスは主観的な問題である。何らかのシステムのパフォーマンスが良いか悪いかは、以下によって左右される。

  • システムの用途
  • ユーザの期待
  • 開発者の期待

パフォーマンスを客観的な問題にするためには、例えば目標の平均応答時間を設定するなど、明確な基準を設ければ良い。

CPUバウンドな処理とIOバウンドな処理

  • CPUバウンド

    • 科学計算などCPUに負担がかかる処理
    • ほとんどの時間ユーザ空間で動く
    • スループットが大事
  • IOバウンド

    • Webサーバなど主にIOを行う処理
    • カーネルの時間を使う
    • レイテンシが大事
  • スケジューラはCPUバウンドの処理を見分けて優先度を下げ、IOバウンドの処理(レイテンシが小さいことが重要)を早く終わらせるようにする

    • プロセスがCPUバウンドかどうかは直近のCPU時間と経過時間を比較すればわかる