« ヒアリング能力を鍛えるには? | トップページ | gemとかPROXY経由で使えるんじゃン »

2014.10.31

PostgreSQLでファイルサイズ容量を見積もるときの注意

DBの必要とするディスク容量を計算する際に、誰でもやるのは各テーブルの必要ファイルサイズの合算と、伸び率を加味したボリューム算出、というところであろう。
もちろんこれが基本になるわけなのだが、他のDBでも共通の注意事項とPostgreSQL特有の注意事項があることに注意。

●インデックスをお忘れなく
まずどのDBでも共通でたまに忘れる人がいるのはインデックスの存在である。
いや、これ本気で忘れる人がいるんですよ……
ただインデックスはテストや本番稼働を見ながらどうしても追加削除の調整が発生するので、初期のサイジング時点ではきちんとしたサイズ見積もりをすることは難しいかもしれない。
とはいえ、PostgreSQLのインデックスはけっこうサイズをとるので、実テーブルのサイズに応じた容量を見積もっておかないといかんです。

●ページサイズをお忘れなく
これもどのDBでも考え方は共通かな?
PostgreSQLでは原則1テーブル/1インデックスごとに1ファイルが割り当てられて、かつ1ページが8KBである。なのでデータの変動があった場合は8KB単位で増加していく。
また1ファイルの上限は1GB(デフォルト:変更可能)なので、1GBを超える場合には同一テーブルであってもファイル分割が起こる。
1レコードが8KB超える場合? そのときにTOASTが使われ、これも容量検討の対象となる。

●Fillfactorにも注意
あとHOT更新をサポートするために、fillfactorが指定されたテーブル/インデックスはそのパラメータに応じた空きを確保することも注意が必要。
FILLFACTORを変更した瞬間ではテーブルサイズには変化が出ないが、今後の更新処理においてはfillfactorに応じた領域を確保していくので、実際のサイズに対してfillfactorを加味した分だけサイズが大きく育っていくことに注意である。また、忘れがちだが明示的にfillfactorを設定しなくとも、インデックスはfillfactor=90になっているので、必然的にインデックスは大きめになる。

●なんといってもMVCCなので。。。
HOTとAutoVACUUMが実装されて肥大化が抑制されるようになってきたとはいえ、VACUUMされるまでは領域肥大が起きる仕様なのは忘れてはならない。
AUTOVACUUMのデフォルトは20%なので、計算結果x1.2は最小限見積もっておかないと容量不足、ということになりかねないので注意が必要である。

●pg_xlogの見積もりも忘れずに!
上記まではデータ実体であるpg_dataのすぐ下にあるデータが対象であったが、WALの書き込まれる領域容量もサーバのサイジングとしては必要である。
WALがどれだけたまるかは、そのシステムの更新等の頻度とcheckpointの設定によって変化がある。
16MB x (Checkpoint_segments + 1) が算出計算式になる。
pg_xlogの領域はサイジング自体では大きな影響はないだろうが、アーカイブ処理の実施等でワーク領域が必要になるオプション等もあるので、アーカイブ失敗やリトライ、ワーク作業を想定したボリュームを見積もっておくほうがいいだろう。特にpg_xlogに対してクォート制約をかけようと考えている場合は要注意だ。

|

« ヒアリング能力を鍛えるには? | トップページ | gemとかPROXY経由で使えるんじゃン »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/60571890

この記事へのトラックバック一覧です: PostgreSQLでファイルサイズ容量を見積もるときの注意:

« ヒアリング能力を鍛えるには? | トップページ | gemとかPROXY経由で使えるんじゃン »