メソドロジと可観測性ツール

gistfile1.md

Memo: メソドロジと可観測性ツール

詳解 システム・パフォーマンスから。よくわからない箇所を書き留めるための文書。

メソドロジと分析

仕事を省略できるので性能チューニングは仕事をする場所付近で行うと効果が高い。 チューニング2.3.4やワークロードの特性の把握2.5.10参照。

方向性を定めるため目標を定めると、行動を選択するとき役立つ。定まればあとは要因を探すだけだ。 方向性とは例えば、レイテンシを犠牲にスループットを上げることがある。他の観点はリソース使用率がある。

基本的にはスレッドの状態、CPU、システムコール、I/O、ワークロードの特性、USEメソッド、ドリルダウン分析、ロック、静的チューニングを順に行う。 併せて特定のアプリケーション、プログラミング言語を対象としたテクニックを探す。

スレッド状態の分析

6種類の状態に着目し、アイドル状態以外を短くするとレイテンシは低く負荷をより処理できる。関連するツールはLinuxのものに絞る。

実行中

由来がユーザーかカーネルかを調べ、プロファイリングによりどのコードパスが時間を消費しているかを調べる。CPUプロファイリングを参照。

Tool: top。

実行可能と無名ページング

CPUやメモリが飽和している。USEメソッドでシステム全体を明らかにする。またアプリケーションへのリソース制限も調べる。

Tool: schedstat, perf sched。

遅延アカウンティング

Tool: getdelays.c, SystemTap。

スリープ

ブロックさせているリソースを調べる。システムコール、I/Oプロファイリングを参照。

Tool: pidstat -d, iotop, SystemTap, pstack (ターゲットを停止させることがある)

ロック

どのロックかとどのスレッドに保持されるか、またそれはなぜか。他のロックが原因になることがある。

CPU プロファイリング

ユーザーレベルスタックトレースを抽出し統合する。これがコードパスを示す。

多量の出力がある。現在実行中の関数を抽出したり、フレームグラムで可視化する。

システムコール

上記の6状態は以下に分かれる。

• 実行中: CPUがユーザーモードで実行している
• syscall: I/Oやロック、カーネルモードで実行しているか待機しているシステムコール中の時間
• それ以外: 実行可能かつCPU待ちや無名ページング

ここでsyscall状態について知りたいことは、どのタイプがどこで使われ、それが呼ばれた理由は何かである。

ブレークポイントトレーシングはエントリとリターンに介入する。パフォーマンスへの影響が大きくなりうる。

Tool: strace。

バッファードトレーシングは上記の問題を回避できる。Instrumentationデータはカーネル内にバッファリングできる。 perfにtraceサブコマンドがある。

可観測性ツール

ツールの持つ性質と分類やより低レベルの情報源について。

不完全さ

統計情報の元になるソフトウェアにはバグが起こり得る。同様にドキュメントにも誤りが有り得る。意味と正しさを疑うべきだ。 また、仕様が完全ではないこと、設計が適切でないこともある。そのため、既知のワークロードを用いたり異なるツールで相互チェックを要する。 すべてを検査しなくとも、仮定したことを認識しておけばよい。

ツールタイプ

つぎの分類がある。

• システム全体かプロセスごと
• カウンタかトレーシング

カウンタはカーネルが自動記録する。利用する追加コストは無視できる。

トレーシングはイベントごとにデータを集める。CPU、ストレージへのオーバヘッドがある。 プロファイリングはスナップショットをとり観察する。これはコードパスを特徴づける。

Solaris系のツールは省略する。

システム全体, カウンタ

• vmstat
• mpstat
• iostat
• netstat
• sar (SystemアクティビティReporter)

プロセス, カウンタ

• ps
• top
• pmap

システム全体, トレーシング

• tcpdump
• blktrace
• SystemTap
• perf (Linux Performance Events)

プロセス, トレーシング

• strace
• gdb

プロファイリング

• oprofile
• perf
• SystemTap
• cachegrind
• Intel VTune Amplifier XE

情報ソース

/proc, /sysはファイルシステムインタフェースを提供する。

/procには次がある。

• limits: リソース制限
• maps, smaps: マップされたメモリ
• sched, schedstat: CPUスケジューラ
• status (stat, statm): CPUとメモリの統計情報
• task: タスク単位の統計情報

システム全体に関連するファイルもある。詳細はマニュアルをみよ。

ソースの見つけ方

カーネルソースコードはこれらの出処を教えてくれる。統計やtracepointがどのように配置されるかを見る。なにか(ref.)を読み出すツールも助けになる。

そのような統計がないなら、動的トレーシングを用いるかあるいはカーネル変数をgdbなどで覗く。

インタフェースの直交性はツールの習得しやすさと（学習）効率を良くする。そのため、SolarisではDTraceへの移行が進んでいるらしい。 LinuxではSystemTapが相当する。

関連するメソドロジ

USEメソッド2.5.9: すべてのリソースについて使用率、飽和、エラーをチェックする。気づかずに性能低下を起こしていることがあるためエラーも対象。 反復対象はツールでなくシステムリソース（機能的コンポーネント）。これにより網羅性が良くなくる。

ドリルダウン分析2.5.11: 次のように絞り込む。

1. モニタリング。関連するツールSimple Network Monitoring Protocol
2. 特定。関連するツール {vm,io,mp}stat
3. 分析トレーシング、プロファイリング、ソースコード解析。関連するツールstrace perf

イベントトレーシング2.5.14: 集計により細部は失われる。個別の情報を取り出す。 Tool: tcpdump strace。

ツールメソッド2.5.8: 不完全で効率的でない。

街灯のアンチメソッド2.5.1: メソドロジの欠如により決定的問題を見つけられない。

記述が拙い。理解して書いてなさそう