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.4k
RDS_Auroraパフォーマンスインサイトを使ってみる(PostgreSQLアンカンファレンス)
第 21 回 PostgreSQL アンカンファレンス@オンライン 2021/03/02
hmatsu47
PRO
February 28, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
大人の社会科見学 ~ NTT 技術史料館に行ってみよう!
hmatsu47
PRO
0
260
pgvector 0.6.0 以降の進化についてざっくり取り上げてみる
hmatsu47
PRO
0
21
Cloudflare Workes からMySQL 系 DB への接続事情(2024/4 現在)
hmatsu47
PRO
0
45
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
62
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
82
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
68
RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話
hmatsu47
PRO
0
32
RDS Data API のその後と Aurora zero-ETL 統合のデータ転送処理の話
hmatsu47
PRO
0
81
RDS_Aurora 関連アップデート 2023 版
hmatsu47
PRO
0
82
Other Decks in Technology
See All in Technology
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
エンジニアリングマネージャーはどう学んでいくのか #devsumi / How Do Engineering Managers Continue to Learn and Grow?
expajp
4
1.3k
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
150
地理情報とAPIのトレンド
nagix
0
160
Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践
yuriemori
0
190
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
AIアシスタントの活用で品質の向上と開発ワークフローのスピードアップ
nagix
1
200
Azure AI ことはじめ
tsubakimoto_s
0
130
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
59
9.6k
Making the Leap to Tech Lead
cromwellryan
127
8.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
13
430
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
44
4.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
GitHub's CSS Performance
jonrohan
1026
450k
Creatively Recalculating Your Daily Design Routine
revolveconf
214
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Build your cross-platform service in a week with App Engine
jlugia
227
17k
The Cult of Friendly URLs
andyhume
75
5.9k
Designing Experiences People Love
moore
136
23k
Typedesign – Prime Four
hannesfritz
37
2.2k
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