システムパフォーマンス本を読む〜第4章

About

前回に引き続き、第4章を読んでいきます。

システムパフォーマンス本を読む〜第1章 - tjinjin's blog

システムパフォーマンス本を読む〜第2章 - tjinjin's blog

システムパフォーマンス本を読む〜第3章 - tjinjin's blog

可観測性ツール

そもそも可観測性とは？

システムの現時点の内部状態を一意的に決めることができるとき，そのシステムは可観測である

可観測性の理論(かかんそくせいのりろん)とは - コトバンク

4.1 ツールのタイプ

• ツールのタイプはシステム全体<=>プロセスごと、カウンタ<=>トレーシングの2軸で大きくわけられる。
• カウンタはイベントの回数を数える
• トレーシングは分析のためにイベントごとのデータを集めてくる

name	システム全体	プロセスごと	カウンタ	トレーシング
vmstat	◯		◯
mpstat	◯		◯
iostat	◯		◯
netstat	◯		◯
sar	◯		◯
ps		◯	◯
top		◯	◯
pmap		◯	◯
tcpdump	◯			◯
snoop	◯			◯
blktrace	◯			◯
iosnoop	◯			◯
execsnoop	◯			◯
dtruss	◯			◯
DTrace	◯			◯
SystemTap	◯			◯
perf	◯			◯
strace		◯		◯
truss		◯		◯
gdb		◯		◯
mdb		◯		◯

• プロファイリングはターゲットの挙動のサンプル、スナップショットを集めてターゲットの特徴を表す。
  • oprofile
  • perf
  • DTrace
  • SystemTap
  • cachegrind
  • Intel VTune Amplifier XE
  • Oracle Solaris Studio
• プログラミング言語毎に専用のプロファイルもある
  • Goだったら pprof とか？

4.2 可観測性ツールの情報ソース

• /proc
  • カーネルによって動的に作成され、インメモリで実行されている。
  • straceでtopを見てみると、/proc 以下のいろんなファイルを見ていることがわかる
  • /proc以下のファイルリストはカーネルバージョンとCONFIGオプションによる
    • /boot/config-*でCONFIGオプションは確認できそう。
  • limits: 実際に有効になっているリソース制限。open filesとか
  • maps: マッピングされているメモリ領域。address/perms/offset/dev /inode/pathnameの順番
  • sched:様々なCPUスケジューラ統計。スレッド数もわかる
  • schedstat:CPUの実行時間、レイテンシ、タイムスライス
  • smaps:マッピングされているメモリ領域とその使用状況。アドレス毎の統計が見える？pmapでも確認可能。
  • stat: CPUとメモリの使用状況を含むプロセスのステータスと統計情報
  • statm:ページを単位とするメモリの仕様状況まとめ
  • status:人間が読める形式にしたstat,statm
  • task:タスク単位の統計ディレクトリ。中にいろいろな情報が入っている
  • 詳細はmanを見る Man page of PROC
• /sys
  • カーネル統計にディレクトリ統計を与えるもの。
• kstat
  • Solarisベースのシステムで利用できるフレームワーク。擬似ファイルシステムは用意されていないのでioctl()を使って/dev/kstatから読みだす
• 遅延アカウンティング（CONFIG_TASK_DELAY_ACCT）
  • 有効にすることでタスクごとの時間管理ができ、パフォーマンス原因をつかみやすくなる？
  • iotopを使うにはこの設定が必要
• マイクロステートアカウンティング
  • 定義済みの状態についての分解能の高い時間を記録でき、制度が高い。Solaris。

4.3 DTrace

• プログラミング言語とツールを内蔵している可観測性フレームワーク。D言語性
• プローブと呼ばれるインストルメンテーションポイント（？）を介してユーザレベル・カーネルレベルのすべてのコードを計測可能。プローブがヒットすると、イベントを実行できる（hook的な）
• DTraceなら動的に利用ができ、かつパフォーマンスへの影響がわりかし少ないので本番環境での実行ができる（カーネルバッファを利用するなど）
• 静的トレーシングはコード内にデバッグポイントみたいなものを埋め込んで実行するもの。動的トレーシングはとくに実行せず、ある関数が実行されるときに最初にDTraceを実行するようにソフトウェア割り込みを起こすことで実行しているっぽい
• プローブ
  • provider:module:function:nameの順
  • provider:プローブのコレクション。例えば、syscall,vminfo,sysinfo,profileなどなど
  • Rubyなどでも利用できるプローブがある。たぶんこれかな？ GitHub - opendtrace/toolkit: The DTrace Toolkit: A set of scripts for use with DTrace on various systems.
  • D言語の使い方系は省略。アクション、変数、集積関数などを組み合わせて使う。サンプルはこちら DTrace Tools

4.4 SystemTap

• DTraceと同じようなツール。あんぜんせいに問題があるっぽい。基本的にはDTraceを使ったほうがよい。

4.5 perf

• DTraceなどのようにリアルタイムでプログラムする機能はないが、静的・動的トレーシングやプロファイリングを実行できる。perfはデータの後処理をユーザーレベルで実行するので、パフォーマンスが問題になるケースがある。
• 詳細は6章で

4.6 可観測性の観測

• 可観測性ツールにもバグの可能性はあるので、本当に正しいのか疑う姿勢が大切
• すでにわかっているワークロードを使って可観測性の正しさを検証する方法もある。ここはコストとのトレードオフだと思う。その辺りの勘所があるかが、よいエンジニアということになりそう。

感想

ツールの使い方の基礎的な部分中心だったので、自分でいくつか試してみたが「こんな感じかー」で終わってしまっていました。これをどうパフォーマンス改善につなげていくかが今後楽しみ。また、/proc 配下についてなんとなくしかわかってない部分も理解が進んだので満足！

とにかく学んでいくのが楽しいので、どんどんやっていくぞというお気持ち！