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
RDS_Auroraパフォーマンスインサイトを使ってみる(PostgreSQLアンカンファレンス)
Search
hmatsu47
PRO
February 28, 2021
Technology
0
1.3k
RDS_Auroraパフォーマンスインサイトを使ってみる(PostgreSQLアンカンファレンス)
第 21 回 PostgreSQL アンカンファレンス@オンライン 2021/03/02
hmatsu47
PRO
February 28, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
47
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
19
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
32
RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話
hmatsu47
PRO
0
15
RDS Data API のその後と Aurora zero-ETL 統合のデータ転送処理の話
hmatsu47
PRO
0
41
RDS_Aurora 関連アップデート 2023 版
hmatsu47
PRO
0
69
人工無能たいたん
hmatsu47
PRO
0
61
20 世紀末の地方税理士事務所で IT 導入の 1 → 10 を頑張った話
hmatsu47
PRO
0
37
パソコン通信むかしばなし
hmatsu47
PRO
0
200
Other Decks in Technology
See All in Technology
ServiceNow Knowledge Learning Rise up
manarobot
0
200
テストプロセスで大事にしていること #jasstnano
makky_tyuyan
0
160
Next'24 事例セッションの紹介とクラウド資格を活用したキャリア形成について語りMuscle
yasumuusan
1
430
反実仮想機械学習とは何か
usaito
PRO
10
3.6k
データベース02: データベースの概念
trycycle
0
150
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
530
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
3
270
Oracle Cloud Infrastructure:2024年4月度サービス・アップデート
oracle4engineer
PRO
1
190
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
500
Hands-on Gemini, the Google DeepMind LLM
meteatamel
1
110
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
290
現代CSSフレームワークの内部実装とその仕組み
poteboy
8
3.6k
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
325
20k
Designing the Hi-DPI Web
ddemaree
276
33k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
Making Projects Easy
brettharned
108
5.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
2
1.3k
Infographics Made Easy
chrislema
238
18k
Faster Mobile Websites
deanohume
299
30k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
Testing 201, or: Great Expectations
jmmastey
28
6.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
14
1.5k
Git: the NoSQL Database
bkeepers
PRO
422
63k
Building an army of robots
kneath
300
41k
Transcript
RDS / Aurora パフォーマンスインサイトを 使ってみる(PostgreSQL 編) 第 21 回 PostgreSQL
アンカンファレンス@オンライン 2021/03/02 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っています ◦
Qiita の記事: https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を勉強会などで無料配布していました ◦ 新型コロナウイルスの関係でオフライン勉強会ができなくなったので、 現在は BOOTH でも配布しています(100 円+送料)8.0.23 対応版配布中 https://hmatsu47.booth.pm/ 2
今日の内容 • パフォーマンスインサイトとは • 管理コンソールで見てみる ◦ Aurora PostgreSQL 12.4 互換版で
pgbench した結果 ▪ RDS PostgreSQL 12.5-R1 と比較 • 注意点 ◦ 表示される合計値のズレ・SQL 文グルーピングの不具合(?) ※2021/01/28 開催の JAWS-UG 名古屋での発表を一部再構成 3
パフォーマンスインサイトとは • RDS / Aurora の負荷とその内訳を示すもの ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ PerfInsights.Overview.html •
カウンターメトリクス ◦ 性能に関係するカウンター値を個別にグラフ表示 • データベースのロード ◦ 負荷の高さと内訳をグラフ表示 4
カウンターメトリクス 5
データベースのロード 6
データベースのロード • 合計:単位時間あたり平均コネクション数 • 内訳:待機イベント毎の所要時間 ◦ 上位 9 個(※)+ CPU
時間(緑)で計 10 個 (※)「上位 9 個」は選択期間内における上位 9 個 ◦ 正規化した SQL(文)上位 10 個の待機イベント内訳も表示可能 ▪ SQL(文)正規化(グルーピング) ≠ DB(テーブル)正規化 ▪ 空白・クォート等を揃え、 パラメータを「?」に置き換え 7
待機イベント 8
待機イベント • Aurora PostgreSQL 互換版独自(代表例) ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraP ostgreSQL.Reference.html#AuroraPostgreSQL.Reference.Waitevents • pg_stat_activity
ビューの wait_event(_type) 列 ◦ https://www.postgresql.jp/document/12/html/monitoring-stats.html#MONITORING- STATS-VIEWS-TABLE ◦ https://www.postgresql.jp/document/12/html/monitoring-stats.html#WAIT-EVENT-T ABLE 9
SQL 情報 • • 「トップ SQL」で正規化された SQL 文のグループか、 展開された個別の SQL
文を選択すると表示される 10
管理コンソールで見てみる • Aurora PostgreSQL 12 互換版 と RDS PostgreSQL で
pgbench(on db.r5.large) ◦ スケールファクタ : 100 でテーブル準備 pgbench -i -s 1000 -U postgres -h 【エンドポイント】 -d pgbench ◦ 10 並列で実行(5 分間) pgbench -N -r -c 10 -j 10 -T 300 -U postgres -h 【エンドポイント】 pgbench ◦ RDS は Single-AZ / Multi-AZ(SSD 700GiB) 11
pgbench 結果(参考) • Aurora PostgreSQL 12.4 互換版 number of transactions
actually processed: 300924 latency average = 9.970 ms tps = 1003.051684 (including connections establishing) tps = 1003.127591 (excluding connections establishing) statement latencies in milliseconds: 0.001 \set aid random(1, 100000 * :scale) 0.000 \set bid random(1, 1 * :scale) 0.000 \set tid random(1, 10 * :scale) 0.000 \set delta random(-5000, 5000) 0.359 BEGIN; 2.119 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 1.417 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 1.039 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 5.035 END; 12
pgbench 結果(参考) • RDS PostgreSQL 12.5-R1 Single-AZ number of transactions
actually processed: 706450 latency average = 4.247 ms tps = 2354.797334 (including connections establishing) tps = 2354.979073 (excluding connections establishing) statement latencies in milliseconds: 0.001 \set aid random(1, 100000 * :scale) 0.000 \set bid random(1, 1 * :scale) 0.000 \set tid random(1, 10 * :scale) 0.000 \set delta random(-5000, 5000) 0.216 BEGIN; 1.129 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 0.482 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 0.476 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 1.944 END; 13
pgbench 結果(参考) • RDS PostgreSQL 12.5-R1 Multi-AZ number of transactions
actually processed: 180294 latency average = 16.640 ms tps = 600.951608 (including connections establishing) tps = 601.006738 (excluding connections establishing) statement latencies in milliseconds: 0.001 \set aid random(1, 100000 * :scale) 0.000 \set bid random(1, 1 * :scale) 0.000 \set tid random(1, 10 * :scale) 0.000 \set delta random(-5000, 5000) 2.083 BEGIN; 2.786 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 2.175 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 2.160 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 7.436 END; 14
注意点 [1] • 選択期間内の上位 9 個 ≠ 対象時間の上位 9 個の場合
(※)CPU を含めて 10 個 ◦ 一部の待機イベントが漏れる・合計値が本来より低くなる ▪ 対象時間に計測された待機イベントが 10 個以上の場合も?(未確認) • API で値を取得してみるとわかる ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ PerfInsights.API.html 15
API で取得してみる • query.json [ { "Metric": "db.load.avg", "GroupBy": {
"Group": "db.wait_event", "Limit": 10 } } ] • コマンド aws pi get-resource-metrics \ > --service-type RDS \ > --identifier db-RM5PRFJKZPTTAINCWH2NM2L3QA \ > --start-time 2021-02-28T02:14:00Z \ > --end-time 2021-02-28T02:15:00Z \ > --period-in-seconds 60 \ > --metric-queries file://query.json 16
合計値が違う { "Identifier": "db-RM5PRFJKZPTTAINCWH2NM2L3QA", "AlignedStartTime": 1614478440.0, "MetricList": [ { "Key":
{ "Metric": "db.load.avg" }, "DataPoints": [ { "Timestamp": 1614478500.0, "Value": 6.566666666666666 } ] }, ※グラフの値は小数点第三位を四捨五入→ 6.57 なら合っている 17
{ "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "LWLock", "db.wait_event.name":
"ProcArrayLock" } }, "DataPoints": [ { "Timestamp": 1614478500.0, "Value": 0.016666666666666666 } ] } 原因らしきもの 18 この項目は、対象時間では (CPU を含んだ順位で) 7 位だったが、選択期間内 全体では 9 位圏外だった
注意点 [2] • • • • トップ SQL の正規化(グルーピング)がおかしい? ◦
2 つに分かれてしまうことがある(何らかの意図がある?) 19
まとめ • ある程度直感的に見ることができる ◦ マニュアルを見なくても負荷状況が(まあまあ)わかる • 値の取り扱い(見方)には注意が必要 ◦ 画面に表示されていない待機イベントがある ◦
画面上の合計値が実際とズレている可能性がある • 管理コンソールは「概況を見るもの」と割り切る ◦ 適宜 API を活用する(→分析基盤等へ) 20