Más contenido relacionado La actualidad más candente (20) Similar a PostgreSQL安定運用のコツ2009 @hbstudy#5 (20) PostgreSQL安定運用のコツ2009 @hbstudy#52. アジェンダ
• パフォーマンスと初期設定
• データベースの監視
• 性能劣化とメンテナンス
• パフォーマンスチューニング(GUC編)
• パフォーマンスチューニング(SQL編)
• バックアップ&リカバリ
本日の資料は http://slideshare.net/uptimejp にアップしてあります。
Copyright 2009 Uptime Technologies LLC, All rights reserved.
4. PostgreSQLプロセス構造
• PostgreSQL 8.4の場合
[snaga@devpg01 ~]$ ps -aef | cat | grep ^snaga
snaga 5282 1 0 20:15 tty1 00:00:00 /usr/local/pgsql/bin/postgres -
D ./pgdata
snaga 5283 5282 0 20:15 ? 00:00:00 postgres: logger process
snaga 5285 5282 0 20:15 ? 00:00:05 postgres: writer process
snaga 5286 5282 0 20:15 ? 00:00:01 postgres: wal writer process
snaga 5287 5282 0 20:15 ? 00:00:00 postgres: autovacuum launcher process
snaga 5288 5282 0 20:15 ? 00:00:00 postgres: archiver process archiving
000000010000000000000059
snaga 5289 5282 0 20:15 ? 00:00:00 postgres: stats collector process
snaga 28467 6806 1 20:26 pts/0 00:00:06 pgbench -i -s 100 pgbench2
snaga 28468 5282 11 20:26 ? 00:00:57 postgres: snaga pgbench2 [local] COPY
snaga 28728 6806 0 20:27 pts/0 00:00:01 pgbench -c 8 -t 1000 -s 10 pgbench
snaga 28756 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] COMMIT
snaga 28757 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] INSERT
snaga 28758 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] UPDATE
snaga 28759 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] COMMIT
snaga 28762 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] COMMIT
snaga 28763 5282 0 20:27 ? 00:00:00 postgres: snaga pgbench [local] UPDATE
waiting
snaga 31381 5288 0 20:34 ? 00:00:00 /bin/cp
pg_xlog/000000010000000000000059
/home/snaga/pgdata/pg_xlogarch/000000010000000000000059
[snaga@devpg01 ~]$
Copyright 2009 Uptime Technologies LLC, All rights reserved.
5. PostgreSQLデータディレクトリ構造
• PostgreSQL 8.4の場合
[snaga@devpg01 ~]$ ls -l pgdata
total 148
drwx------ 8 snaga snaga 4096 Nov 5 20:26 base
drwx------ 2 snaga snaga 4096 Nov 5 20:26 global
drwx------ 2 snaga snaga 4096 Nov 5 20:01 pg_clog
-rw------- 1 snaga snaga 3652 Nov 5 20:01 pg_hba.conf
-rw------- 1 snaga snaga 1631 Nov 5 20:01 pg_ident.conf
drwx------ 2 snaga snaga 4096 Nov 5 20:15 pg_log
drwx------ 4 snaga snaga 4096 Nov 5 20:01 pg_multixact
drwx------ 2 snaga snaga 4096 Nov 5 20:33 pg_stat_tmp
drwx------ 2 snaga snaga 4096 Nov 5 20:01 pg_subtrans
drwx------ 2 snaga snaga 4096 Nov 5 20:01 pg_tblspc
drwx------ 2 snaga snaga 4096 Nov 5 20:01 pg_twophase
-rw------- 1 snaga snaga 4 Nov 5 20:01 PG_VERSION
drwx------ 3 snaga snaga 4096 Nov 5 20:33 pg_xlog
lrwxrwxrwx 1 snaga snaga 23 Nov 5 20:08 pg_xlogarch -> /home/snaga/pg_xlogarch
-rw------- 1 snaga snaga 16807 Nov 5 20:13 postgresql.conf
-rw------- 1 snaga snaga 46 Nov 5 20:15 postmaster.opts
-rw------- 1 snaga snaga 46 Nov 5 20:15 postmaster.pid
[snaga@devpg01 ~]$
Copyright 2009 Uptime Technologies LLC, All rights reserved.
6. PostgreSQLの構成
• さまざまなプロセス・メモリ領域・ファイルによって構成され
る
writer
postmaster logger wal writer autovacuum
(バックグラウンド
(リスナプロセス) (サーバログ) (WALライタ) (自動vacuum)
ライタ)
プロセス群
archiver stat collector postgres
(WALアーカイバ) (統計情報収集) (サーバプロセス)
shared_buffers wal_buffers freespacemap トランザクション
メモリ群 (共有バッファ) (WALバッファ) (空き領域情報) 制御情報
ファイル群 テーブル インデックス トランザクション アーカイブ
設定ファイル
ファイル ファイル ログファイル ログファイル
Copyright 2009 Uptime Technologies LLC, All rights reserved.
7. PostgreSQLのアーキテクチャ
• 共有バッファを中心として、複数のプロセス間で連携しな
がら処理を行うマルチプロセス構造
postmaster
(リスナプロセス)
(
shared_buffers
postgres 共
クライアント 有
(サーバプロセス) バ
ッ
フ
ァ
)
writer
(バックグラウンド
ライタ)
トランザクション
ログファイル
テーブル
ファイル
インデックス
ファイル
Copyright 2009 Uptime Technologies LLC, All rights reserved.
8. PostgreSQLのファイル種別
• テーブルファイル
– レコードの実データを保存
– タプル(行)単位で、テーブルファイルに追記
• インデックスファイル
– インデックスのキーとレコードへのポインタを保持
– ツリー構造を持つ(ルート、インターナル、リーフ)
• トランザクションログ
– テーブルやインデックスの更新情報を追記
– リカバリの際に使用される
Copyright 2009 Uptime Technologies LLC, All rights reserved.
10. インデックスファイル
• ツリー構造を持つ
– 各ノードが、8kBのブロックに相当
– ルートノードから辿っていく
– リーフノードは、テーブルファイルの実タプルへのポインタを持つ
インデックスファイル テーブルファイル
レコード1
レコード2
レコード3
レコード4
レコード5
1~5 6~10 11~17 18~25
Copyright 2009 Uptime Technologies LLC, All rights reserved.
11. トランザクションログ
• 更新情報を記録していく(追記)
– 1セグメント16MB。使い終わると次のファイルへ
– リカバリの際に読み込まれる
– pg_xlog/ 以下に配置
– 「Write Ahead Log(WAL)」とも呼ばれる
Aテーブルのレコード1をmに変更
Bテーブルのレコード6をnに変更
Aテーブルのレコード4をxに変更
Aテーブルのレコード1をyに変更
Bテーブルのレコード2をzに変更
ファイルの先頭から
順番に更新情報が
追記されていく
Copyright 2009 Uptime Technologies LLC, All rights reserved.
12. RDBMSで発生するファイルI/O
• さまざまなパターンのファイルI/Oが発生する
– 例えば、プライマリキーで検索してレコードを更新する場合
ひとつの物理ディスク
テーブルファイル
テーブルファイル ②読む
テーブルファイル
④書く
ディスク
ヘッド
①読む
インデックスファイル
インデックスファイル
インデックスファイル
③書く
トランザクション
ログファイル
Copyright 2009 Uptime Technologies LLC, All rights reserved.
13. アクセスパターン
• シーケンシャルアクセス
– 全レコード、または多くのレコードを処理する必要がある場合(集約処
理、LIKE文の中間一致など)
• ランダムアクセス
– 主にインデックスを用いたアクセス
シーケンシャル ランダム
アクセス アクセス
ファイルの先頭から
順番に読み込んでいく 必要なレコードだけ
ピンポイントで読み込む
テーブルファイル テーブルファイル
Copyright 2009 Uptime Technologies LLC, All rights reserved.
14. 共有バッファとは
• ディスク上のブロックをキャッシュするメモリ領域
– ディスクI/Oを抑えるための機構
postmaster
(リスナプロセス)
(
shared_buffers
postgres 共
クライアント 有
(サーバプロセス) バ
ッ
フ
ァ
)
writer
(バックグラウンド
ライタ)
トランザクション
ログファイル
テーブル
ファイル
インデックス
ファイル
Copyright 2009 Uptime Technologies LLC, All rights reserved.
15. 共有バッファ
• ディスク上のブロックをキャッシュするメモリ領域
– 読み書きともにキャッシュすることで高速化を図る
• すべてのバックエンドプロセスで共有
• 8kB単位で管理
– postgresql.conf の shared_buffers でサイズ指定
postgres
postgres
postgres 共有バッファ
バックエンド
ディスク
Copyright 2009 Uptime Technologies LLC, All rights reserved.
16. レコード量とデータサイズ
• Pgbenchのaccountsテーブルのサイズ
– 10万レコードの場合、15MB
– 100万件レコードの場合、148MB
pgbench=# SELECT count(*) FROM
accounts;
count
10万レコードのcount --------
100000
(1 row)
Time: 107.818 ms
pgbench10=# SELECT count(*) FROM accounts;
count
---------
1000000
100万レコードのcount (1 row)
Time: 1009.377 ms
Copyright 2009 Uptime Technologies LLC, All rights reserved.
17. 初期設定
• 必ず変更すべき項目
– shared_buffers
– checkpoint_segments
– wal_buffers
• 変更を推奨する項目
– max_connections
– log_line_prefix
– stats_start_collector, stats_block_level, stats_row_level
• PostgreSQL 8.1 / 8.2 の場合
– track_activities, track_counts
• PostgreSQL 8.3 / 8.4 の場合
Copyright 2009 Uptime Technologies LLC, All rights reserved.
19. なぜ「監視」が重要なのか?
• PDCA(Plan-Do-Check-Action)を回すため
– データベースがきちんとサービスを提供しているか?
– 性能レベルが落ちていないか?
• 監視は「Action」につなげるための「Check」
– チューニングを行う
– ハードウェアの増強を行う
– メンテナンスを行う
• 「何のために、何を監視するのか」
– あらかじめ決めておくことが重要
Copyright 2009 Uptime Technologies LLC, All rights reserved.
20. 監視すべき項目とその方法
• データベースサイズ、テーブルサイズ
– データベースサイズ
• pg_database_size()関数
– テーブルサイズ
• pg_relation_size()関数、pg_total_relation_size()関数
• トランザクション量(論理I/O)
– コミット数、ロールバック数(データベース単位)
• pg_stat_databaseシステムビュー
– INSERT/UPDATE/DELETE数(テーブル単位)
• pg_stat_user_tablesシステムビュー
• ディスクI/O量(物理I/O)
– ブロック読み込み、キャッシュ読み込み(データベース単位)
• pg_stat_databaseシステムビュー
– ブロック読み込み、キャッシュ読み込み(テーブル単位)
• pg_statio_user_tablesシステムビュー
Copyright 2009 Uptime Technologies LLC, All rights reserved.
21. データベースサイズ、テーブルサイズの取得
• データベース、テーブルサイズ取得用関数
– pg_database_size()
– pg_relation_size()
– pg_total_relation_size()
• 使い方
– SELECT pg_database_size('データベース名')
– SELECT pg_relation_size('テーブル名')
Copyright 2009 Uptime Technologies LLC, All rights reserved.
22. データベースサイズ、テーブルサイズの取得(例)
dbt1=# SELECT pg_database_size('dbt1');
pg_database_size
------------------
5616124552
dbt1=# SELECT pg_relation_size('orders');
pg_relation_size
------------------
407257088
dbt1=# SELECT pg_total_relation_size('orders');
pg_total_relation_size
------------------------
504676352
Copyright 2009 Uptime Technologies LLC, All rights reserved.
23. トランザクション量の取得
• アクセス統計情報(システムビュー)
– pg_stat_database
– pg_stat_user_tables
• 使い方
– SELECT * FROM pg_stat_database
– SELECT * FROM pg_stat_user_tables
Copyright 2009 Uptime Technologies LLC, All rights reserved.
24. トランザクション量の取得(例)
t1=# SELECT * FROM pg_stat_database WHERE datname='t1';
-[ RECORD 1 ]-+---------
datid | 16384
datname | t1
numbackends | 1
xact_commit | 255038
xact_rollback | 35
blks_read | 4772
blks_hit | 53456459
tup_returned | 57235672
tup_fetched | 405515
tup_inserted | 135015
tup_updated | 121564
tup_deleted | 269
t1=# SELECT * FROM pg_stat_user_tables WHERE relname='pgbench_accounts';
-[ RECORD 1 ]----+------------------------------
relid | 16555
schemaname | public
relname | pgbench_accounts
seq_scan | 1
seq_tup_read | 100000
idx_scan | 265836
idx_tup_fetch | 265836
n_tup_ins | 100000
n_tup_upd | 33772
n_tup_del | 0
n_tup_hot_upd | 31394
n_live_tup | 100000
n_dead_tup | 0
last_vacuum | 2009-11-11 00:53:51.387782+09
last_autovacuum |
last_analyze | 2009-11-11 00:18:23.847632+09
last_autoanalyze |
Copyright 2009 Uptime Technologies LLC, All rights reserved.
25. 監視結果の可視化
• サンプルWebアプリを数日間実行し、その間のトランザク
ション数およびデータベースサイズを計測
データベースサイズとトランザクション数
740 1200
720
トランザクション数(TPM)
1000
700
DBサイズ (MB)
800
680
660 600
640
400
620
200
600
580 0
2006/5/4 2006/5/5 2006/5/6 2006/5/7
Copyright 2009 Uptime Technologies LLC, All rights reserved.
26. 有効にすべきGUC項目
• PostgrSQL 8.1/8.2の場合
– stats_start_collector 統計情報の収集を行う
– stats_command_string SQLコマンドの統計を取得する
– stats_block_level ブロック単位の統計を取得する
– stats_row_level 行単位の統計を取得する
• PostgreSQL 8.3/8.4の場合
– track_activities SQLコマンドの統計を取得する
– track_counts ブロック単位、行単位の統計を取得する
Copyright 2009 Uptime Technologies LLC, All rights reserved.
27. 【参考】pg_stat_databaseとpg_stat_user_tables
t1=# ¥x t1=# ¥x
Expanded display is on. Expanded display is on.
t1=# SELECT * FROM pg_stat_user_tables; t1=# SELECT * FROM pg_stat_database;
(...snip...) (...snip...)
-[ RECORD 1 ]----+------------------------------ -[ RECORD 4 ]-+----------
relid | 16555 datid | 16384
schemaname | public datname | t1
relname | pgbench_accounts numbackends | 1
seq_scan | 1 xact_commit | 255069
seq_tup_read | 100000 xact_rollback | 35
idx_scan | 265836 blks_read | 4772
idx_tup_fetch | 265836 blks_hit | 53457349
n_tup_ins | 100000 tup_returned | 57244317
n_tup_upd | 33772 tup_fetched | 405783
n_tup_del | 0 tup_inserted | 135015
n_tup_hot_upd | 31394 tup_updated | 121564
n_live_tup | 100000 tup_deleted | 269
n_dead_tup | 0
last_vacuum | 2009-11-11 00:53:51.387782+09 (...snip...)
last_autovacuum |
last_analyze | 2009-11-11 00:18:23.847632+09 t1=#
last_autoanalyze |
(...snip...)
t1=#
Copyright 2009 Uptime Technologies LLC, All rights reserved.
29. 性能劣化の原因
• データ量の増大
– 実データの増大
• データが蓄積されていくことによって、実際のデータ量が増大。
– 不要領域の増大
• データ量は増えていないが、追加・削除・更新を繰り返すことによって、
ディスクの利用効率が悪くなり、余計なI/Oが発生。
• 問い合わせ処理の増大
– 接続数の増大
– 処理処理の増大
Copyright 2009 Uptime Technologies LLC, All rights reserved.
30. 不要領域のできる仕組み
• あるトランザクションによってレコードが(論理的に)削除され
ると、「削除フラグ」が設定される
– 物理的にはディスク上に残る
• これは、複数のトランザクションからのレコードの可視性を制
御するためである。
– Multi-Version Concurrency Control (MVCC)
• よって、削除して不要になった領域は、事後的に「再利用可
能領域」として回収する必要がある。
– これが「VACUUM処理」
Copyright 2009 Uptime Technologies LLC, All rights reserved.
31. 追記型アーキテクチャ
レコード1 「レコード5」を追加 レコード1
レコード レコード2 レコード2
追加処理 レコード3 レコード3
レコード4 レコード4
(INSERT) レコード5
ファイル中に4件のレコードが
順番に並んでいる レコード5がファイル末尾に追加され、
ファイルサイズが増える
「レコード2」を削除
レコード1 レコード1
レコード レコード2 (レコード2)
削除処理 レコード3 レコード3
レコード4 レコード4
(DELETE)
ファイル中に4件のレコードが レコード2に削除マークが付けられる
順番に並んでいる
「レコード2」を
レコード1 「レコード2’」として更新 レコード1
レコード レコード2 (レコード2)
更新処理 レコード3 レコード3
レコード4 レコード4
(UPDATE)
レコード2’
ファイル中に4件のレコードが レコード2に削除マークが付けられ、
順番に並んでいる レコード2’が新たに追加、ファイルサイズ増加
Copyright 2009 Uptime Technologies LLC, All rights reserved.
32. データファイル不要領域率の確認
• テーブルの不要領域の確認
– pgstattuple関数を使う
• インデックスの不要領域の確認
– pgstatindex関数を使う
• 入手先
– pgstattuple関数
• contribのpgstattupleモジュール
– pgstatindex関数
• バージョン8.1の場合:以下から取得
http://www.pgperf.com/tools/pgstatindex
• バージョン8.2以降の場合:pgstattupleモジュールに同梱
Copyright 2009 Uptime Technologies LLC, All rights reserved.
33. pgstattuple使用方法
pgbench=# ¥x
Expanded display is on.
pgbench=# SELECT * FROM pgstattuple('accounts');
-[ RECORD 1 ]------+----------
table_len | 138739712
tuple_count | 1000000
tuple_len | 128000000
tuple_percent | 92.26
dead_tuple_count | 32000
dead_tuple_len | 4096000
dead_tuple_percent | 2.95
free_space | 2109248
free_percent | 1.52
Copyright 2009 Uptime Technologies LLC, All rights reserved.
34. pgstatindex使用方法
pgbench=# ¥x
Expanded display is on.
pgbench=# SELECT * FROM pgstatindex('accounts_pkey1');
-[ RECORD 1 ]------+---------
version | 2
tree_level | 2
index_size | 17956864
root_block_no | 361
internal_pages | 8
leaf_pages | 2184
empty_pages | 0
deleted_pages | 0
avg_leaf_density | 90.07
leaf_fragmentation | 0
Copyright 2009 Uptime Technologies LLC, All rights reserved.
35. 不要領域率とパフォーマンス
• 不要領域が増えるとパフォーマンスが落ちる
pgbenchスコアと不要領域率
(accountsテーブル)
350 25
300
20
トランザクション数/秒
250
不要領域率(%)
200 15
トランザクション数/秒
150 不要領域率
10
100
5
50
0 0
目
目
目
目
目
目
目
目
目
目
1回
2回
3回
4回
5回
6回
7回
8回
9回
回
10
pgbench実行回数 ※PostgreSQL 8.1での検証
Copyright 2009 Uptime Technologies LLC, All rights reserved.
37. VACUUM処理
VACUUM前 VACUUM後
レコード1 レコード1
(レコード2)
VACUUM処理
空き領域
VACUUM レコード3 レコード3
処理 レコード4 レコード4
レコード2’ レコード2’
レコード2に削除マークが レコード2の領域が「空き領域」として
付いている 再利用可能になる。
追記前 追記後
レコード1 レコード5を追記 レコード1
空き領域 レコード5
VACUUM レコード3 レコード3
してあると レコード4 レコード4
レコード2’ レコード2’
「空き領域」がある ファイルサイズを変えずに追記できる
レコード1 レコード1
レコード5を追記
(レコード2) (レコード2)
VACUUM レコード3 レコード3
してないと レコード4 レコード4
レコード2’ レコード2’
レコード2の領域が埋まったまま レコード5
ファイルサイズが増加
Copyright 2009 Uptime Technologies LLC, All rights reserved.
38. REINDEXとは
• インデックスを再作成する
– 不要領域のないインデックスが作られる
• REINDEXコマンド
– REINDEX TABLE <テーブル名>
– REINDEX DATABASE <データベース名>
Copyright 2009 Uptime Technologies LLC, All rights reserved.
39. メンテナンスの効果
• FULL VACUUMとREINDEXを実行
accountsテーブルサイズとpgbenchスコア
350 180
160
300
140
トランザクション数/秒
テーブルサイズ(MB)
250
120
200 100 トランザクション数/秒
150 80 テーブルサイズ(MB)
60
100
40
50
20
0 0
目
目
目
目
目
目
目
目
目
目
目
1回
2回
3回
4回
5回
6回
7回
8回
9回
回
回
10
11
pgbench実行回数
Copyright 2009 Uptime Technologies LLC, All rights reserved.
40. タプルの更新とインデックスの更新
8.3以前
インデックス付きカラム
ヒープタプル レコード1 レコード1
インデックスのない
(テーブル) レコード2 カラムを更新すると・・・ (レコード2)
レコード2’
エントリ1 エントリ1 インデックスサイズも
インデックス
エントリ2 (エントリ2) 増える
エントリ2’
8.3以降 インデックス付きカラム
ヒープタプル レコード1 レコード1
(テーブル) インデックスのない
レコード2 カラムを更新すると・・・
(レコード2)
レコード2’
エントリ1 エントリ1 インデックスサイズは
インデックス
エントリ2 エントリ2 増えない
インデックスの張られていないカラムを更新すると、
ヒープのみの(インデックスエントリが無い)カラムができる。
これが、HOT(Heap Only Tuple)
Copyright 2009 Uptime Technologies LLC, All rights reserved.
41. その他の情報
• VACUUMの自動化「autovacuum」
– 負荷状況を見ながら、VACUUMを自動実行する機能
• VACUUMの負荷分散「vacuum delay」
– Vacuumを「ゆっくり」実行する機能
Copyright 2009 Uptime Technologies LLC, All rights reserved.
44. Thank you.
質問またはコメントなどがある方は、
snaga@uptime.jp
または
twitter.com/uptimejp
まで、お気軽にご連絡ください。
Copyright 2009 Uptime Technologies LLC, All rights reserved.