A Top-Down Approach to Achieving Performance Predictability in Database Systems を読んだ

どんなもの？

DBのlatencyのバラ付きの主要な原因を特定するためにTprofiler(解析ツール)を作成しバラ付きを少なくした
- MySQL, Postgres, VoltDBのバラ付きの原因を調べた
  - Tprofilerを使えば複雑なコードベースでも解析できる
  - 各DBでパフォーマンスとlatencyのばらつきが少なくなった

DBの平均的なパフォーマンス向上については今まで研究されてきた
- パフォーマンスの平均だけでなく、ピーク時トランザクションのスループットも重要
- latencyやスループットの平均を落とすことなく、それらのばらつきを少なくすることを可能にした
Tprofiler
- DBのソースコードとトランザクションの開始/終了をアノテートすることで、latencyのバラ付きの原因を特定する

Tprofiler
- Dtrace等の既存のツールはトランザクションシステムのパフォーマンスのバラ付きの根本原因の特定には向いていない
  - 原因は子の関数よりも親の関数側にあることが多いが、原因を特定するための情報が少ない
Overview
- Tprofilerはパフォーマンスのバラ付きが大きい関数をランキング形式で教えてくれる
- 下記の2つがある
  - online trace collection
  - offline variance analysis
- トランザクションの開始終了をコード側でAPIを叩いて指定する
Characterizing Execution Variance
- トランザクション内での特定の関数のdulationを比較する
  - 様々なトランザクションでこれを行う
- variance treeというlantecyのバラ付きの関係を表してたtreeを作る
  - 特定の関数のcall hierachyを表す
Latency Variance in MySQL
- os_event_wait()というlockに関する関数がlatencyのバラ付きの原因になっていた
Latency Variance in Postgres
- トランザクションをcommitする前にredo logをdiskにflushする処理がlatencyのバラ付きの原因になっていた

f:id:ikemonn:20170730215223p:plain

下記を検証した
- どれくらい効率的になったか
- latencyやスループットの平均値を犠牲にして、latencyのバラ付きを無くすことに価値はあるのか
- Tprofilerが既存のプロファイラに比べてどのくらい効率的で効果的に解析を行えるか
結果
- VATSはスループットを犠牲にすること無く、ばらつきを少なくし、更に速くなった
  - ばらつきは6.3倍改善
  - latencyは5.6倍改善 -スループットは2.0倍に
- LLUはMySQLを下記のように改善
  - ばらつきは1.2倍改善
  - latencyは1.4倍改善
- Parallel LoggingはPostgresを下記のように改善
  - ばらつきは1.3倍改善
  - latencyは1.8倍改善
- TprofilerはDtraceにくらべて解析のオーバーヘッドが少なかった

f:id:ikemonn:20170730215246p:plain