postgresqlクラスタ全体の参照クエリが重くなった話し

レプリケーション構成中のpostgresqlマスタ、スレープ全台のある特定の参照クエリが重くなった話し

  • 重いのは特定のクエリのみ
  • indexは正しく使われており、実行計画上重いものではなさそう
  • なのに速度が出ない
  • 1プロセスあたりのcpu使用率が高い。サチるような処理ではないはず。
  • 昨日の状況と比べてみてもcpu使用率が異常値となっている

解決編

  • テーブルごとのデッドタプルを確認
select n_dead_tup from pg_stat_user_tables ;
  • 巨大なデッドタプルを持つテーブルを確認
  • autovacuumしてしているんだけどな
  • autovacuum設定値はデフォルトのautovacuum_vacuum_scale_factor=0.2 (20%)
  • 結論としてはこれがまずかった。
  • 1,000万レコードあるテーブルでは200万デッドタプルがautovacuumのトリガとなる
  • ユーザ操作上、大量のデータを更新できる機能があり、一気に80万ほどの更新が走り巨大なデッドタプルが生まれたが、20%の閾値以下なので、autovacuumが走らなかった
  • マスタ側DBで対象のテーブルを手動vacuumすることで対応

ある程度の規模のテーブルになるとautovacuum_vacuum_scale_factor=0.2が最適な閾値とはならない可能性が出てくるので、autovacuum運用する時はレコードサイズに注意しておこう。という話し。

apacheがセマフォを食いつぶす件

以下のログが出てapacheが停止しているー

[Sat Feb 25 03:14:02.160466 2017] [core:emerg] [pid 20337] (28)No space left on device: AH00023: Couldn't create the watchdog-callback mutex 
[Sat Feb 25 03:14:02.160495 2017] [:emerg] [pid 20337] AH00020: Configuration Failed, exiting

ググるとわんさか出てくるが、多分、logrotate時のHUPでセマフォが解放されてない
で、起動できなくなった時の対処法はみんな書いてあるけど、運用中のapache停止防止については書かれていないー
運用中のapacheに対してipcrmすると、使っているセマフォまで消してしまう可能性あり。どうやらセマフォは結構根の深いところで使っているとのこと

で、ipcsの数を監視するpluginで、アラート来たら再起動するようにしました。というお話し。

職務内容の違いによって当然価値観も違うよね。と思った話し

自分の経験則上、バックオフィスシステムの開発やメンテなんかを依頼してくるような会社は、エクセル方眼紙に図面入りの設計書書いて上げると喜ぶし、テスト報告書の納品は絶対だけど、テストコードは必要ない。といった会社が多い。
まあ、そういった仕事を生業にしていると、それを相手にするノウハウは自然とついてきて、うん十年続けてるとそれなりに技術者としてのプライドが出てくる。

それ相手にしているエンジニアとrailsでテスト駆動開発してるようなエンジニアは「開発効率」の価値感が全然違うので、SNS等でそういった両者が開発効率について議論してもあんまり生産的な議論にならないな〜　とかふと思った。
前提が全然違うっぽいので。。。

自分的にはそういう仕事はまだまだなくならないと思うし、それはそれで立派なエンジニアの仕事だと思うのでプライド持っててもいいと思うのだが。

まあ、構成管理ソフトくらいは使えよな。とは思う。

禁酒中

3月7日より禁酒中　禁酒2週間経過

理由：肝臓の値が高いため

変化したこと

  • 湿疹持ちだが、多少改善したように感じる
  • 酒なしでも寝つけるようになった
  • 熟睡できてる感がある　飲酒時はトイレに行ったり、朝、睡眠不足を感じることがあった
  • 今回はあまり甘いものが欲しくならない
  • 食欲は変わらず。　がセーブできる
  • 多少、ポジティブ思考に　ストレスになるようなことがあっても、飲酒で気を紛らわすのではなく、向き合えるようになった気がする
  • エレベーター、エスカレーターを控えて階段の昇降までしてるが、体重は減らない
  • 飲酒欲求は禁酒当日とさほど変わらず　飲みたい時は飲みたい
  • お金が減らない

デメリット

  • お酒の味が味わえない

リカバリーで競合が発生したためステートメントをキャンセルしています

postgresql

レプリケーション環境下のスレープサーバへの参照問い合わせ、主に重いクエリ発行時に発生する

原因は以下のクエリで確認できる

database =>  select * from pg_stat_database_conflicts ;
 datid |  datname  | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock
-------+-----------+------------------+------------+----------------+-----------------+----------------
 16386 | database    |                0 |          0 |           1 |               0 |              0

この場合は参照中のテーブルに対してマスタ側で変更があったことを表す
こういった場合、スレーブ側はmax_standby_streaming_delayの値まで、レプリケーション同期を待つのだがmax_standby_streaming_delayの値内で処理が終わらない場合、confl_snapshotとなる

max_standby_streaming_delayはdefaultで30秒となっており、30秒以上かかるクエリ且つマスタ側で対象テーブルにデータ更新が行われると発生する

単純に値を増やす、または-1(無制限)とすれば解決するのだが、その分、長時間かかるクエリ時のwal同期が遅れるので注意する
可能であればシーケンシャルスキャンする専用のスレープを用意し、同期遅延前提でのデータベースとして取り扱うことを考える