社内で行ったシステムパフォーマンス勉強会の第4回（誤字修正版)

1. システムパフォーマンス
勉強会
#4
SRA 産業第1事業部
鈴木真吾

2. 注意
• このスライドは勉強会後に SlideShare にアップロードする予
定です
• メーリングリストで告知予定

3. 今回の内容
詳解システム・パフォーマンス 5 章
アプリケーションのパフォーマンス分析
• 5章 アプリケーション
• 基礎
• パフォーマンス向上のためのテクニック
• プログラミング言語
• メソドロジと分析

4. ■ 基礎
まず初めに確認すること
• 機能
• アプリケーションの役割を確認する：データベースサーバ？ウェブサー
バー？
• オペレーション
• アプリケーションの処理する要求は何か
• CPU モード
• ユーザレベルかカーネルレベルか
• 構成・設定
• 設定ファイルを使うか？管理ツールを使うか？チューニング可能なパラメー
タはどう設定されているか
• 指標
• アプリケーションの指標は提供されているか

5. ■ 基礎
(つづき)
• ログ
• アプリケーションはどのようなログを作っているかログからどのようなパフォーマンス
指標が分かるか
• バージョン
• アプリケーションは最新のバージョンになっているか
• バグ
• パフォーマンスに関する既知のバグはあるか？
• コミュニティ
• パフォーマンスについての質問に答えてくれるコミュニティはあるか？
• 書籍
• パフォーマンスに関する書籍、ドキュメントはあるか？
• エキスパート
• 身近にパフォーマンスの相談ができるエキスパートがいるか？

6. パフォーマンスの目標
パフォーマンスの項目はいくつかある
• 例
• レイテンシ
• スループット
• リソースの使用率
目標とする項目を決めたら定量化する
• 例
• アプリケーションの平均な要求レイテンシは 5ms
• 95 % の要求のレイテンシは 100ms 以下
• 平均的なディスク使用率を 50% に抑える

7. ■よく実行されるコードの最適化
• 効率的なパフォーマンスの向上
• 本番で最もよく使われるコードパスを見つけ出し改善
• CPU バウンド
• 頻繁に CPU が実行するコードに注目
• I/Oバウンド
• 頻繁に I/O を実行するコードパスに注目
• ⇒
• アプリケーションの分析
• プロファイリング
• 可観測性ツール

8. ■可観測性
• アプリケーションを採用する際には、可観測性ツールが用意されているも
のを採用したほうがよい
• 高速だが不透明なアプリケーションよりも長期的にみて有利
• 可観測性ツールを使うと不要な仕事を取り除ける
• 「最も大きくパフォーマンスを引き上げられるのは、不要な仕事を取り除いたとき」

9. ■ビッグオー記法
• アルゴリズムの複雑度を表す指標
• 「計算量のオーダー」とも呼ばれる
• O(n) なら「オーダーエヌ」とよく読まれる
• 入力データセットが増えた時のパフォーマンスをモデル化
• 読み方
• 𝑂(𝑛2
)
• O → 平均的な条件の下であることを示す
• 最悪の場合なら Ω (オメガ)など
• n → 入力サイズ
• () の中の式→ 入力サイズに対する処理時間の増え方
• 例
• O(1) … 入力サイズによらず定数時間
• O(n) … 入力サイズに比例して処理時間が増える

10. ■ビッグオー記法の例
記法 例
O(1) 2値テスト
O(log n) ソート済み配列の 2 部探索
O(n) 連結リストの線形サーチ
O(n log n) クイックソート (平均的な条件で)
O(n^2) バブルソート(平均的な条件で)
O(n!) 巡回セールスマン問題の総当り

11. 計算量の比較

12. ■パフォーマンス向上のテクニック
• I/Oサイズの選択
• キャッシング
• バッファリング
• ポーリング
• 並行・並列処理
• ノンブロッキングI/O
• プロセッサのバインド

13. I/Oサイズの選択
• I/O にかかるコストは大きい
• バッファの初期化, システムコールの実行 etc
• 効率を上げるには １回の I/O De転送するデータが大きいほう
が良い
• 大きなI/Oサイズが必要でないとき
• I/Oサイズが無駄になる

14. キャッシング
読み込みパフォーマンスの向上に使う
• コストの高いオペレーションの代わりに、結果だけローカル
キャッシュに書くなどする
• アプリケーションにどのようなキャッシュが提供されているか
調べてシステムに合わせてキャッシュサイズを設定する
• ただしキャッシュが大きくなるとキャッシュコヒーレンシが問
題になる
• キャッシュコヒーレンシ
• キャッシュと実際のリソース間の一貫性
• キャッシュが大きくなればそれだけ一貫性のチェックにも時間がかかる

15. バッファリング
書き込みパフォーマンスの向上に使う
• バッファ内で書き込みデータを結合するテクニック
=＞一度に行う I/O サイズが大きくなり効率が上がる
• ただしレイテンシが高くなる場合もある
• バッファに対する最初の書き込みは後の書き込みが届かないと送られ
ない

16. ポーリング
• ループ内でイベントのステータスをチェックしてイベントの発
生を確認するテクニック
• パフォーマンス上の問題
• 反復的なチェックにより CPU のオーバーヘッドが高くなる
• イベントの発生から次のチェックまでのレイテンシが高い
• poll()
• Linuxの場合は epoll を使えばO(1)で済む

17. 並行・並列処理
• 並行≠並列
• 並行 (concurrent)
• 複数のタスクを 1 つの CPU で同時に実行する方式
• node.js でやるようなイベントベースの非同期処理もこちらに含まれる
• パフォーマンス向上は
• CPUバウンドな処理では期待できない
• I/Oバウンドなどレイテンシが高い処理の場合には期待できる
• 並列 (parallel)
• 複数のタスクを複数の CPU で同時に実行する方式
• パフォーマンス向上は大抵の場合で期待できる
• ただし以前の Amdahl の法則のようにCPUを増やした分だけ性能が上がるわけでは
ない
• 並列であっても並行でない場合もある (←個人的な意見であるが…)
• GPU の SIMT の predicate 機構

18. 並行・並列処理に使う同期プリミティブ
• ミューテックスロック
• ロックを持つスレッドだけがCPUを使える
• 他のスレッドはブロックされる
• Linux では実際にはアダプティブスピニングミューテックスロックとして実
装されている
• ミューテックスロックとスピンロックの中間
• Solaris由来
• スピンロック
• ロックを持つスレッドが処理を実行できる
• 他のスレッドはループしながらロックスピンを獲得しようとする
• ブロックされず CPU から排除されないため低レイテンシのアクセスができ
るがCPUリソースが無駄になる
• RWロック
• 複数の読み込みか、ひとつの書き込みだけを認める

19. ノンブロッキングI/O
• ブロッキング I/O では次のパフォーマンス問題がある
• 並列実行されている I/O が多数あると個々の I/O がスレッドをブロッ
クしてしまう。
• 短時間で終了する I/O を頻繁に行うと、頻繁にコンテキストスイッチ
を行うためのオーバヘッドが出てしまう
• ノンブロッキング I/O
• 現在のスレッドをブロックせずに I/O を非同期に発行
• I/Oの実行中に他の仕事が出来る
• Node.js など

20. プロセッサのバインド
• プロセスやスレッドを同じ CPU で実行し続けること
• 特に NUMA (Non Unified Memory Access) 環境でメリットが多い
• メモリが CPU 別に局在しているため、プロセスが移動してしまうとオーバー
ヘッドがある
• それ以外の場合でも、プロセスがCPUを移動しなければCPUのキャッ
シュが活かせるためメリットがある
• Linux では OS が効率的にスケジューリングしてくれる
• アプリケーションによっては自分自身を CPU にバインドする
• この状態でほかの CPU バインドしてしまうとパフォーマンスが下が
るので注意

21. ■プログラミング言語
• 言語によってはパフォーマンスの問題をチューニングで解決で
きる
• コンパイル言語
• インタープリタ言語
• 仮想マシン
• ガベージコレクション

22. コンパイラ型言語
• コンパイラ型言語
• コンパイル処理が必要な言語
• この処理でソースコードから実行可能なファイルを作る
• コンパイル時に最適化を行いパフォーマンスを改善できる
• コンパイル言語の例
• C, C++, Java, Go

23. コンパイル言語の最適化
• コンパイラによる最適化
• gcc の場合は全部で 180 程の最適化オプションがある
• gcc –Q –O3 –help=optimizers
• ただしなにかしらのトレードオフがある
• フレームポインタの保存を省略するとスタックトレースが見れなくなるetc
• プログラマによる最適化
• 特に低レイヤの場合は CPU の挙動を把握して書くとパフォーマンス
が向上する場合がある
• 分岐予測を意識してコードを書く etc

24. インタープリタ言語
• インタープリタ言語とは
• 実行時にプログラムを実際の動作に変換する言語
• 変換にはオーバーヘッドがかかる
• パフォーマンスの高さは期待できない
• グローバルインタプリタロックにより並列処理に制限がある場合も多い
• 一部のインタプリタではこの GIL をなくす試みもある
• インタープリタ言語の例
• Python, Ruby

25. インタープリタ言語のパフォーマンス
• インタープリタによるパフォーマンス向上
• 新しいバージョンを使う
• Ruby 2.5 だと依然のバージョンの 3 倍早くなる予定
• そもそもパフォーマンスマターの場合には採用しない
• プログラマによる最適化
• ホットスポットでだけ C 関数 etc の呼び出しに変える
• Python ならその部分だけ Cython にしてみるetc
• numpy などはこのアプローチをとっている
• JIT が使える場合は JIT を使う
• Python → Numba というライブラリで python 関数を JIT できる
• コードの書き方によって性能が大きく変わる場合も多い
• ドキュメントやコミュニティを調べる

26. 仮想マシン
• 仮想マシンとは
• コンピュータをシミュレートするソフトウェア
• プラットフォームに非依存、移植性が高い
• バイトコード(＝仮想マシン語命令セット)をインタープリートして実
行するので、インタープリタにも近い
• 例
• Java, Erlang

27. 仮想マシンのパフォーマンス
• VMによる最適化
• JIT コンパイル
• バイトコードを実行時 or 適当なタイミングでネイティブコードにコンパイルす
る仕組み
• 速いが、メモリが足りなくなると JIT が働かなくなり性能が落ちることも
• VMのチューニング可能なパラメータをよく調べる
• 特にメモリ周り
• プログラマによる最適化
• Erlang そもそもそんなに早くない
• スケールアウトさせたい場合には有利
• Java, JVM 系言語
• VM は複雑なので、VM付属のプロファイラetc を使用して解析する

28. ガベージコレクション
• ガベージコレクションとは
• メモリ管理を自動化するもの
• プログラムは非常に書きやすくなる
• デメリット
• メモリ消費量の増加
• メモリ消費量が増えて、ページングに引っかかったりする
• CPUのコスト
• GC の実行に CPU リソースが使われる
• 大量にオブジェクトを持っていると、スキャンに時間がかかることも
• レイテンシ外れ値
• GC の実行によりアプリケーションが一時停止する場合がある
• どの程度の頻度、長さかは GC の実装による

29. ■メソドロジと分析
• スレッドの状態の分析
• CPUのプロファイリング
• の分析
• I/Onoプロファイリング
• ワークロードの特性の把握
• USE メソッド
• ドリルダウン分析
• ロック分析
• 静的パフォーマンスチューニング
書籍ではこの順序でチェックしていくことが薦められている

30. スレッド状態の分析
• どの状態で長く時間を費やしているかわかるとさらに深い調査がで
きる
• 実行中
• どのコードパスがどれくらいの時間 CPU を消費しているか調べる
• スピンロックの可能性もあるので注意
• 実行可能
• CPUリソースが足りない=>CPUの使用状況と制限があるか調べる
• スワッピング待ち
• メモリが足りていない恐れがある⇒メモリ使用状況とリソースに制限があるか調べる
• スリープ
• アプリケーションをブロックしているリソースを調べる
• ロック
• ロックを保持しているスレッドは何か、保持スレッドが長期間ロックを保持している
のはなぜかを調べる

31. スレッド状態の分析
• 実行時間
• top(1) の %CPU を見る
• 実行可能時間
• /proc/*/schedstat に公開されている
• スワッピング待ち時間
• カーネルの遅延アカウンティング機能で計測
• 計測にはCONFIG_TASK_DELAY_ACCT の有効化が必要
• スリープ
• pidstat –d
• ps –l の WCHAN
• iostat
• ロック時間
• トレーシングツール
• プログラミング言語付属のツール

32. CPUのプロファイリング
• アプリケーションが CPU リソースをどこで消費しているか？
• perf コマンドでスタックトレースのサンプリングを行い調べる
ことができる
• 詳細は次回
• perf record –a –g –F100000 <コマンド>
• -g ⇒コールスタックを記録
• -a ⇒実行コマンドだけでなくシステム全体の情報も収集
• -F100000 ⇒100, 000Hz でサンプリング
• Brendan Gregg が可視化ツールも公開している

33. システムコールの分析
• ブレークポイントトレーシング
• システムコールの開始と終了にブレークポイントを設定する
• パフォーマンスが悪くなる場合がある
• Linux の場合は strace を使う
• strace –ttt –T
• -ttt
• 最初の行
• エポックからの時間
• -T
• 最後の行
• システムコールにかかった時間

34. システムコールの分析
• バッファードトレーシング
• プログラムの実行を止めず、カーネル内にデータをバッファリングす
る
• ブレークポイントで割り込むのではないのでオーバヘッドは少ない
• perf trace –e read,open,close <コマンド>
• 対象を read,open,close システムコールに絞ってトレーシングする

35. I/Oのプロファイリング
• CPU のプロファイリングと同様に I/O 関連のシステムコール
をスタックトレースで解析する
• スタックトレースにより次が分かる
• 誰が
• 何を
• どのようにして

36. USEメソッド
• アプリケーションによって USE(使用率、飽和、エラー)の指標
は異なる
• 例
• キューを使うアプリ
• 使用率 -> 一定期間中にビジーになっているスレッドの割合
• 飽和 -> 要求キューに入っている要求の平均的な長さ
• エラー -> リジェクトorエラーになった要求の数
• ファイルを扱うアプリ
• 使用率 -> 利用中のファイル記述子の数
• 飽和 -> ファイルディスクリプタの読み込み待ちなど
• エラー -> EFILE などのエラー

37. ドリルダウン分析
• アプリケーションに対するドリルダウン分析は次の順序で行う
• アプリケーションが提供するオペレーションを解析
• アプリケーションがそれらをどう実行しているか内部構造をみる
• I/O に対しては
• システムライブラリ
• システムコール
• カーネル
• ライブラリ呼び出しに対しては ltrace(1) が便利

38. ロック分析
• ロックに関する分析は次の2つ
• 競合のチェック
• 長過ぎるロック保持のチェック
• ツールが提供されている場合はそれを使えばよい
• Go言語 => go tool pprof <target> mutex.out
• For Linux
• perf lock
• カーネルのロックのみ,
• CONFIG_LOCKDEP と CONFIG_LOCK_STAT を有効にする必要がある
• perf trace や strace で futex_lock などをしている箇所を探すなど
• スピンロックなら CPU のプロファイリングをみて検出できるかもしれない
• ちなみに
• 本では lockstat, plockstat が紹介されているが DTrace が前提
• FreeBSD や MacOS では使えるらしい

39. 静的パフォーマンスチューニング
• 次のようなチェックを行う
• 使用しているバージョンに問題はないか
• アプリケーションの既知のパフォーマンス問題はないか
• CPU, メモリなどの利用にシステムが設定した制限、リソースコント
ロールはないか
• クラウドの場合は設定されているのが普通
• などなど

40. まとめ
• アプリケーションのパフォーマンス作業は次の手順
• パフォーマンスの目標を設定する
• スレッド状態の分析でどこにボトルネックがあるかを調べる
• 他の分析手法でさらに深く調べる
• パフォーマンス問題が分かったらチューニングOR修正

41. おわり