トランザクション処理における ⾼競合状態の分析/cybozulabs-youth10-masumura

Transcript

1. トランザクション処理における
   ⾼競合状態の分析
   ⾇村康成
   メンター 星野さん
   

   View Slide

2. はじめに
   研究成果
   データベースにおけるトランザクション処理について
   ・Backoffの性能向上について新たな⾒解
   ・その発⾒から、Backoffにかわる新たな最適化⼿法を提案
   1
   

   View Slide

3. トランザクションとは
   ・データベースに対する処理のまとまり。
   ・複数のトランザクションを並列に処理したときに、結果はトランザクションを
   ⼀つずつ実⾏した時と等価になる必要がある。
   どうやって処理する？
   TX
   TX
   TX
   TX
   TX
   ・
   ・
   ・
   コア
   コア
   ・
   ・
   ・
   メモリ
   2
   

   View Slide

4. WLPH GDWD$ ฎ⌮% ฎ⌮&
   %[ UHDG$
   &[ UHDG$
   %[
   &[
   ZULWH$%[
   ZULWH$&[
   DATA
   TX1 TX2
   >失敗
   ＞やり直し
   競合とは
   ２つ以上のTXが同じデータに同時にアクセスする
   と、どちらかをやり直さないといけない。
   ＞余計なコストが⽣まれる。
   Lost updateの例
   3
   

   View Slide

5. 近年のトランザクション処理の課題
   ＞競合の回避
   ＞すべての並⾏性制御法は、この問題を解決するために様々な⼯夫を提案している
   ＞Backoffはその⼀つ
   4
   

   View Slide

6. Backoffとは
   Backoffは、 abort したトランザクションを⼀定時間 sleep させたあとに再実⾏ するという最適化
   ＜従来考えられていたbackoffの仕組み＞
   abort したトランザクションを即時再実⾏しては、そのトランザクションが扱うデータアイテムが他
   のトランザクションによってロックが取られている可能性が⾼いため、そのトランザクションを時
   間 をおいて再実⾏することでトランザクションの成功率を上げると考えられている。
   ＞タイミング制御
   5
   

   View Slide

7. TX1
   TX2
   DATA1をLock中
   Abort やり直し、でもまだlock中…
   DATA1を読みたいけど
   lockが取られている
   従来のBackoffの考え⽅
   6
   

   View Slide

8. TX1
   TX2
   DATA1をLock中
   Abort やり直し、成功！
   Sleep
   Backoff
   Backoffは、タイミング制御 ＞＞ 本当にそうなのか
   従来のBackoffの考え⽅
   7
   

   View Slide

9. 検証
   0
   5x106
   1x107
   1.5x107
   2x107
   2.5x107
   3x107
   3.5x107
   4x107
   0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
   Throughput[TPS]
   skew
   no backoff
   abort1
   abort2
   ２つのabortにおいて、差が少ない。
   タイミング制御では説明しきれない
   ・readするデータがすでに変更されてないか
   ＞abort1
   ・read するデータが他のトランザクションに
   よって lock されていないか>abort2
   8
   

   View Slide

10. 仮説
    ＞backoff が sleep によって単位時間ごとの起動 thread を減らし、 競合の可能性を低下させていると仮説
    0
    2x106
    4x106
    6x106
    8x106
    1x107
    1.2x107
    1.4x107
    1.6x107
    1.8x107
    2x107
    0.7 0.75 0.8 0.85 0.9 0.95 1
    Throughput[TPS]
    skew
    silo 224 thread
    backoff
    thread adjust
    VNHZ
    WKUHDGDGMXVW䛻䜘䜛WKUHDGᩘ
    EDFNRII䛾㉳ືWKUHDGᩘᖹᆒ
    Sleepによるタイミング制御ではなく、Sleepによる並⾏thread数の低下が理由では？
    ＞実⾏ thread 数を調整することにより、
    チューニングした backoff と同等の性能を出すことが可
    能であると考えられる
    9
    

    View Slide

11. BackoffはSleepによるタイミング制御ではなく、
    Sleepによる並⾏thread数の低下が理由で性能が上がっている
    10
    成果1
    

    View Slide

12. 原因:Cache-miss
    backoff は 4 つの socket で計 224thread を⽤いているのに対し、実⾏ thread 調整では、1 つの socket
    で thread がすべて収まり切っている
    thread adjust において、thread 数はそのままに 4 socket に均等に thread を 配置することで⽐較
    0
    1x106
    2x106
    3x106
    4x106
    5x106
    6x106
    7x106
    8x106
    0.8 0.82 0.84 0.86 0.88 0.9 0.92 0.94 0.96 0.98 1
    Throughput[TPS]
    skew
    backoff
    1socket
    4socket
    silo 224 thread
    0
    10
    20
    30
    40
    50
    60
    1 2 3 4
    0
    1x106
    2x106
    3x106
    4x106
    5x106
    6x106
    cache-misses rate
    Throughput[TPS]
    socket
    cache-misses rate
    Throughput
    （skew0.9_26thread） 11
    

    View Slide

13. Backoffはせず、
    そもそもthreadの数と配置を最適化したほうが良いのでは
    成果2
    12
    

    View Slide

14. Thread-controlの効果
    0
    1x106
    2x106
    3x106
    4x106
    5x106
    6x106
    7x106
    8x106
    9x106
    0.8 0.82 0.84 0.86 0.88 0.9 0.92 0.94 0.96 0.98 1
    Throughput[TPS]
    skew
    thread adaptive
    backoff
    thread adjust
    13
    

    View Slide

15. まとめ
    ・Backoff による性能向上の理由は、従来考えられていた「abort しやすいタイミングの回避」よ
    り、sleep することによる並⾏ thread 数の低下によって⼤きく性能が向上していることが新たに
    判明
    ＞＞Backoffの性能向上について新たな⾒解
    ・thread locaity の観点から、少なくとも Silo においては backoff を⽤いるよりも実⾏ thread そ
    のものをワークロードに適した値に設定するほうが性能が向上する
    ＞＞新たな最適化⼿法の提案
    14
    

    View Slide