|
必聴講座ご紹介 Cloud Days Tokyo 2012 エムオーテックス Cloud Days Tokyo 2012 ヴイエムウェア Cloud Days Osaka 2012 アマゾン データ サービス ジャパン |
|
| 設定項目 | デフォルト値 | 説明 |
| autovacuum | FALSE | trueならばautovacuumを有効にする |
| autovacuum_naptime | 60 | autovacuumを起動する間隔を秒単位で指定 |
| autovacuum_vacuum_threshold | 1000 | VACUUMを起動するトリガとなる更新行数 |
| autovacuum_analyze_threshold | 500 | ANALYZEを起動するトリガとなる更新行数 |
| autovacuum_vacuum_scale_factor | 0.4 | VACUUMを起動するトリガとなる更新行数の割合 |
| autovacuum_analyze_scale_factor | 0.2 | ANALYZEを起動するトリガとなる更新行数の割合 |
|
| 図1●autovacuumの効果 |
いつものように,縦軸はTPS(Transaction Per Second)で,1秒間に実行したトランザクション数を示す。したがって数字が大きいほど性能が良いことになる。横軸はpgbenchの実行回数である。pgbenchは以下のように起動した。
pgbench -n -c 10 -t 500
同時接続数は10で,それぞれの接続ごとに500個の更新トランザクションを実行する。したがって,1回のpgbenchの起動でトータル5000回のトランザクションが実行される。
autovacuumが有効な場合は,多少性能にでこぼこはあるものの,100TPS前後の性能を維持していることが分かる。
一方autovacuumが有効になっていない場合は,徐々に性能が低下し,最終的には当初の半分程度の性能になってしまった。これは,更新が行われることによってテーブルに不要領域が溜っていくからである。このデータからもVACUUMの必要性が分かる。
PostgreSQLに対する誤解で最も多いものの一つが,「PostgreSQLは使っていくうちに性能が低下する」というものである。VACUUMを適切に実行していないケースではこうした誤解が生じる。VACUUMはPostgreSQL 固有の操作であり,特に他のDBから移行してきたユーザーにとってはVACUUMが落とし穴になり易いのも事実である。autovacuumが正式にサポートされたことにより,こうした誤解や運用ミスが少くなることが期待される。
ただ,autovacuumを使用するにあたっては実行統計情報の取得自体に一定のオーバヘッドがあることに注意したい。環境にもよるが,筆者の経験では,10-20%程度性能への影響が見られた。
ではautovacuumが使えないかというと,まったく逆である。VACUUMを適切に運用できない場合,性能の低下は20%どころではなく,ときには50%以上にもなる。熟練したPostgreSQL管理者を用意できないような環境では,autovacuumを使って一定の性能を維持できるメリットは非常に大きいと言える。
次に,ローカル・バッファとマルチカラム・インデックス,テーブル・パーティショニングを紹介しよう。