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

Copyright © 2015 NTT DATA Corporation

中国地方DB勉強会 2015年4月18日 NTTデータ

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

2 Copyright © 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%E3%83%9A%E3%83%BC%E3%82%B8

http://www.slideshare.net/satock/29shikumi-backup




http://www.slideshare.net/suzuki_hironobu/recovery-11




http://www.slideshare.net/kasaharatt/postgre-sql-26186128






http://www.oss-db.jp/news/event/image/20130615_01.pdf




http://www.slideshare.net/noriyoshishinoda/postgresqlconference-2014-hands-on-2-shinoda-201412061














http://www.postgresqlinternals.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%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だと危ないかも

1

1


【実例】 VACUUMの手動と自動を使い分け

～数GBの小規模テーブル

数百GB以上の大規模テーブル

システム性能への影響小 →auto vacuumに任せる

システム性能への影響

→メンテナンス枠にて手動で実施

VACUUM

24時間DBアクセス昼夜問わず大量バッチ

システムへの影響をミニマムに！

1

2


仕組みを意識したメンテナンス


死活監視




停止/再起動


プロモート


バックアップ

PITR

■ 性能維持






実行計画解析





• メンテナンスのロックを意識している？


排他ロックを取るメンテナンス

• 排他ロック(Access Exclusive Lock)は業務処理を停めてしまう

• VACUUM FULL/CLUSTER

• テーブルの物理圧縮/物理再編成 • 物理サイズの圧縮をしたい時によく使う

• テーブルに排他ロックを取る処理

• REINDEX

• インデックスの再作成 • 断片化したインデックスのリフレッシュに使う

• インデックスに排他ロックを取る処理 • というかシステムカタログにロックを取るので、

planner処理内でロック待ちになる


排他ロックを取るメンテナンス

• おまけ

• ALTER TABLE … ADD COLUMN … DEFAULT x

• テーブルに新規列(デフォルト値あり)追加

• デフォルト値なし(NULL)の場合、システムカタログの更新だけなので一瞬で終わる

• でも DEFAULT NULL と明記すると再作成、という罠がある

• テーブルの再作成

• ALTER TABLE … SET TABLESPACE x

• テーブルを異なるテーブルスペースに移動

• テーブルの再作成

1

5


【実例】システムを停めないメンテを考える

外部モジュールと便利なコマンド

pg_reorg

オンラインVACUUM FULL オンラインCLUSTER

自作ツール CREATE INDEX

CONCURRENTLY

VACUUMができなかったら？インデックスが荒れてしまったら？

排他ロック要らず！

1

6


【参考】 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 との組み合わせで推測する

→ 各テーブルスペースを駆使するとよい！かも

2

3


【実例】 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高騰が解消した

2

4


【実例】 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 I R R I

I R

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句相当のもの

困ったときのチューニング用に！

3

0


【実例】 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 (バックエンドプロセス)


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 (親玉プロセス)



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

https://www.postgresql.jp/events/jpug-pgcon2013-files/B1_jpugpgcon2013_slide







3

6


Hinemos はいかがですか

標準の監視種別

PING監視

システムログ監視

Hinemosエージェント監視

HTTP監視

プロセス監視

リソース監視

SQL監視

SNMP監視

SNMPTRAP監視

ログファイル監視サービス・ポート監視

カスタム監視

Windowsサービス監視 Windowsイベント監視

選択

・監視対象

ノード

・通知設定

監視設定

ノード

・監視間隔:○分・判定条件（閾値指定)

システム運用管理で要求される幅広い機能を備えた統合運用管理ソフトウェア

ノード管理状態監視ジョブ制御

✔

✔

▲

パフォーマンス管理

3

7


SQL監視機能

管理対象ノード上のDBMSに対してSQLによる問い合わせを発行し、SQL実行結果を取得・収集

実行結果が数値の場合は閾値監視、実行結果が文字列の場合は、文字列監視を実行

管理対象機器 (DBサーバ)

通知

閾値監視 (数値)

②SQL実行

③SQL実行結果

(数値・文字列)

SQL監視

ＤＢ JDBC

ドライバ

①SQL実行指示文字列監視 (文字列)

運用管理サーバ

Hinemosマネージャ

④

⑤通知 ⑤

④SQL実行結果の

監視処理

3

8


Hinemos エージェント

カスタム監視機能

システム個別のサービス・ミドルウェアをユーザ定義コマンドにて監視

監視結果を蓄積し、性能管理機能で確認可能

コマンドコマンドコマンド

コマンドコマンドコマンド

コマンド

繰り返し実行

管理対象機器

①コマンド実行指示

Hinemosエージェント

カスタム監視

運用管理サーバ

Hinemosマネージャ

閾値監視 (数値)

通知

②コマンド実行結果

③通知

key.value

3

9


カスタム監視実行結果(例)

CSV

グラフ表示・分析レポート作成

アラート通知

例)PostgreSQL監視コマンドカスタム監視

4

0


ミドルウェア監視用スクリプト

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/

4

1


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)

4

2


おわりに

PostgreSQLはかなり成長していますが

運用がやや面倒なのは否めない・・・

→ そんな時は、外部モジュールの力を借りましょう

仕組みを意識すると、応用の効いた運用ができます

運用は設計時点から始まっています！

こんなこともあろうかと、な手段を準備しておきましょう！

4

3


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

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

Technology

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