A Top-Down Approach to Achieving Performance Predictability in Database Systems を読んだ
A Top-Down Approach to Achieving Performance Predictability in Database Systemsを読んだ時のメモ。
どんなもの?
- DBのlatencyのバラ付きの主要な原因を特定するためにTprofiler(解析ツール)を作成しバラ付きを少なくした
- MySQL, Postgres, VoltDBのバラ付きの原因を調べた
- Tprofilerを使えば複雑なコードベースでも解析できる
- 各DBでパフォーマンスとlatencyのばらつきが少なくなった
- MySQL, Postgres, VoltDBのバラ付きの原因を調べた
先行研究とくらべて何がすごい?
- DBの平均的なパフォーマンス向上については今まで研究されてきた
- Tprofiler
技術や手法の肝は?
- Tprofiler
- Dtrace等の既存のツールはトランザクションシステムのパフォーマンスのバラ付きの根本原因の特定には向いていない
- 原因は子の関数よりも親の関数側にあることが多いが、原因を特定するための情報が少ない
- Dtrace等の既存のツールはトランザクションシステムのパフォーマンスのバラ付きの根本原因の特定には向いていない
- Overview
Characterizing Execution Variance
Latency Variance in MySQL
- os_event_wait()というlockに関する関数がlatencyのバラ付きの原因になっていた
Latency Variance in Postgres
- Variance-aware trancaction scheduling
- Tprofilerによるとlocak wait timeがlantecyのバラ付きの原因
- lock scheduling algorithmを変更する
- Problem setting
- 一般的なDBはconcurrency controlのための2-PLが原因でlatencyのバラ付きが起こる
- 一般的なトランザクションスケジューリングはFCFS
- 一番早いトランザクションがlockを獲得する
- current queueに一番長くいるものからlockを獲得していく
- これがlantecyの平均値を最小化しないだけでなく、latencyのバラ付きの原因になっている
- 一番早いトランザクションがlockを獲得する
- トランザクションがどれくらいキューにいるかを考慮せずにtransaction scheduleをおこなう
- トランザクションがキューにつまれたときに、そのageのみを考慮して、いつ終了するかやlockを開放するかについては知らない
- Additional Strategies
どうやって有効と検証した?
- 下記を検証した
- どれくらい効率的になったか
- latencyやスループットの平均値を犠牲にして、latencyのバラ付きを無くすことに価値はあるのか
- Tprofilerが既存のプロファイラに比べてどのくらい効率的で効果的に解析を行えるか
- 結果