CPU from 詳解システム・パフォーマンス
6章 CPU
avashe.iconIntelのハイパースレッディングとかAMDのSMPをハードウェアスレッドと呼ぶのはいい名称だと思う
CPUのクロックを使用するといっても命令セットを意識しないといけない場合もある
メモリアクセス待ちでストールが頻発しているCPUのクロックを上げても無意味
CPUキャッシュはストールサイクル低減にも有効
CPI(Cycles Per Instruction)が高いことはストールサイクルが多いことを意味している
data-intensiveの場合DRAM増設、メモリIOの削減、あるいはメモリの局所性を上げることで改善しうる
CPIは命令処理の効率性を示しているが、命令自体の効率性を示すわけではない
優先度の逆転
優先度の逆転なる現象が起きる
優先度が低いスレッドがリソースのロックをとり、同リソースが欲しい優先度の高いスレッドの実行が止まる現象
Solarisベースのカーネルでは逆転を防ぐために優先度の継承が実装されている とにかく早く優先度の低いスレッドが終わってほしいので、実行を待つ中で最大の優先度のスレッドのNICE値をその低いスレッドにコピーし、とっととリソースを解放させる機能を指す
Linuxでは2.618以降、優先度の継承をサポートするユーザレベルミューテックスを提供する
avashe.icon説明されてる実例いまいちピンとこない
というかこの章翻訳が適当な個所が多い
明らかにタームを知らない人が翻訳している
32bit, 64bitってなんの値
ワードサイズのこと
汎用的なレジスタのサイズになる
CPUによってはアドレス空間サイズやデータパスの幅になる
デカいほどいいわけではない
未使用空間分のオーバヘッド
フットプリントの大きさから必要なメモリIOが増える
Intel ではレジスタの数を増やし、レジスタの呼び出し方法を改善したことでオーバヘッドを帳消しにした
CPUキャッシュのレイテンシ特性を実測できるベンチマークソフトlmbenchが知られている CPUパフォーマンスカウンタ
CPUの動作をカウントできる専用のレジスタとして実装される
ストールやキャッシュアクセス、個々の命令の種類を認識し、指定できるプログラマブルなカウンタ
イベント読み書き両用レジスタに決まったフォーマットでイベントを指定し、それと組になった読みだし用レジスタから結果を読み込む
メーカー間の標準として、Processor Application Programmers Interface (PAPI)が知られている スケジューリングクラス
実行可能スレッドのふるまいを管理するしくみで、それぞれNICE値の範囲で切り替わる
LinuxではほとんどRTとCFSの2つ
RTはリアルタイム処理用
固定された高い優先度で実行され、ユーザ/カーネル両レベルでプリエンプション可能
より低いレイテンシで実行する
CFSはユーザプロセスのデフォルトで公平性重視
keyをCPU時間から得た値、valueをタスクとした赤黒木で管理
CPUをあまり消費しないタスクを優先して実行することで対話的、IO律速のワークロードを低レイテンシで実行できる
これに加え、クラスごとの追加のオプション(プロセスから呼べる)であるスケジューリングポリシーが選べる
RT
SCHED_RR
優先度ごとにキューを持ち実行されるラウンドロビン
SCHED_FIFO
ランキュー先頭のスレッドがCPUを手放すか、より高優先度のスレッドがくるまで走り続ける
CFS
SCHED_NORMAL
動的に優先度を調整する
SCHED_BATCH
スレッドがCPU律速であるという前提で動作し、他の非CPU律速なスレッドを邪魔しないよう振舞う
他にも温度やハイパースレッディングなど、CPUの様々な要因に合わせスケジュールするポリシーが研究中
NUMAのローカリティについてはスケジューリングドメインと呼ばれ、ポリシーとはまた別の分類
メソドロジー
著者的にはこの節のパフォーマンスモニタリング、USEメソッド、プロファイリング、マイクロベンチマーキング、静的分析の順で進めることを提案している
その他技術的なこと
モノリシックなカーネルでしか言えないけど、自発的コンテキストスイッチが多いかどうかでIO命令が多いかどうか大体わかる
procから直接grepしても良いけど、pidstatの-wで自発非自発が取れる pidstatはそのほかプロセスレベルで色々取れて実際便利、ログが標準出力されるtopのようにも扱える
CPUレベルで見るときはmpstatが強い
-I ALLで有名なハードウェアのエラーが取れる
コアレベルって便利か?となるけどcgroupsなどの情報を先に得てから使うと有用な状況がありそう
折に触れ予めリストを作っておくことの重要性が語られる
USEメソッドやCPUワークロード特性把握リストを自作しとけとか
予め組んどいた分析手順を脳死で流せるくらいが理想
実際障害対応時は叩き起こされ考える時間もなかったりする
sarは便利だが、全部を取れるわけでは無い
先のpidstatやmpstat -I ALL -P ALLなどは無い
一方でランキューのタスク数はsar -qでとれる
ロードアベレージは単純にはコアで走っているタスク+ランキューのタスク数なんだけど、現代ではiowaitとか色々要素はいってるっぽいのでlinuxカーネルの実装を探した方がいい
仕様を表現したドキュメントあるのかな?
calc_load