関係
- PostgreSQL の max_connections、Pgpool-Ⅱ の max_pool 、num_init_children の関係は以下の通り
- num_init_children は prefork される pgpool-II のプロセス数
- web(client) からは num_init_children のコネクションを張ることができる
- pgpool-IIと PostgreSQL の間は num_init_children * max_pool のコネクションを張ることができる。
- prefork されたプロセスが max_pool をマルチスレッドで処理する（さらに子プロセスを fork するわけではない）
max_pool*num_init_children <= (max_connections - superuser_reserved_connections)
- 問い合わせのキャンセルを行うとバックエンドに対して別の接続が張らるため。 すべての接続が使用中の場合には問い合わせのキャンセルができなくなる。 問い合わせのキャンセルを必ず保証したい場合は、想定されるコネクション数の倍の値を設定する必要がある。
max_pool*num_init_children*2 <= (max_connections - superuser_reserved_connections)
- 従って、Webサーバのプロセス数（厳密にはマルチスレッド、1プロセス／スレッドで複数セッション張れるので、「セッション数」）との関係は以下の通り
max_pool*num_init_children*2 <= (max_connections - superuser_reserved_connections)
Webサーバの最大プロセス数 <= max_pool*num_init_children
例）
max_pool:100 *num_init_children:1 * 2 <= (max_connections:203 - superuser_reserved_connections:3)
Webサーバの最大プロセス数:100 <= max_pool*num_init_children: 100
設計時に考慮すべきこと
- pgpool-II がActive/Activeのマルチノード構成、Aurora が複数インスタンス構成の場合は考慮が必要
- 全接続が1台に偏ってもDB側がmax_connectionsエラーを出さないように設計すると、接続は受けるもののキャパシティ不足で1台で処理を受けきれずにスローダウンする可能性があり、最初から1台で全ワークロードを処理可能なサイジングではコスト高になってしまうと想定されるので、落とし所を要検討
