PostgreSQLエンジンでのAuroraとRDSのベンチマーク - so what
PostgreSQLエンジンでAuroraとRDSでpgbenchを使った負荷テストを行った。 テスト環境 クライアント pgbench (PostgreSQL) 14.2 (Ubuntu 14.2-1ubuntu1) EC2のc5.2xlargeインスタンスから実行 クライアントインスタンスの性能上限には引っかかっていないことは確認 以下のようなスクリプトを実行 スケールファクター: 100 トランザクションタイプ: デフォルト（TPC-B like） #!/bin/bash . .rds for i in 8 16 32 48 64; do echo "--- $(date +%FT%TZ) RDS $i" pgbench -i -s 100 -q pgbench -c $i -T 210 sleep 60 done echo "--- $(date +%FT%TZ) RDS end"
RDS for PostgreSQL で変更すべきパラメータチューニング - そーだいなるらくがき帳
※追記(タイトルにRDSと書いたがPostgreSQL限定である） RDSはデフォルトでパラメータをチューニングされているものの、本番でそれなりに使うにはチューニングが必要。 そこで最初にある程度チューニングしておくべき場所を記載していく。 AWSのパラメータについては下記を参考。 docs.aws.amazon.com デッドロックの検査間隔 soudai.hatenablog.com deadlock_timeout はデフォルトは1000msになっている。 1秒はPostgreSQLのデフォルトなので短い。 10秒以上と書いているが弊社の場合は40秒にしている。 これは明確な基準値を持って決めてるわけでは無く、pg_stat_database.deadlocks の値が今までずっと0なので強気に付けている。 checkpointの値 Google検索すると checkpoint_se
AWS RDSでもDBAはparameterチューニングする - Qiita
弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 （この記憶はほんとうか？ 意訳や美化が入っているかもしれない） 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQLをメジャーアップするには、現況を把握して変更影響を洗い出す作業から始めます。 現況把握のひとつとして、postgresql.conf（AWS RDSだとparameter group） の状況調査をしました。 重点ポイント PostgreSQLデフォールト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
