読者です 読者をやめる 読者になる 読者になる

tom__bo’s Blog

情報系学生がプログラミングしたり、ボルダリングしたりボルダリングしたことを書くブログ。もはやダイアリー

Systems Performance 読んでいく (4章 その1)

Linux Book Performance SystemsPerformance

Systems Performance: Enterprise and Cloudを読んでいく。

前回の続き。

Solarisに関する記述は断りなく省いたりします。

4. Observability Tools

OSは歴史的にも様々なソフトウェアとハードウェアの観測ツールを提供してきた。
入門者には幅広いツール群は全て重要に思えるかもしれないが、それらの結果と現実の実装にはギャップがある。

この章では、重要な例と共に様々な計測ツールについて説明する。
特に、/proc, kstat, /sys, DTrace, System Tapに重点を置くことにする。

4.1 Tool Types

パフォーマンス監視ツールは、システム全体/プロセスごと・カウンター/トレーシングという軸で4つに分類できる

(観測ツールのタイプ例 図4.1) f:id:tom__bo:20161214160018p:plain

もちろんtopコマンドのように1つのタイプに当てはまらないものもある
また、システム全体/プロセスごと、によらずプロファイリングを基準にしているツールもある。

この後にカウンタ、トレーシング、プロファイリングのツールのまとめを示す。

4.1.1 Counters

カーネルは特定のイベントをカウントするためにcountersを用意している。
これらはたいていはunsigned integerで、何かのイベントが発生する度にインクリメントされる。

カウンターはカーネルによってデフォルトで有効化されているため、"free"と思われることがおく、コストが掛かるとすればユーザランドから読み出しをすることである(些細なこと)

この後の例はシステム全体、プロセスごとの両方の例である。

[system wide]

  • vmstat: virtual and physical memory statistics, system-wide
  • mpstat: per-CPU usage
  • iostat: per-disk I/O usage, reported from the block device interface
  • netstat: network interface statistics, TCP/IP stack statistics, and some per-connection statistics
  • sar: various statistics; can also archive them for historical reporting

これらはどれもユーザランドから実行できる。

(vmstatの簡単な例)

[per process] - ps - top - pmap

これらのツールは/procファイルシステムを読んでいることがおおい

4.1.2 Tracing

トレース用のフレームワークはCPUのオーバーヘッドになることと、保存のためのストレージを食うことから、たいていデフォルトで有効にはされていない。
このオーバーヘッドは対象の動作にも影響してしまう。

システムログを含むLoggingはデフォルトで有効化されている頻度の低いトレーシングと考えることが出来る。
ロギングはイベント発生時に出力するもので、たいてい頻度の低いエラーや警告をトリガーとしている。

以下はシステム全体・プロセスごとのトレーシングツールである。

[System-Wide]
これらのツールはカーネルのトレーシング機構を使って、システム全体のリソースを調べる

(s)はSolarisベース

  • tcpdaump
  • snoop(s)
  • blktrace
  • iosnoop(DTrace-based)
  • execsnoop(DTrace-based)
  • SystemTap
  • perf

[Per-Process]

  • strace
  • truss (s)
  • gdb
  • mdb (s)

デバッガーはイベント毎のデータを収集することができるが、対象の動作を止めて、計測を開始する必要がある。
DTrace, SystemTap, perfといったツールは1つのプロセスのみを調査するのが基本である。それでもシステム全体の観測よりは良いことが多い。

4.1.3 Profiling

プロファイリングは対象の振る舞いを、スナップショットを集めることで観測する。
CPU使用率はそのいい例で、CPUのサイクルを消費するコードパスを特定するために、プログラムカウンタやスタックトレースをプロファイリングしたりする。
プロファイリングは100, 1000Hzといった一定の間隔で行われる。

また、プロファイリングはCPUのハードウェアキャッシュミスといった、時間ベースではないイベントごとに行うものもある。
これらは、プログラムの最適化をするデベロッパーにとって重要なものとなる。

[System-Wide and Per-Process]

プロファイリングツールに関する詳細は6章CPUを参照。

4.1.4 Monitoring (sar)

モニタリングに関しては2章で紹介した。
一つのOSを監視するモニタリングツールとして最も使われているのがsarコマンドである。
sarはカウンターベースで、一定の時間ごとにシステムカウンターの値を記録している。

sarコマンドは様々な統計情報を報告する一方で、必要とする全ての値を読み出せるわけではなく、時にはミスリーディングを発生させることもある。

Linuxではsarコマンドはsysstatパッケージによって提供されている。

4.2 Observability Sources

この節は観測ツールのために統計情報を提供する様々なインタフェースやフレームワークを説明する。
これらは表4.1にまとめられている。

表4.1 f:id:tom__bo:20161214160054p:plain

システムパフォーマンスの統計情報のメインソースである/procと/sysとkstatがこの後紹介され、Delay accountingとmicrostate accountingが説明され、最後に他のソースについてまとめられる。
その後に、DTraceとSystemTapツールが紹介される。

4.2.1 /proc

/procはカーネルの統計情報へのファイルシステムインたフェーズである。
/procはプロセスIDにちなんだディレクトリを持っており、これらがカーネルデータ構造にマッピングされている。

/procは動的に生成され、ストレージデバイスに書き戻されることはない。
これらはたいてい読み込み専用で、観測ツールのための統計情報を提供している。

ファイルシステムは便利で、ユーザランドに直感的なフレームワークを提供することが出来る。
POSIXファイルシステムによって、プログラミングインタフェースからopen, read, closeといったシステムコールでアクセスすることが出来る。

(straceによってtopコマンドが/procの情報を読みだしている例)

これによって、topコマンドがプロセスごとのディレクトリに対して、statシステムコールを発行していっていることがわかる。

[Linux(Linuxのみ)]

$ ls -F /proc/(プロセスIDにちなんだ数字)

に含まれるもの

  • limits
  • maps
  • sched
  • schedstat
  • smaps
  • stat
  • statm
  • status
  • task
$ cd /proc; ls -Fd [a-z]*

に含まれているもの

  • cpuinfo
  • diskstats
  • interrupts
  • loadavg
  • net/dev
  • net/tcp
  • schedstat
  • self
  • slabinfo
  • stat
  • zoneinfo

これらはシステム全体に対するツールから呼び出される。
例えばvmstatはここを呼び出している。

これらがファイルシステムとして提供されていることは便利である一方で、オーバーヘッドを生んでいる。
カーネルは統計情報をテキストにエンコードする必要があり、ユーザはこのテキストを処理する必要がる。

4.2.2 /sys

Linuxは/sysとしてマウントしているsysfsファイルシステムを提供している。 これはkernelの統計情報をディレクトリベースで提供するためにカーネル2.6で導入されたものである。 /sysは/procと違って、常時更新されていて、さまざまなシステム統計情報が、トップレベルのディレクトリに加えられている。
そもそもはドライバの情報を提供するものだったが、様々な情報を提供するように拡張されている。

grep . /sys/devices/system/cpu/cpu0/cache/index*/size

(上記でCPUキャッシュのサイズが見れる例)

/sysファイルシステムは大量の読み取り専用のファイルを提供していると同時に書き込み用のファイルも提供している。それらに 値をセットすることで、カーネルの挙動を変化させることが出来る。

4.2.3 kstat

Solarisベースのシステムでは、Linuxのようにニセのファイルシステムを提供するのではなく、kstatフレームワークによって提供している。

(...略...)

4.2.4 Delay Accounting

CONFIG_TASK_DELAY_ACCTオプションによるLinuxシステムっエアh、以下の状態でタスクごとの時間を計測している - Scheduler latency: on-CPUにするために待っている状態 - Block I/O: 完了するためにblock I/Oを待っている状態 - Swapping: ページングを待っている状態 - Memory reclaim: メモリーリクレイムルーチンを待っている状態

技術的にはscheduler latencyの統計情報は、schedstats(前述の/proc内)にあるが、これの他のdelay accounting stateが提供されている

これらの統計情報は、ユーザレベルからtaskstatsを使うことで読むことが出来る。
ドキュメントのaccountingディレクトリはドキュメントーションになっており、getdelays.cなどのサンプルもある。

(.getdelays -dp (プロセスID)の例)

4.2.5 Microstate Accounting

Solarisベースのシステムではスレッドごと、CPUごとのmicrostate accountingがある。

(...略...)

4.2.6 Other Obsevability Sources

この他にも様々な観測源がある - CPU performance counters - perf - cpustat - Per-process tracing - ptraceシステムコール - strace - Kernel Tracing - perf - Network sniffing - /proc/net/devices - tcpdaump - Process accounting - System calls