![3Copyright © 2015 NTT DATA Corporation
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](https://image.slidesharecdn.com/postgresql-150423072326-conversion-gate01/85/PostgreSQL-3-320.jpg)
![2Copyright © 2015 NTT DATA Corporation
【実例】 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高騰が解消した](https://image.slidesharecdn.com/postgresql-150423072326-conversion-gate01/85/PostgreSQL-23-320.jpg)
![2Copyright © 2015 NTT DATA Corporation
【実例】 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](https://image.slidesharecdn.com/postgresql-150423072326-conversion-gate01/85/PostgreSQL-24-320.jpg)
![28Copyright © 2015 NTT DATA Corporation
いざという時のために
PostgreSQLを再起動すると有効になる
しかし本番環境やシビアな試験環境ではおいそれと再起動もできない・・・
と言って、必要そうなもの全部を仕込むとログ量とか大変・・・
こういう時は、モジュールを無効にした状態で仕込んでおいて、
必要な時に有効にすると良い
大抵の場合、xxxxx_enabled = [on | off] がある
off <-> on は reload (SIGHUP)で良いので気楽にできる
ExecutorStart_hook ExecutorEnd_hook
if (! xxxx_enabled)
return;
②処理をフック
③モジュール内処理
(無効なら何もしない)
④通常処理へ
⑤ 通常のExecution
① Execution 開始 ⑥Execution 終了
if (! xxxx_enabled)
return;
⑦処理をフック
⑧モジュール内処理
(無効なら何もしない)
⑨通常処理へ](https://image.slidesharecdn.com/postgresql-150423072326-conversion-gate01/85/PostgreSQL-28-320.jpg)
![4Copyright © 2015 NTT DATA Corporation
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)](https://image.slidesharecdn.com/postgresql-150423072326-conversion-gate01/85/PostgreSQL-41-320.jpg)
PostgreSQLの運用・監視にまつわるエトセトラ
- 1. Copyright © 2015 NTT DATA Corporation 中国地方DB勉強会 2015年4月18日 NTTデータ PostgreSQLの運用・監視にまつわるエトセトラ
- 2. 2Copyright © 2015 NTT DATA Corporation 本日お話すること PostgreSQLの運用・監視にまつわるポイントを、 実例を交えてお話します 細かい話は既存資料にお任せします 運用面で頼りになるツールの紹介や、出来立ての 新機能について触れます
- 3. 3Copyright © 2015 NTT DATA Corporation 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
- 4. 4Copyright © 2015 NTT DATA Corporation 運用管理あれこれ ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・
- 5. 5Copyright © 2015 NTT DATA Corporation 本日触れるところ ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・
- 6. 6Copyright © 2015 NTT DATA Corporation 仕組みを意識したメンテナンス ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • VACUUMの効用と副作用をおさえてる？
- 7. 7Copyright © 2015 NTT DATA Corporation VACUUMの効用・副作用あれこれ • VACUUMの主な効用 • テーブル/インデックスをスキャンし、ガベージ(不要領域)を回収する • 初回のVACUUMはテーブルのフルスキャンを行いVM(Visibility Map)作成 • VMは更新処理(UPDATE/DELETE)で更新される • 以降は、VMを見て必要なところだけVACUUM • 回収領域はFSM(FreeSpaceMap)に登録し、INSERTやUPDATEに使う • ガベージが無くなったページはVMのビットを立ててステータスを最新化 テーブル テーブル テーブル VM VM VM 初回VACUUMは 全体スキャンして VM最新化 更新処理 VMも更新 次のVACUUMは 部分スキャンして VM最新化
- 8. 8Copyright © 2015 NTT DATA Corporation VACUUMの効用・副作用あれこれ • VACUUMの主な副作用 • テーブルやインデックスデータのread/write負荷 • VMの最新化に伴う IOS(Index-Only-Scan) の性能向上 • IOSはVMのビットが立って入れば、ヒープ(テーブル)は見ない • ガベージ回収に伴うWAL出力 • ページ内のデータ変更が実施されるため テーブル テーブル テーブル VM VM VM テーブルとかイン デックスをread IOSの性能 向上 回収対象ページは 書き込む。 ついでにWALも。
- 9. 9Copyright © 2015 NTT DATA Corporation VACUUMの実施方法(autovacuum) • VACUUMの実施方法は、手動と自動の2つ • 実施契機の閾値はテーブル毎に設定可能 PostgreSQL autovacuum launcher システムビュー テーブルB テーブルA autovacuum worker autovacuum worker 各テーブルのガベー ジや更新回数などを 保持監視 fork VACUUM ANALYZE workerは複数起動が 可能 VACUUMの計画や実施ジョブを組む必要はない 基本はautovacuumでOK しかし、巨大なテーブルへのVACUUMが繁忙期に実施されるリスク
- 10. 10Copyright © 2015 NTT DATA Corporation VACUUMについて考えること • 更新が無いテーブルでも、VMメンテが必要 • Index-Only-Scanに頼っている場合は特に • DWHな用途でも、VACUUMが必要かも • WAL(トランザクションログ)の出力量に気を付ける • アーカイブログ容量やレプリの設計にご注意 • メンテナンス時のバーストするかも • autovacuumに任せるもの、任せないもの • 基本はautovacuumでOKだけど・・ • 巨大なテーブルはautovacuumだと危ないかも
- 11. 1Copyright © 2015 NTT DATA Corporation 【実例】 VACUUMの手動と自動を使い分け ～数GBの 小規模テーブ ル 数百GB以上の 大規模テーブル システム性能への影響 小 →auto vacuumに任せる システム性能への影響 →メンテナンス枠にて手動 で実施 VACUUM 24時間DBアクセス 昼夜問わず大量バッチ システムへの影響をミニマムに！
- 12. 1Copyright © 2015 NTT DATA Corporation 仕組みを意識したメンテナンス ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • メンテナンスのロックを意識している？
- 13. 13Copyright © 2015 NTT DATA Corporation 排他ロックを取るメンテナンス • 排他ロック(Access Exclusive Lock)は 業務処理を停めてしまう • VACUUM FULL/CLUSTER • テーブルの物理圧縮/物理再編成 • 物理サイズの圧縮をしたい時によく使う • テーブルに排他ロックを取る処理 • REINDEX • インデックスの再作成 • 断片化したインデックスのリフレッシュに使う • インデックスに排他ロックを取る処理 • というかシステムカタログにロックを取るので、 planner処理内でロック待ちになる
- 14. 14Copyright © 2015 NTT DATA Corporation 排他ロックを取るメンテナンス • おまけ • ALTER TABLE … ADD COLUMN … DEFAULT x • テーブルに新規列(デフォルト値あり)追加 • デフォルト値なし(NULL)の場合、システムカタログの 更新だけなので一瞬で終わる • でも DEFAULT NULL と明記すると再作成、という罠が ある • テーブルの再作成 • ALTER TABLE … SET TABLESPACE x • テーブルを異なるテーブルスペースに移動 • テーブルの再作成
- 15. 1Copyright © 2015 NTT DATA Corporation 【実例】 システムを停めないメンテを考える 外部モジュールと便利なコマンド pg_reorg オンラインVACUUM FULL オンラインCLUSTER 自作ツール CREATE INDEX CONCURRENTLY VACUUMができなかったら？ インデックスが荒れてしまったら？ 排他ロック要らず！
- 16. 1Copyright © 2015 NTT DATA Corporation 【参考】 pg_reorg • pg_reorg はテーブルを再編成し、断片化を解消する • 近い将来、pg_repack に置き換わる(マージされる)かも • 再編成処理の間も参照/更新処理をブロックしないことが特徴 年に一度のメンテナンスでも DB を止めずに運転が可能 VACUUM不足による肥大化からもサービスを止めずに回復可能 ついでにインデックスも再作成(REINDEX)します 対象テーブル 操作ログ表に記録 INSERT UPDATE DELETE 作業テーブル 並び替え 操作反映 テーブルを切り替え 差分を反映し 更新結果を 引き継ぎ 切り替えは一瞬 (ロック期間は数秒)
- 17. 17Copyright © 2015 NTT DATA Corporation クエリキャンセルとプロセス停止 ■ 監視・レポート 死活監視 リソース監視・性能監視 統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • 正しいキャンセルしていますか？
- 18. 18Copyright © 2015 NTT DATA Corporation 正しいクエリ/プロセスの停め方 • あるクエリが終わらない とか VACUUMを停めたい とか • kill -SIGKILL <pid> or kill -9 <pid> は絶対にダメ • PostgreSQLは、バックエンドプロセスがSIGKILLを受け取った場合、 全プロセスを落として、共有メモリをリフレッシュする • いわば、クラッシュリカバリとなる シグナル ファンクション クエリキャンセル SIGINT SELECT pg_cancel_backend(pid); プロセスの停止 SIGTERM SELECT pg_terminate_backend(pid);
- 19. 19Copyright © 2015 NTT DATA Corporation 【実例】 不要な 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 的な感じで作法の悪いものは切断 開発環境といえども運用は大変・・・
- 20. 20Copyright © 2015 NTT DATA Corporation 監視をする ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • PostgreSQLで取得してる情報と してない情報、知ってます？
- 21. 21Copyright © 2015 NTT DATA Corporation PostgreSQLから取得できる性能情報 DB内で実施された処理の情報(稼働統計情報)はかなり細かく記録している • テーブル • 表スキャン、インデックススキャンの回数とフェッチ行数 • INSERT/UPDATE/DELETE対象の行数 • (auto)VACUUM/ANALYZEの回数と最後の実施時間 • 共有バッファにHITした回数、HITしなかった回数 • インデックス • インデックススキャン、ビットマップスキャンの回数とフェッチエントリ数 • 共有バッファにHITした回数、HITしなかった回数 • SQLとファンクション • 各SQLの実施回数、累積レスポンス時間、レスポンスのMIN/MAXなど(NEW!) • DDLやVACUUMも含む • 各ファンクションの実施回数、累積レスポンス時間
- 22. 22Copyright © 2015 NTT DATA Corporation PostgreSQLから取得できない性能情報 • プロファイラ情報 • OracleのTop 5 Timed Event など • インスタンス単位のネック候補を簡単に探る方法が無い • どうする？ → perf を入れておくと幸せになるかも！ • I/Oやメモリの使用状況に関する情報も無い • 各テーブルやインデックスへの実I/O量を直接知る手段なし • どうする？ → sar とか iostat との組み合わせで推測する → 各テーブルスペースを駆使するとよい！かも
- 23. 2Copyright © 2015 NTT DATA Corporation 【実例】 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高騰が解消した
- 24. 2Copyright © 2015 NTT DATA Corporation 【実例】 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
- 25. 25Copyright © 2015 NTT DATA Corporation 【実例】 テーブルスペースと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
- 26. 26Copyright © 2015 NTT DATA Corporation いざという時のために ■ 監視・レポート 死活監視 リソース監視・性能監視 稼働統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • 入れておくと便利なモジュール、 あるんですよ？
- 27. 27Copyright © 2015 NTT DATA Corporation いざという時のために PostgreSQLには、内部のHookを使うcontribモジュールがある これらはとても有用なものばかり shared_preload_libraries パラメータにモジュール名を付与して、 PostgreSQLを再起動すると有効になる ExecutorStart_hook ExecutorEnd_hook queryDesc->totaltime = InstrAlloc(…) ②処理をフック ③モジュール内処理 (計測開始など) ④通常処理へ ⑤ 通常のExecution ① Execution 開始 ⑥Execution 終了 InstrEndLoop(queryDesc- >totaltime) ⑦処理をフック ⑧モジュール内処理 (計測整理と記録など) ⑨通常処理へ (参考)Hookを使うモジュールの動き
- 28. 28Copyright © 2015 NTT DATA Corporation いざという時のために PostgreSQLを再起動すると有効になる しかし本番環境やシビアな試験環境ではおいそれと再起動もできない・・・ と言って、必要そうなもの全部を仕込むとログ量とか大変・・・ こういう時は、モジュールを無効にした状態で仕込んでおいて、 必要な時に有効にすると良い 大抵の場合、xxxxx_enabled = [on | off] がある off <-> on は reload (SIGHUP)で良いので気楽にできる ExecutorStart_hook ExecutorEnd_hook if (! xxxx_enabled) return; ②処理をフック ③モジュール内処理 (無効なら何もしない) ④通常処理へ ⑤ 通常のExecution ① Execution 開始 ⑥Execution 終了 if (! xxxx_enabled) return; ⑦処理をフック ⑧モジュール内処理 (無効なら何もしない) ⑨通常処理へ
- 29. 29Copyright © 2015 NTT DATA Corporation どれを入れておくか？ 以下の３つはおススメ 1. pg_stat_statements 実行されたSQLの回数や累積所要時間が取れる SQLごとのキャッシュヒット率とかもわかる PostgreSQL 9.5 からはレスポンスのMIN/MAX/MEAN/STDDEVもわかる！ 2. auto_explain 指定時間以上かかったSQLの実行計画をログに出す 実行計画が変わったことによる性能劣化が分かりやすい！ 試験時の実行計画確認にも使える 3. pg_hint_plan 実行計画を制御するモジュール OracleのHINT句相当のもの 困ったときのチューニング用に！
- 30. 3Copyright © 2015 NTT DATA Corporation 【実例】 HINT句を活用 HINT句を使い直接実行計画を制御することで、 迅速なSQLチューニングを可能に ○ HINT句を使用するメリット SQLを書き換えるよりも改修時間が短い！ • 使用するインデックスやスキャン方法を変えるだけ SQLの実行結果の内容は変わらない！ • HINTを付与するだけなので、SQLのリテスト不要 /*+ IndexScan(hoge) */ SELECT * FROM hoge WHERE id = 9999;
- 31. 31Copyright © 2015 NTT DATA Corporation 【実例・小ネタ】 auto_explain で実行計画確認 試験時に特定の処理の実行計画だけ知りたい、しかし・・・ APには手を入れられない 一つのインスタンスに数十のDB 多数の試験が並行して実施中 postgresql.confで auto_explain.enabled = on で reload すると大変なことに・・・ ところで、reload って何しているの？ postgres (親玉プロセス) postgres (バックエンドプロセス) postgres (バックエンドプロセス) reloadコマンド (内部ではSIGHUPを 親玉に飛ばす) postgresql.conf SIGHUP SIGHUP 読みこみ 読みこみ こいつだけ変えたい
- 32. 32Copyright © 2015 NTT DATA Corporation 【実例・小ネタ】 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 読みこみ よっしゃ
- 33. 33Copyright © 2015 NTT DATA Corporation 監視を助けてくれるツール ■ 監視・レポート 死活監視 リソース監視・性能監視 統計情報監視 ■ サービス管理 停止/再起動 フェイルオーバ/フェイルバック プロモート ■ バックアップ/リストア バックアップ PITR ■ 性能維持 メンテナンスコマンド実施 ■ 性能分析/トラブルシュート クエリキャンセル/プロセス停止 ボトルネック調査 スロークエリ解析 実行計画解析 ■ アップデート (セキュリティ)アップデート アップグレード などなど・・・・ • たくさん取れるけど面倒ですよね？
- 34. 34Copyright © 2015 NTT DATA Corporation pg_statsinfo あります PostgreSQLのインスタンスにエージェントが常駐 定期的にPostgreSQLから稼働統計情報を収集し、スナップショットとして保存 2つのスナップショット差分から、当該期間の性能レポートを生成する
- 35. 35Copyright © 2015 NTT DATA Corporation 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
- 36. 3Copyright © 2015 NTT DATA Corporation Hinemos はいかがですか 標準の監視種別 PING監視 システムログ監視 Hinemosエージェント監視 HTTP監視 プロセス監視 リソース監視 SQL監視 SNMP監視 SNMPTRAP監視 ログファイル監視サービス・ポート監視 カスタム監視 Windowsサービス監視 Windowsイベント監視 選択 ・監視対象 ノード ・通知設定 監視設定 ノード ・監視間隔:○分 ・判定条件（閾値指定) システム運用管理で要求される幅広い機 能を備えた統合運用管理ソフトウェア ノード管理 状態監視 ジョブ制御 ✔ ✔ ▲ パフォーマンス管理
- 37. 3Copyright © 2015 NTT DATA Corporation SQL監視機能 管理対象ノード上のDBMSに対してSQLによる 問い合わせを発行し、SQL実行結果を取得・収集 実行結果が数値の場合は閾値監視、 実行結果が文字列の場合は、文字列監視を実行 管理対象機器 (DBサーバ) 通知 閾値監視 (数値) ②SQL実行 ③SQL実行結果 (数値・文字列) SQL監視 ＤＢ JDBC ドライバ ①SQL実行指示文字列監視 (文字列) 運用管理サーバ Hinemosマネージャ ④ ⑤通知 ⑤ ④SQL実行結果の 監視処理
- 38. 3Copyright © 2015 NTT DATA Corporation Hinemos エージェント カスタム監視機能 システム個別のサービス・ミドルウェアを ユーザ定義コマンドにて監視 監視結果を蓄積し、性能管理機能で確認可 能 コマンド コマンド コマンド コマンド コマンド コマンド コマンド 繰り返し実行 管理対象機器 ①コマンド実行指示 Hinemosエージェント カスタム監視 運用管理サーバ Hinemosマネージャ 閾値監視 (数値) 通知 ②コマンド実行結果 ③通知 key.value
- 39. 3Copyright © 2015 NTT DATA Corporation カスタム監視 実行結果(例) CSV グラフ表示・分析 レポート作成 アラート通知 例)PostgreSQL監視コマンド カスタム監視
- 40. 4Copyright © 2015 NTT DATA Corporation ミドルウェア監視用スクリプト 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/
- 41. 4Copyright © 2015 NTT DATA Corporation 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)
- 42. 4Copyright © 2015 NTT DATA Corporation おわりに PostgreSQLはかなり成長していますが 運用がやや面倒なのは否めない・・・ → そんな時は、外部モジュールの力を借りましょう 仕組みを意識すると、応用の効いた運用ができます 運用は設計時点から始まっています！ こんなこともあろうかと、な手段を準備しておきましょう！
- 43. 4Copyright © 2015 NTT DATA Corporation ご清聴ありがとうございました！