Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
トランザクション処理における ⾼競合状態の分析/cybozulabs-youth10-mas...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Cybozu
PRO
March 31, 2021
Technology
400
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
トランザクション処理における ⾼競合状態の分析/cybozulabs-youth10-masumura
Cybozu
PRO
March 31, 2021
More Decks by Cybozu
See All by Cybozu
新卒1年目QAが リリース基準の"なぜ"をたどってみた
cybozuinsideout
PRO
1
280
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
82k
kintone リサーチ副部/UXリサーチャー 業務紹介
cybozuinsideout
PRO
0
80
私たちが『JaSST協賛』から『外部コネクト』チームになった理由
cybozuinsideout
PRO
0
360
LLMでもいつものテスト技術〜意外と半分はこれまでのテストでした〜
cybozuinsideout
PRO
1
890
kintone開発のプラットフォームエンジニアの紹介
cybozuinsideout
PRO
0
1.3k
LLMアプリの品質保証
cybozuinsideout
PRO
1
630
技術広報チームに丸投げしない!「一緒につくる」スポンサー活動
cybozuinsideout
PRO
0
240
テクニカルライター (グループウェア) について
cybozuinsideout
PRO
0
210
Other Decks in Technology
See All in Technology
AIのReact習熟度を測る
uhyo
2
370
気づかぬうちにセキュリティ負債を生むAPIキー運用
sgwrmctk
0
120
AI駆動開発を通して感じた、 AI時代のデザイナーの役割変化
whisaiyo
3
2k
How Timee Delivers Day 1 Production Ready LLM Features
tomoyks
0
190
エラーバジェットのアラートのタイミングを考える.pdf
kairim0
0
140
protovalidate-es を導入してみた
bengo4com
0
180
やさしいA2A入門
minorun365
PRO
12
1.8k
Claude Code の Sandbox 機能を Anthropic Sandbox Runtime(srt) で試そう!/lets-play-anthropic-sandbox-runtime
tomoki10
1
570
【NRUG vol.18】なぜ多くのオブザーバビリティ導入は失敗するのか
nrug_member
0
120
チームで進めるAI駆動アジャイル×ウォーターフォール
kumaiu
0
160
【Cyber-sec+】経営層を"動かす"ための考え方
hssh2_bin
0
170
攻撃者視点で考えるDetection Engineering
cryptopeg
3
1.6k
Featured
See All Featured
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
320
Documentation Writing (for coders)
carmenintech
77
5.4k
Everyday Curiosity
cassininazir
0
230
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.5k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
230
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
250
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
160
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
Typedesign – Prime Four
hannesfritz
42
3.1k
How to build a perfect <img>
jonoalderson
1
5.6k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
430
Transcript
トランザクション処理における ⾼競合状態の分析 ⾇村康成 メンター 星野さん
はじめに 研究成果 データベースにおけるトランザクション処理について ・Backoffの性能向上について新たな⾒解 ・その発⾒から、Backoffにかわる新たな最適化⼿法を提案 1
トランザクションとは ・データベースに対する処理のまとまり。 ・複数のトランザクションを並列に処理したときに、結果はトランザクションを ⼀つずつ実⾏した時と等価になる必要がある。 どうやって処理する? TX TX TX TX TX
・ ・ ・ コア コア ・ ・ ・ メモリ 2
WLPH GDWD$ ฎ⌮% ฎ⌮& %[ UHDG $
&[ UHDG $ %[ &[ ZULWH $%[ ZULWH $&[ DATA TX1 TX2 >失敗 >やり直し 競合とは 2つ以上のTXが同じデータに同時にアクセスする と、どちらかをやり直さないといけない。 >余計なコストが⽣まれる。 Lost updateの例 3
近年のトランザクション処理の課題 >競合の回避 >すべての並⾏性制御法は、この問題を解決するために様々な⼯夫を提案している >Backoffはその⼀つ 4
Backoffとは Backoffは、 abort したトランザクションを⼀定時間 sleep させたあとに再実⾏ するという最適化 <従来考えられていたbackoffの仕組み> abort したトランザクションを即時再実⾏しては、そのトランザクションが扱うデータアイテムが他
のトランザクションによってロックが取られている可能性が⾼いため、そのトランザクションを時 間 をおいて再実⾏することでトランザクションの成功率を上げると考えられている。 >タイミング制御 5
TX1 TX2 DATA1をLock中 Abort やり直し、でもまだlock中… DATA1を読みたいけど lockが取られている 従来のBackoffの考え⽅ 6
TX1 TX2 DATA1をLock中 Abort やり直し、成功! Sleep Backoff Backoffは、タイミング制御 >> 本当にそうなのか
従来のBackoffの考え⽅ 7
検証 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
仮説 >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
BackoffはSleepによるタイミング制御ではなく、 Sleepによる並⾏thread数の低下が理由で性能が上がっている 10 成果1
原因: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
Backoffはせず、 そもそもthreadの数と配置を最適化したほうが良いのでは 成果2 12
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
まとめ ・Backoff による性能向上の理由は、従来考えられていた「abort しやすいタイミングの回避」よ り、sleep することによる並⾏ thread 数の低下によって⼤きく性能が向上していることが新たに 判明 >>Backoffの性能向上について新たな⾒解
・thread locaity の観点から、少なくとも Silo においては backoff を⽤いるよりも実⾏ thread そ のものをワークロードに適した値に設定するほうが性能が向上する >>新たな最適化⼿法の提案 14