タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

PostgreSQLに関するZoeのブックマーク (5)

  • 第5回 PostgreSQL でのデータベース構築の際に必要となる物理設計のポイント | gihyo.jp

    第5回では、PostgreSQL でのデータベース構築の際に必要となる物理設計のポイントとして、データ容量の計算方法とインデックスの張り方を解説していきます。 データベース・サイジング サイジングとは、サービスの開始前に、想定される負荷や格納されるデータ量を見積り、十分な性能や規模のサーバおよびストレージを用意することです。今回は、サイジングの要素のうち、ストレージサイズの計算方法を紹介します。 データファイルの構成 PostgreSQLはデータベース・クラスタと呼ばれるディレクトリの下に、複数のディレクトリやファイルを作成します。容量の多くを占めるのはアプリケーションが使うテーブルやインデックスになるでしょうが、それ以外にも管理領域やログのためのディスク領域が必要になります。 表1 データファイルの構成と容量

    第5回 PostgreSQL でのデータベース構築の際に必要となる物理設計のポイント | gihyo.jp
  • pg_bulkload: プロジェクト ホームページ

    はじめに pg_bulkloadは一定の制約条件の下で大量のデータを高速にロードするためのプログラムです。 大量のデータを投入するような状況では、細かなチェックは省いてでもいいからとにかく 高速にデータをロードしたいという場面があります。たとえば、あるデータベースに格納 されている情報を別のデータベースへ移送するような状況や、これから投入しようとする データの整合性がすでに別のツールで保証されているような状況がこれにあたります。 このような状況を想定して pg_bulkload は開発されました。 したがって、整合性を確認できていないデータのロードに対して、 pg_bulkload の使用 は適していません。この場合にはPostgreSQLがデータロードのためにもともと用意して いる COPY コマンドの利用をお勧めします。 注意点、使用方法を十分に理解した上で、pg_bulkload を

    Zoe
    Zoe 2009/10/21
    高速データロード
  • pg_statsinfo

     プロジェクトTopページへ    前のページへ レポートの見方 pg_make_report.plで出力されるレポートの、サマリ部分についての見方を記述します。なお、基的に出力される情報は 指定された2つ(もしくは範囲中の最新と最古)のスナップショットの差分値ですが、一部は最新値や平均値を使用しています。 各項目でそれぞれどの値になるのかは、項目の先頭に付与されている下記の凡例を参考にして下さい。 [d]:差分値 [n]:最新値 [a]:平均値 [m]:最大値 サマリは以下のカテゴリの情報が確認できます。 レポート情報 ホスト情報 デバイス使用率 ロングトランザクション情報 DBロードプロファイル DB設定情報 (ver1.1-)消費時間の多いSQL上位10 (ver1.1-)消費時間の多い関数上位10 断片化が進んだテーブル上位

    Zoe
    Zoe 2009/10/21
    pg_statsinfoについて
  • Kazuho@Cybozu Labs: PostgreSQL のボトルネックを統計的に監視・解析する方法

    先日書いた「MySQL のボトルネックを統計的に監視・解析する方法」について、PostgreSQL でも pg_stat_activity テーブルを使って実行中のクエリ一覧を取得できると higepon さんに教えてもらったので、やってみました。 % ppdump > ppdump.txt のようにクエリをサンプリング (デフォルトで100秒間程度) して、 % ppfilter < ppdump.txt | ppreport のようにすると、平均負荷の高いクエリから順にソートされて表示されます。詳しい使い方や考え方については、mprofile のエントリをご参照ください。 pprofile のソースコードは、/platform/postgresql/pprofile – CodeRepos::Share – Tracに置いてあります。負荷が高い PostgreSQL 環境が手元にないの

    Zoe
    Zoe 2009/10/21
    pg_stat_activityのポーリング
  • スロークエリの分析 — Let's Postgres

    NTT オープンソースソフトウェアセンタ 板垣 貴裕 スロークエリ (時間のかかるSQL) を発見するまでの手順を解説します。スロークエリ分析と改善は以下の流れで行うことになります。この記事では主に 1. のスロークエリの特定方法について解説します。2.については『スロークエリの改善』を参考にしてください。 どのSQLが遅いのかを見つける。 そのSQLがなぜ時間がかかるのかを判断する。 設定パラメータ、SQL、スキーマなどを改善する。 着目したSQLの性能を再測定し、2. から繰り返す。 着目したSQLのチューニングが完了したら、他のボトルネックを探すため 1. から繰り返す。 スロークエリの見つけ方 スロークエリを見つけるには、大きく分けて統計情報ビューを使う方法と、サーバログを使う方法の2つがあります。統計情報ビューを使う方法は PostgreSQL 8.4 以降でしか利用できませんが

    Zoe
    Zoe 2009/10/21
    スロークエリ
  • 1