Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

A97eee01397705443a72a48ce29d3e19?s=47 Cybozu
March 31, 2021

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

A97eee01397705443a72a48ce29d3e19?s=128

Cybozu

March 31, 2021
Tweet

Transcript

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

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

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

    ・ ・ ・ コア コア ・ ・ ・ メモリ 2
  4. WLPH GDWD$ ฎ⌮% ฎ⌮&   %[ UHDG $ 

     &[ UHDG $   %[    &[    ZULWH $%[   ZULWH $&[ DATA TX1 TX2 >失敗 >やり直し 競合とは 2つ以上のTXが同じデータに同時にアクセスする と、どちらかをやり直さないといけない。 >余計なコストが⽣まれる。 Lost updateの例 3
  5. 近年のトランザクション処理の課題 >競合の回避 >すべての並⾏性制御法は、この問題を解決するために様々な⼯夫を提案している >Backoffはその⼀つ 4

  6. Backoffとは Backoffは、 abort したトランザクションを⼀定時間 sleep させたあとに再実⾏ するという最適化 <従来考えられていたbackoffの仕組み> abort したトランザクションを即時再実⾏しては、そのトランザクションが扱うデータアイテムが他

    のトランザクションによってロックが取られている可能性が⾼いため、そのトランザクションを時 間 をおいて再実⾏することでトランザクションの成功率を上げると考えられている。 >タイミング制御 5
  7. TX1 TX2 DATA1をLock中 Abort やり直し、でもまだlock中… DATA1を読みたいけど lockが取られている 従来のBackoffの考え⽅ 6

  8. TX1 TX2 DATA1をLock中 Abort やり直し、成功! Sleep Backoff Backoffは、タイミング制御 >> 本当にそうなのか

    従来のBackoffの考え⽅ 7
  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 2つのabortにおいて、差が少ない。 タイミング制御では説明しきれない ・readするデータがすでに変更されてないか >abort1 ・read するデータが他のトランザクションに よって lock されていないか>abort2 8
  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
  11. BackoffはSleepによるタイミング制御ではなく、 Sleepによる並⾏thread数の低下が理由で性能が上がっている 10 成果1

  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
  13. Backoffはせず、 そもそもthreadの数と配置を最適化したほうが良いのでは 成果2 12

  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
  15. まとめ ・Backoff による性能向上の理由は、従来考えられていた「abort しやすいタイミングの回避」よ り、sleep することによる並⾏ thread 数の低下によって⼤きく性能が向上していることが新たに 判明 >>Backoffの性能向上について新たな⾒解

    ・thread locaity の観点から、少なくとも Silo においては backoff を⽤いるよりも実⾏ thread そ のものをワークロードに適した値に設定するほうが性能が向上する >>新たな最適化⼿法の提案 14