More Related Content
Similar to PostgreSQLの運用・監視にまつわるエトセトラ (20)
More from NTT DATA OSS Professional Services (20)
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
どれを入れておくか?
以下の3つはおススメ
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監視
DB
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はかなり成長していますが
運用がやや面倒なのは否めない・・・
→ そんな時は、外部モジュールの力を借りましょう
仕組みを意識すると、応用の効いた運用ができます
運用は設計時点から始まっています!
こんなこともあろうかと、な手段を準備しておきましょう!