PostgreSQL検証報告セミナー
アシスト 2011-05-19 PostgreSQL検証報告セミナー
基本性能や可用性構成はどこまで実用的？
午前の部セミナーに参加しました。
Session1、PostgreSQL9.0の実力を探る
Session2、PostgreSQLでの高可用性データベースシステムとは?!
2つのセッションで各1時間づつ
自分は、PostgreSQL6.4から利用を始めた。
書籍やWebの情報をもとに使用してきたが、
改めてセミナーの形式で情報を得るのははじめてだった。
セミナーでの検証環境は、
Xeon X5650 2.66G×2
RedHatLinux5 64bit
PostgreSQL 9.0.1
内蔵Disk 146G×8
コールセンターシステムの擬似アプリケーションといった内容であった。
テーブルの関連図
実際に運用するシステムと比較するとテーブル数が少ない。
PostgreSQL固有機能画関係する性能評価で、
追記型アーキテクチャとVACUUM（自動VACUUM）
HOT（Heap-Only Tuples）
表・索引の領域拡張
について言及
遅延VACUUMの効果を600同時セッションにて効果の有無を検証されており非常に参考になった。
自動VACUUMで発生する性能低下が遅延VACUUM機能により抑制されることが確認できた。
HOTは索引更新が頻繁に発生する場合の性能低下をアイテムポインタというリンクを用いることで索引更新を抑制する。
HOTなしのPostgreSQL8.2とHOTが機能するPostgreSQL9.0での比較があり良好な性能を発揮している。
HOTの存在、構造、意味をキーワードでしか知らなかったが、今回のセミナーでよく理解できた。
表・索引の領域拡張については
複数セッションによる同一表への書き込み時の性能低下とその対策例が検証されていた。
対応状況ログ表に同時に1400同時セッションインサート要求あった場合の例で、
TPS（1秒あたりのトランザクション数）の落ち込みがみられる。
正常な処理が、7分経過頃ほとんど動かない状態になり、1分程度で回復する。
対処法としてあらかじめ対応状況のログ表の領域を確保した状態とする。
（対応状況ログ表にダミーデータを挿入し表末尾の行データのみを残して、行削除）
により、対応状況ログ表の拡張競合は解消（ゼロ）
自分の環境では、今のところ100セッションにも満たないので、起こらないだろうが、
一応記憶に留めておこう。
その他、スケーラビリティ、共有バッファのチューニング、
600同時セッションでの48時間継続運転でのTPM推移の検証
自動VACUUMと遅延VACUUM、HOT機能により、長時間運転に安定した性能を確認できた。
PostgreSQLでの高可用性データベース・システム構築手法とは?!
のセッションでは、Pgpool-II、Slony-I、Worm Standby、Hot Standby、StreamingReplication
などの組み合わせでの性能評価、障害検証のレポートがあったが、
どれも、決定的な「うまい・やすい・はやい」の印象はなく。
気軽に使えるものではなさそうだ。
自分の環境では、日々の自動バックアップを確実にする程度で十分だ。
止められないシステムは、それなりにコストが掛り、
復旧時の手順を明確にしておかなければならない。
危機的な事態に正確に回復できるか困難な問題が多い。
安易な導入はかえって命取りになる。
Pgpool-II、Slony-I、その他の個別の機能を整理して理解できたのはありがたかった。
