PostgreSQLの運用・監視にまつわるエトセトラ

Copyright © 2015 NTT DATA Corporation
中国地方DB勉強会
2015年4月18日
NTTデータ
PostgreSQLの運用・監視にまつわるエトセトラ

2Copyright © 2015 NTT DATA Corporation
本日お話すること
PostgreSQLの運用・監視にまつわるポイントを、
実例を交えてお話します
細かい話は既存資料にお任せします
運用面で頼りになるツールの紹介や、出来立ての
新機能について触れます

Worth to read
本日の話の穴埋めを(きっと)してくれる資料です
[PostgreSQLバックアップことはじめ]
http://www.slideshare.net/satock/29shikumi-backup
[PostgreSQLのリカバリ超入門]
http://www.slideshare.net/suzuki_hironobu/recovery-11
[明日から使えるPostgreSQL運用管理テクニック(監視編)]
http://www.slideshare.net/kasaharatt/postgre-sql-26186128
[OSS-DB Exam Gold 技術解説無料セミナー]
http://www.oss-db.jp/news/event/image/20130615_01.pdf
[PostgreSQL 安定運用のレシピ]
http://www.slideshare.net/noriyoshishinoda/postgresqlconference-2014-hands-on-
2-shinoda-201412061
[PostgreSQL Internal]
http://www.postgresqlinternals.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E
3%83%9A%E3%83%BC%E3%82%B8

運用管理あれこれ
■ 監視・レポート
死活監視
リソース監視・性能監視
稼働統計情報監視
■ サービス管理
停止/再起動
フェイルオーバ/フェイルバック
プロモート
■ バックアップ/リストア
バックアップ
PITR
■ 性能維持
メンテナンスコマンド実施
■ 性能分析/トラブルシュート
クエリキャンセル/プロセス停止
ボトルネック調査
スロークエリ解析
実行計画解析
■ アップデート
(セキュリティ)アップデート
アップグレード
などなど・・・・

本日触れるところ
死活監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析

仕組みを意識したメンテナンス
死活監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• VACUUMの効用と副作用をおさえてる？

VACUUMの効用・副作用あれこれ
• VACUUMの主な効用
• テーブル/インデックスをスキャンし、ガベージ(不要領域)を回収する
• 初回のVACUUMはテーブルのフルスキャンを行いVM(Visibility Map)作成
• VMは更新処理(UPDATE/DELETE)で更新される
• 以降は、VMを見て必要なところだけVACUUM
• 回収領域はFSM(FreeSpaceMap)に登録し、INSERTやUPDATEに使う
• ガベージが無くなったページはVMのビットを立ててステータスを最新化
テーブルテーブルテーブル
VM VM VM
初回VACUUMは
全体スキャンして
VM最新化
更新処理
VMも更新
次のVACUUMは
部分スキャンして
VM最新化

VACUUMの効用・副作用あれこれ
• VACUUMの主な副作用
• テーブルやインデックスデータのread/write負荷
• VMの最新化に伴う IOS(Index-Only-Scan) の性能向上
• IOSはVMのビットが立って入れば、ヒープ(テーブル)は見ない
• ガベージ回収に伴うWAL出力
• ページ内のデータ変更が実施されるため
テーブルテーブルテーブル
VM VM VM
テーブルとかイン
デックスをread
IOSの性能
向上
回収対象ページは
書き込む。
ついでにWALも。

VACUUMの実施方法(autovacuum)
• VACUUMの実施方法は、手動と自動の2つ
• 実施契機の閾値はテーブル毎に設定可能
PostgreSQL
autovacuum
launcher
システムビュー
テーブルB
テーブルA
autovacuum
worker
autovacuum
worker
各テーブルのガベー
ジや更新回数などを
保持監視
fork
VACUUM
ANALYZE
workerは複数起動が
可能
VACUUMの計画や実施ジョブを組む必要はない
基本はautovacuumでOK
しかし、巨大なテーブルへのVACUUMが繁忙期に実施されるリスク

VACUUMについて考えること
• 更新が無いテーブルでも、VMメンテが必要
• Index-Only-Scanに頼っている場合は特に
• DWHな用途でも、VACUUMが必要かも
• WAL(トランザクションログ)の出力量に気を付ける
• アーカイブログ容量やレプリの設計にご注意
• メンテナンス時のバーストするかも
• autovacuumに任せるもの、任せないもの
• 基本はautovacuumでOKだけど・・
• 巨大なテーブルはautovacuumだと危ないかも

【実例】 VACUUMの手動と自動を使い分け
～数GBの
小規模テーブ
ル
数百GB以上の
大規模テーブル
システム性能への影響小
→auto vacuumに任せる
システム性能への影響
→メンテナンス枠にて手動
で実施
VACUUM
24時間DBアクセス
昼夜問わず大量バッチ
システムへの影響をミニマムに！

仕組みを意識したメンテナンス
死活監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• メンテナンスのロックを意識している？

排他ロックを取るメンテナンス
• 排他ロック(Access Exclusive Lock)は
業務処理を停めてしまう
• VACUUM FULL/CLUSTER
• テーブルの物理圧縮/物理再編成
• 物理サイズの圧縮をしたい時によく使う
• テーブルに排他ロックを取る処理
• REINDEX
• インデックスの再作成
• 断片化したインデックスのリフレッシュに使う
• インデックスに排他ロックを取る処理
• というかシステムカタログにロックを取るので、
planner処理内でロック待ちになる

排他ロックを取るメンテナンス
• おまけ
• ALTER TABLE … ADD COLUMN … DEFAULT x
• テーブルに新規列(デフォルト値あり)追加
• デフォルト値なし(NULL)の場合、システムカタログの
更新だけなので一瞬で終わる
• でも DEFAULT NULL と明記すると再作成、という罠が
ある
• テーブルの再作成
• ALTER TABLE … SET TABLESPACE x
• テーブルを異なるテーブルスペースに移動
• テーブルの再作成

【実例】システムを停めないメンテを考える
外部モジュールと便利なコマンド
pg_reorg
オンラインVACUUM FULL
オンラインCLUSTER
自作ツール
CREATE INDEX
CONCURRENTLY
VACUUMができなかったら？
インデックスが荒れてしまったら？
排他ロック要らず！

【参考】 pg_reorg
• pg_reorg はテーブルを再編成し、断片化を解消する
• 近い将来、pg_repack に置き換わる(マージされる)かも
• 再編成処理の間も参照/更新処理をブロックしないことが特徴
年に一度のメンテナンスでも DB を止めずに運転が可能
VACUUM不足による肥大化からもサービスを止めずに回復可能
ついでにインデックスも再作成(REINDEX)します
対象テーブル
操作ログ表に記録
INSERT
UPDATE
DELETE
作業テーブル
並び替え
操作反映テーブルを切り替え
差分を反映し
更新結果を
引き継ぎ
切り替えは一瞬
(ロック期間は数秒)

クエリキャンセルとプロセス停止
死活監視
統計情報監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• 正しいキャンセルしていますか？

正しいクエリ/プロセスの停め方
• あるクエリが終わらないとか VACUUMを停めたいとか
• kill -SIGKILL <pid> or kill -9 <pid> は絶対にダメ
• PostgreSQLは、バックエンドプロセスがSIGKILLを受け取った場合、
全プロセスを落として、共有メモリをリフレッシュする
• いわば、クラッシュリカバリとなる
シグナルファンクション
クエリキャンセル SIGINT SELECT pg_cancel_backend(pid);
プロセスの停止 SIGTERM SELECT pg_terminate_backend(pid);

【実例】不要な idle in transactionの停止
開発環境にて、作法の悪いセッションがあった
トランザクションを開始して終わらないもの
≒ 長時間 idle in transaction でいるものとか・・・
⇒ これらはVACUUMの阻害やDDL競合となり厄介
というわけで
psql –At –c ¥
“SELECT pid FROM pg_stat_activity
WHERE now() – xact_start > interval ’30 min’” ¥
| xargs kill –SIGTERM
的な感じで作法の悪いものは切断
開発環境といえども運用は大変・・・

監視をする
死活監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• PostgreSQLで取得してる情報と
してない情報、知ってます？

PostgreSQLから取得できる性能情報
DB内で実施された処理の情報(稼働統計情報)はかなり細かく記録している
• テーブル
• 表スキャン、インデックススキャンの回数とフェッチ行数
• INSERT/UPDATE/DELETE対象の行数
• (auto)VACUUM/ANALYZEの回数と最後の実施時間
• 共有バッファにHITした回数、HITしなかった回数
• インデックス
• インデックススキャン、ビットマップスキャンの回数とフェッチエントリ数
• 共有バッファにHITした回数、HITしなかった回数
• SQLとファンクション
• 各SQLの実施回数、累積レスポンス時間、レスポンスのMIN/MAXなど(NEW!)
• DDLやVACUUMも含む
• 各ファンクションの実施回数、累積レスポンス時間

PostgreSQLから取得できない性能情報
• プロファイラ情報
• OracleのTop 5 Timed Event など
• インスタンス単位のネック候補を簡単に探る方法が無い
• どうする？
→ perf を入れておくと幸せになるかも！
• I/Oやメモリの使用状況に関する情報も無い
• 各テーブルやインデックスへの実I/O量を直接知る手段なし
• どうする？
→ sar とか iostat との組み合わせで推測する
→ 各テーブルスペースを駆使するとよい！かも

【実例】 perf が役に立った件(1)
ある日DBサーバのCPUが高騰、しかしログとか何も出ていない
perf topの状況を見ると、PostgreSQL以外に原因がありそう
■perf top結果(一部抜粋)
320878.00 29.0% SpinPause /usr/java/…/libjvm.so
187781.00 17.0% _spin_lock_irq [kernel.kallsyms]
143784.00 13.0% read_hpet [kernel.kallsyms]
109362.00 9.9% ParallelTaskTerminator /usr/java/…/libjvm.so
35295.00 3.2% native_write_msr_safe [kernel.kallsyms]
33563.00 3.0% intel_idle
25783.00 2.3% _spin_lock
19725.00 1.8% _spin_lock_irqsave
11848.00 1.1% find_busiest_group
2835.00 0.3% compaction_alloc [kernel.kallsyms]
2782.00 0.3% unmap_vmas [kernel.kallsyms]
2603.00 0.2% rb_next
• 調べてみるとRHEL6.2にあったTransparent Huge Page(THP)の
バグを踏んでいたよう
• THPを無効にすることによりCPUのsys高騰が解消した

【実例】 perf が役に立った件(2)
INSERT主体のワークロードで性能が伸び悩んだ際に、perf実施
PostgreSQLの内部処理競合がネックだった・・
Overhead Command Shared Object Symbol
7.39% postgres postgres [.] s_lock
3.49% postgres postgres [.] GetSnapshotData
2.62% postgres postgres [.] AllocSetAlloc
2.49% postgres postgres [.] base_yyparse
2.36% postgres postgres [.] SearchCatCache
1.92% postgres postgres [.] core_yylex
1.88% postgres [kernel.kallsyms] [k] _spin_lock
1.85% postgres postgres [.] XLogInsert
1.59% postgres postgres [.] LWLockAcquire
1.12% postgres postgres [.] hash_search_with_hash_value
1.07% postgres postgres [.] LWLockRelease

【実例】テーブルスペースとI/O
テーブルスペースを複数つくり、I/O分散しておいた
ところが、想定外にアクセスがあり、特定のテーブルスペースに負荷が偏った
細かくテーブルスペースを区切って異なるパーティションに配置していたので
Iostatで確認できた
→ 別の予備テーブルスペースに一部のテーブルを移動
Tblspc_1
Tblspc_2
Tblspc_3
PostgreSQL
Tblspc_1
Tblspc_2
Tblspc_3
PostgreSQL
Tblspc_new
IRR I
IR
R I

いざという時のために
死活監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• 入れておくと便利なモジュール、
あるんですよ？

PostgreSQLには、内部のHookを使うcontribモジュールがある
これらはとても有用なものばかり
shared_preload_libraries パラメータにモジュール名を付与して、
PostgreSQLを再起動すると有効になる
ExecutorStart_hook ExecutorEnd_hook
queryDesc->totaltime =
InstrAlloc(…)
②処理をフック
③モジュール内処理
(計測開始など)
④通常処理へ
⑤ 通常のExecution
① Execution 開始 ⑥Execution 終了
InstrEndLoop(queryDesc-
>totaltime)
⑦処理をフック
⑧モジュール内処理
(計測整理と記録など)
⑨通常処理へ
(参考)Hookを使うモジュールの動き

PostgreSQLを再起動すると有効になる
しかし本番環境やシビアな試験環境ではおいそれと再起動もできない・・・
と言って、必要そうなもの全部を仕込むとログ量とか大変・・・
こういう時は、モジュールを無効にした状態で仕込んでおいて、
必要な時に有効にすると良い
大抵の場合、xxxxx_enabled = [on | off] がある
off <-> on は reload (SIGHUP)で良いので気楽にできる
ExecutorStart_hook ExecutorEnd_hook
if (! xxxx_enabled)
return;
②処理をフック
③モジュール内処理
(無効なら何もしない)
④通常処理へ
⑤ 通常のExecution
① Execution 開始 ⑥Execution 終了
if (! xxxx_enabled)
return;
⑦処理をフック
⑧モジュール内処理
(無効なら何もしない)
⑨通常処理へ

どれを入れておくか？
以下の３つはおススメ
1. pg_stat_statements
 実行されたSQLの回数や累積所要時間が取れる
 SQLごとのキャッシュヒット率とかもわかる
 PostgreSQL 9.5 からはレスポンスのMIN/MAX/MEAN/STDDEVもわかる！
2. auto_explain
 指定時間以上かかったSQLの実行計画をログに出す
 実行計画が変わったことによる性能劣化が分かりやすい！
 試験時の実行計画確認にも使える
3. pg_hint_plan
 実行計画を制御するモジュール
 OracleのHINT句相当のもの
 困ったときのチューニング用に！

【実例】 HINT句を活用
HINT句を使い直接実行計画を制御することで、
迅速なSQLチューニングを可能に
○ HINT句を使用するメリット
 SQLを書き換えるよりも改修時間が短い！
• 使用するインデックスやスキャン方法を変えるだけ
 SQLの実行結果の内容は変わらない！
• HINTを付与するだけなので、SQLのリテスト不要
/*+ IndexScan(hoge) */
SELECT * FROM hoge
WHERE id = 9999;

【実例・小ネタ】 auto_explain で実行計画確認
試験時に特定の処理の実行計画だけ知りたい、しかし・・・
APには手を入れられない
一つのインスタンスに数十のDB
多数の試験が並行して実施中
postgresql.confで auto_explain.enabled = on で reload すると大変なことに・・・
ところで、reload って何しているの？
postgres
(親玉プロセス)
postgres
(バックエンドプロセス)
postgres
reloadコマンド
(内部ではSIGHUPを
親玉に飛ばす)
postgresql.conf
SIGHUP
SIGHUP
読みこみ
読みこみ
こいつだけ変えたい

【実例・小ネタ】 auto_explain で実行計画確認
では、postgresql.confを書き換えて、特定のプロセスにだけSIGHUP送ろう
実行計画を変えたいプロセスは幸い、DBユーザが ‘xxx’ で識別できたので・・
$ psql –At –c “SELECT pid FROM pg_stat_activity WHERE usename = ‘xxx’ ¥
| xargs kill –SIGHUP
的な方法で何とかしました
postgres
(親玉プロセス)
postgres
postgres
postgresql.conf
SIGHUP
読みこみ
よっしゃ

監視を助けてくれるツール
死活監視
統計情報監視
停止/再起動
プロモート
バックアップ
PITR
■ 性能維持
実行計画解析
• たくさん取れるけど面倒ですよね？

pg_statsinfo あります
PostgreSQLのインスタンスにエージェントが常駐
定期的にPostgreSQLから稼働統計情報を収集し、スナップショットとして保存
2つのスナップショット差分から、当該期間の性能レポートを生成する

pg_statsinfo のいいところ
1. 導入と運用が楽
 RPM入れて、postgresql.confを書くだけ
 PostgreSQLを再起動すれば監視開始
 古いスナップショットの削除も自動でやる
2. ハードウェアリソースも取得してくれる (Linuxのみ)
 sar相当の情報を自前で収集してレポートする
 PostgreSQLの稼働統計情報と一緒にCPU使用率とかも確認できる
3. ログ制御
 ログからもautovacuumやcheckpoint情報を抽出
 エラーレベルごとにsyslogとPostgreSQLのサーバログへルーティング
 性能情報からALERTログも出す
NTTデータをはじめ、NTT-Gが手掛けるシステムの
PostgreSQLの大部分をpg_statsinfoが監視しています
ツール詳細は↓の資料
https://www.postgresql.jp/events/jpug-pgcon2013-
files/B1_jpugpgcon2013_slide

Hinemos はいかがですか
標準の監視種別
PING監視
システムログ監視
Hinemosエージェント監視
HTTP監視
プロセス監視
リソース監視
SQL監視
SNMP監視
SNMPTRAP監視
ログファイル監視サービス・ポート監視
カスタム監視
Windowsサービス監視 Windowsイベント監視
選択
・監視対象
ノード
・通知設定
監視設定
ノード
・監視間隔:○分
・判定条件（閾値指定)
システム運用管理で要求される幅広い機
能を備えた統合運用管理ソフトウェア
ノード管理状態監視ジョブ制御
✔
✔
▲
パフォーマンス管理

SQL監視機能
管理対象ノード上のDBMSに対してSQLによる
問い合わせを発行し、SQL実行結果を取得・収集
実行結果が数値の場合は閾値監視、
実行結果が文字列の場合は、文字列監視を実行
管理対象機器
(DBサーバ)
通知
閾値監視
(数値)
②SQL実行
③SQL実行結果
(数値・文字列)
SQL監視
ＤＢ
JDBC
ドライバ
①SQL実行指示文字列監視
(文字列)
運用管理サーバ
Hinemosマネージャ
④
⑤通知
⑤
④SQL実行結果の
監視処理

Hinemos
エージェント
カスタム監視機能
システム個別のサービス・ミドルウェアを
ユーザ定義コマンドにて監視
監視結果を蓄積し、性能管理機能で確認可
能
コマンドコマンドコマンド
コマンドコマンドコマンド
コマンド
繰り返し実行
管理対象機器
①コマンド実行指示
Hinemosエージェント
カスタム監視
運用管理サーバ
Hinemosマネージャ
閾値監視
(数値)
通知
②コマンド実行結果
③通知
key.value

カスタム監視実行結果(例)
CSV
グラフ表示・分析レポート作成
アラート通知
例)PostgreSQL監視コマンドカスタム監視

ミドルウェア監視用スクリプト
Hinemosのパートナー企業による、カスタム監視機能を活用した取り組み
ミドルウェア特有の性能情報を監視するための、カスタム監視機能で実行可能なスクリプトを提供
ミドルウェア監視用スクリプト
種別ミドルウェア監視用スクリプト
動作概要
WEBサーバ Apache HTTP Server Apacheの各種監視
APサーバ Jboss Enterprise Application Platform JbossアプリケーションサーバのMbeanか
らJMVで各種統計情報を取得
Apache Tomcat Tomcatのアプリケーションの
状態監視
DBサーバ PostgreSQL PostgreSQLサーバ内部の性能・統計情
報格納テーブルからデータを取得
Oracle Database Oracleサーバの各種監視
MySQL MySQLサーバのステータス情報取得
および監視
http://atomitech.jp/hinemos/service/service_03/service_03_07/

pg_store_plans できました！
• オンザフライで実行計画をクエリ別に集計してくれるモジュール
• pg_stat_statementsと組み合わせで使う
• クエリの実行計画変化がさくっと分かる
• auto_explian に頼らなくても良い！
• 「pg_store_plans」で検索
=# SELECT substr(s.query, 1, 16), regexp_replace(p.plan, '¥([^¥)]*¥)', '', 'g'),
p.first_call::timestamp(0), p.last_call::timestamp(0),
p.calls, p.total_time, p.total_time/p.calls as avg
FROM pg_store_plans p JOIN pg_stat_statements s
ON (pg_store_plans_hash_query(s.query)) = p.queryid
WHERE s.query LIKE '%PGST_00001%’ AND p.calls > 0 ;
substr | regexp_replace | first_call | last_call | calls | total_time | avg
------------------+-------------------------------------------------+---------------------+---------------------+-------+------------+---------
/* PGST_00001 */ | Index Only Scan using tbl_idx on tbl +| 2015-04-10 19:05:19 | 2015-04-10 19:05:23 | 10 | 0.431 | 0.0431
| Index Cond: | | | | |
/* PGST_00001 */ | Seq Scan on tbl +| 2015-04-10 19:05:28 | 2015-04-10 19:05:32 | 10 | 158.262 | 15.8262
| Filter: | | | | |
(2 rows)

おわりに
PostgreSQLはかなり成長していますが
運用がやや面倒なのは否めない・・・
→ そんな時は、外部モジュールの力を借りましょう
仕組みを意識すると、応用の効いた運用ができます
運用は設計時点から始まっています！
こんなこともあろうかと、な手段を準備しておきましょう！

ご清聴ありがとうございました！

PostgreSQLの運用・監視にまつわるエトセトラ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à PostgreSQLの運用・監視にまつわるエトセトラ

Similaire à PostgreSQLの運用・監視にまつわるエトセトラ (20)

Plus de NTT DATA OSS Professional Services

Plus de NTT DATA OSS Professional Services (20)

Dernier

Dernier (8)

PostgreSQLの運用・監視にまつわるエトセトラ