ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング | Amazon Web Services
Amazon Web Services ブログ ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for Postgre
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
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
目的別ガイド：チューニング編 — Let's Postgres
この記事では PostgreSQL のチューニングの概要を紹介します。まずは PostgreSQL のチューニングの勘所を掴んでください。各項目についての詳細はリンク先の記事で紹介していますので、そちらをご覧下さい。 チューニングの流れ PostgreSQLのチューニングとして必要な作業には何があるのでしょうか？ システムの開発状況やボトルネックによって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 1. 情報収集と分析 チューニングを総当りで試すのは得策ではありません。まずは「ログ」や「稼動統計情報」を収集し、パフォーマンスのボトルネックを見つけることが先決です。特に良くあるトラブルは「トラブルシュートとチューニング」にも対処方法があります。 2. チューニングの実施 最も影響の大きなボトルネックから順にチューニングしていきます。 ボトルネックが解消されるまで、それ以外の
PostgreSQL のパフォーマンスチューニング - Qiita
PostgreSQL Advent Calendar 2014 の 13日目です。 Advent Calendar を今年もやってみたいと思って、枠が空いていたので飛び込んでみました。 昨日は osapon さんの libpqxx を使ってみたでした。 概要 PostgreSQL のパフォーマンスチューニングは大きく下記に分かれます。 システムチューニング SQL チューニング ここでは Linux 上で動かしていることを前提に、それぞれ説明します。 システムチューニング システムチューニングの概要 システムチューニングとは、OS または PostgreSQL の設定を変更することです。 それぞれ順に説明します。 OS チューニング PostgreSQL では特にメモリ関連でOSパラメータを設定変更すると、高速化効果が得られます。 特に下記のカーネルパラメータに注意します。 vm.dirt
PostgreSQL初期設定これだけは変えておこう
PostgreSQL Advent Calendar 2012（全部俺）のDay 1です。 初日は、まずPostgreSQLを使い始める際の基本的なお作法である初期設定について簡単にまとめてみます。 PostgreSQLは、パラメータの設定を変更せずにデフォルトの設定のまま使い始めても、もちろん動くことは動くのですが、後からいろいろと問題が出てくることもありますし、特に性能関連のパラメータのデフォルト値はあまりに小さく、チューニング云々以前の問題だったりします。 というわけで、私が普段PostgreSQLをインストールして使い始める時、開発機であってもいくつかパラメータを初期設定するようにしています。 使い始める前に設定から入るのは確かに面倒なのですが、最初に設定が必要なパラメータは少数（今回紹介するのは5つ）ですので、まずは最初に必要最低限の設定をしてから使い始めましょう、というのが本エ
PostgreSQL 9.2の同期レプリケーションを利用する際の勘所
レプリケーション利用時の注意点 PostgreSQLレプリケーションの「同期」は、WALの伝播を同期するだけで、テーブルへのデータ反映は非同期で行われます。そのため同期・メモリ同期を選択したとしても、更新直後にスレーブからデータを参照すると、更新の反映がまだ行われていない場合があります[3]。 また前節で紹介した4つの設定は性能と可用性がトレードオフの関係にあります。それぞれの特徴は以下のとおりです。 同期はユーザへの応答があった時点でマスター・スレーブの両方のディスクにWALが書き込まれます。スレーブのディスクに最新の更新が存在しますので、マスターのディスク障害が発生しても最新の更新が失われることはありません。しかし、スレーブでのWAL書き込みを待つため、他の設定に比べて更新処理のレスポンス時間が長く、性能面で劣ります。 メモリ同期はユーザへの応答があった時点でマスターのディスクとスレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PGTune - calculate configuration for PostgreSQL based on the maximum performance for a given hardware configuration