pgauditとpg_sulogの性能への影響をちょっと測ってみた
ちょうど、一か月前ににPostgreSQLカンファレンス2015があったんだっけ・・・もう一か月経ったのか。
pgaudit
今年のPostgreSQLカンファレンスではデータベースセキュリティや、データベース監査というネタの発表が多かったんですけど、その中で pgaudit というPostgreSQLに監査拡張の紹介がありました。
監査要件を有するシステムに対するPostgreSQL 導入の課題と可能性 (PDF)
その pgaudit はちょっと前にバージョン1.0.0として正式リリースされたっぽい。
https://github.com/pgaudit/pgaudit
このモジュールはPostgreSQLのコマンド実行前にHOOKを使って介入して、SQLコマンドのメタ情報やSQLそのものをサーバログに出力するというもの。
そうなると、素のPostgreSQLの実行時と比較して、どの程度性能への影響があるのかちょいと気になる。
なので、pgbenchを使って、簡単に測定してみることにした。
pg_sulog
PostgreSQLカンファレンス2015のクロージング・ライトニングトークでも、いくつかHOOKネタが発表された。
まあ、そのうち一つが私の発表なんですけどね。
で、私の発表の中で紹介した pg_sulog がPostgreSQLの性能に与える影響もついでに測ってみることにした。
測定
測定環境
例によって、自分のノートPC上でやりますよ。
- VMWare
- CentOS 7 (まだ7.2に入れ替えてない)
- PostgreSQL 9.5 rc1
- サーバログは /tmp 配下に生成
- パラメータはデフォルト。これにEXTENSION用の設定を追加しただけ。
pgbenchパラメータ
初期化パラメータはこんな感じ。
- scale factor = 10 (-s 10)
- unloogged指定 (--unlogged-table)
- Filfactor = 90 (-F 90)
実行パラメータはこんな感じ。これを3回連続で測定し、tpsの平均値をとる。
- 実行モードはデフォルト。更新あり。
- 同時実行数は4 (-c 4)
- トランザクション数は25000 (-t 25000)
- 平均レイテンシ取得 (-r)
結果
見てのとおりですがな。
- pgauditはロギングしなければ、ほとんどPostgreSQLへの性能影響はなさそう。
- pg_sulog遅すぎ・・・ロギングしなくても半分程度のスループットしかでねえ。
- これの理由は明白。pg_sulogではクエリ実行前にpg_roleを参照してスーパーユーザ権限のあるユーザを収集し、それとセッションユーザを比較している。比較した結果、スーパーユーザ権限だと判断したら、ロギングやブロックを行う。
- このpg_roleの参照をSPI経由で行っているんだけど、ここを改善しないとダメだろうなー。
- 直接システムカタログのHeapを見にいくべきなんだろうか。
まあ、pg_sulog側はどうでもいいんだけど、pgauditの組み込みによる性能低下は、ロギング量が少なければ、それほど心配はしなくても良さそうというのが、なんとなく見えてきた。
