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
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
340
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
82k
kintone リサーチ副部/UXリサーチャー 業務紹介
cybozuinsideout
PRO
0
90
私たちが『JaSST協賛』から『外部コネクト』チームになった理由
cybozuinsideout
PRO
0
370
LLMでもいつものテスト技術〜意外と半分はこれまでのテストでした〜
cybozuinsideout
PRO
1
930
kintone開発のプラットフォームエンジニアの紹介
cybozuinsideout
PRO
0
1.4k
LLMアプリの品質保証
cybozuinsideout
PRO
1
650
技術広報チームに丸投げしない!「一緒につくる」スポンサー活動
cybozuinsideout
PRO
0
250
テクニカルライター (グループウェア) について
cybozuinsideout
PRO
0
220
Other Decks in Technology
See All in Technology
AWS Security Hub CSPMの成功・失敗体験
cmusudakeisuke
0
550
元銀行員がAIだけでアプリを量産!「バイブコーディング実演セミナー 」
tatsuya1970
0
110
When Platform Engineering Meets GenAI
sucitw
0
170
自宅LLMの話
jacopen
1
720
現場のトークンマネジメント
dak2
1
190
AIAU_UMEMOGU_ninomiya_slide
ninomiya_ii
0
260
AWS Security Agent といっしょに脅威モデリングをやってみよう
amarelo_n24
1
210
[チョークトーク資料]AWS DevOps Agent を使いこなす / AWS Dev Ops Agent Chalk Talk AWS Summit Japan 2026
kinunori
4
770
クラウドファンディング版StackChan 3体(4体)をインタラクティブな体験型作品にして展示もした話 / スタックチャンお誕生日会2026
you
PRO
0
180
AIペネトレーションテスト・ セキュリティ検証「AgenticSec」紹介資料
laysakura
2
7.5k
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
1
1.8k
WebGIS AI Agentの紹介
_shimizu
0
560
Featured
See All Featured
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
420
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
1.1k
We Are The Robots
honzajavorek
0
250
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
310
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
The Cult of Friendly URLs
andyhume
79
6.9k
So, you think you're a good person
axbom
PRO
2
2.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
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