PostgreSQLで、最大接続数の設定値確認は、PSQLで
show max_connections;
AWS RDS(PostgreSQL)での最大接続数の原則は、
インスタンスのメモリ(GiB)*1024*1024*1024/31457280より少し少ない程度。
ただしこれは、パラメータグループの内容により変わるかもしれない。
ちょっとした検証用でAWS上で動かしているWebアプリケーションで、謎のエラーが出るようになった。Tomcatのエラーログを見ると、なんとなくDBの接続が足りないっぽいことを言っている。
DBにPSQLで接続すると、
psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
こんなこと言って怒られる。なので、とりあえずTomcatをシャットダウンしてコネクションを空けてからPSQLで接続。
show max_connectionsというコマンドで最大接続の設定数が見えるそうなので見てみる。
> show max_connections;
max_connections
-----------------
26
26本。RDSのスーパーバイザーが3本だかそこらは使うとどこかで見たので、まあ数本はここから引かれるとして、20本前後。
実際、このDBに接続しているアプリケーションは常時3つ、たまに4つ。それぞれ、DBCPで最大接続4を設定しているがプールを2つずつ作るので24から32本の接続が必要になることがある。
なるほど、微妙に足りない。
なお、RDSの設定上の最大数は、PotgreSQL9.4.5のデフォルトのパラメータグループで、
{DBInstanceClassMemory/31457280}
使っているインスタンスはt2.microなのでメモリは1GiB。
1*1024*1024*1024/31457280で計算すると34本ということなるが、実際には他の事に使うメモリもあるとか何かそういうこともあるのだろう。
パラメータグループをいじって値を変更することも可能なのだろうが、AWSの尖ったエンジニアたちが精査した値よりいいバランスというのを俺が出せる気もしないので、素直にインスタンスを少し強くすることにした。
t2.smallのメモリは2GiBで、だいたい計算通り、psqlの返す最大コネクション数は60になった。
* * * 余談
なお、あえてアプリケーションを稼働させたままRDSのインスタンスを変更してみたら、当たり前だけどアプリケーションはDBに接続できなくなってエラーになった。アプリケーションにはバックグラウンドの処理があり、しつこくDBにつなごうとしてエラーを出しまくっている。が、変更が終了したら復旧した。
0 件のコメント:
コメントを投稿