| Pgpool-II 4.0.4 文書 | |||
|---|---|---|---|
| 前のページ | 上に戻る | 第 5章サーバの設定 | 次のページ |
Pgpool-IIは確立されたPostgreSQLサーバへの接続を保存しておき、同じ属性(ユーザ名、データベース、プロトコルバージョン)を持つ新しい接続が来た時にこれらを再利用します。 これにより接続のオーバヘッドを低減し、システム全体のスループットを向上することができます。
onに設定されるとバックエンドへの接続をキャッシュします。 デフォルトはonです。 ただし、connection_cacheがonでも、template0、template1、postgres、regressionデータベースへの接続はキャッシュされません。
このパラメータを変更した時にはPgpool-IIを再起動してください。
Pgpool-IIの各子プロセスがキャッシュするコネクションの最大数です。 Pgpool-IIは、受け付けた接続が同じユーザ名で同じデータベースに接続しようとする場合に、キャッシュされたコネクションを再利用します。 そうでなければPgpool-IIはバックエンドへの新しい接続を生成します。 もしキャッシュされている接続の数がmax_poolを超えた場合には、一番古いコネクションが廃棄され、そのスロットが新しい接続のために使用されます。
デフォルト値は4です。 Pgpool-IIのプロセスからバックエンドへの接続の数は全部でnum_init_children * max_poolに達する可能性があることに注意してください。
このパラメータはサーバ起動時にのみ設定可能です。
フロントエンドからPgpool-IIへの接続待ち行列の長さを制御します。 接続待ち行列の長さ(具体的にはlisten()システムコールのbacklogパラメータ)は、listen_backlog_multiplier * num_init_childrenで決まります。
注意: システムによってはlisten()システムコールのbacklogパラメータに上限が設定されています。 詳細はnum_init_childrenの項を参照してください。
デフォルト値は2です。
このパラメータはサーバ起動時にのみ設定可能です。
onに設定することで、Pgpool-IIは受け付けるクライアント接続のシリアライズを有効にします。 シリアライズを行わない場合、OSカーネルはaccept()を実行するために全てのPgpool-II子プロセスを起こし、実際にはそのうちの１つのみが入ってきた接続を処理します。 ここでの問題は、子プロセスが一度に起こされるために重いコンテキストスイッチングが起こり、性能に影響がでることです。
この現象は「thundering herd problem（猛獣の暴走）」と呼ばれる古典的な問題です。 これはaccept()呼び出しのシリアライズを行うことで解決できます。 入ってきた接続に対してPgpool-IIプロセスのうちひとつだけが起こされてaccept()を実行ようになるためです。
しかしシリアライズにはオーバヘッドがあり、num_init_childrenが大きい時のみ使用することを推奨します。 小さいnum_init_childrenに対しては、シリアライズのオーバヘッドのために性能が低下するかもしれません。
注意: num_init_childrenとserialize_acceptの相関は環境によって異なるので、serialize_acceptを使うかどうか決める前にベンチマークテストを行ってみることをおすすめします。
例 5-1. serialize_acceptの使用判断のためにpgbenchを利用する
以下のコマンドを使ってpgbenchを実行します。
pgbench -n -S -p 9999 -c 32 -C -S -T 300 test
ここで、-Cはpgbenchにトランザクション実行の度に毎回データベースに接続することを指示します。 -c 32は、Pgpool-IIへの同時セッション数です。 これはシステム要件にあわせて変更するのがよいでしょう。 pgbenchが終了後、"including connections establishing" の数値をチェックします。
注意: なお、child_life_time が有効だと、serialize_acceptは効果がありません。 serialize_acceptをonにしたい場合は、child_life_timeが0であることを確認してください。 Pgpool-IIプロセスのメモリーリークなどの潜在的な問題を気にする場合は、代わりにchild_max_connectionsを使ってください。 この制限は純粋に実装上の問題であり、将来はなくなるかもしれません。
デフォルトはoffです。
このパラメータはサーバ起動時にのみ設定可能です。
Pgpool-IIの子プロセスがアイドル状態のままでいるときに、それを強制終了するまでの時間を秒単位で指定します。 child_life_timeにより終了された時には、すぐに新しい子プロセスがPgpool-IIにより起動されます。 child_life_timeはPgpool-II子プロセスのメモリリークやその他の不測のエラーに備えた予防措置です。
注意: child_life_timeはまだ一度もコネクションを受け付けていないプロセスには適用されません。
注意: child_life_timeが有効な場合、serialize_acceptは無効になります。
デフォルト値は300秒（すなわち5分）です。 0を指定するとこの機能は無効になります。
このパラメータはサーバ起動時にのみ設定可能です。
クライアントが前回のクエリからアイドル状態のままでいるときに、それを切断するまでの時間を秒単位で指定します。 これは、だらしないクライアントやPgpool-IIの間のTCP/IPコネクションの不調によって、Pgpool-IIの子プロセスが占有されてしまうのを回避するのに役立ちます。
注意: client_idle_limitはオンラインリカバリのセカンドステージでは無視されます。
デフォルト値は0で、この機能はoffとなります。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。
各Pgpool-II子プロセスの寿命を、受付可能なクライアント接続の数で指定します。 child_max_connections個のクライアント接続を処理した後にPgpool-IIはその子プロセスを終了させ、すぐに代わりの新しい子プロセスを生成します。
child_max_connectionsはchild_life_timeやconnection_life_timeが効かないくらい忙しいサーバで有用です。 またPostgreSQLバックエンドが肥大化するのを防ぐのにも有用です。
デフォルト値は0で、この機能はoffとなります。
このパラメータはサーバ起動時にのみ設定可能です。
キャッシュされたPostgreSQLへの接続を切断するまでの時間を秒単位で指定します。 これはキャッシュされた接続の有効期間として働きます。
デフォルトは0です。 これはキャッシュされた接続が切断されないことを意味しています。
このパラメータはサーバ起動時にのみ設定可能です。
ユーザセッションを終了するときにバックエンドコネクションを初期化するために送られるSQLコマンドを指定します。 複数のコマンドを";"で区切って指定することができます。
利用できるコマンドはPostgreSQLのバージョンによって異なります。 各PostgreSQLバージョンごとの設定は以下です。 ただし、"ABORT"は必ずコマンドに含めてください。
表 5-4. PostgreSQLバージョンごとのreset_query_listの推奨設定
| PostgreSQLバージョン | reset_query_list |
|---|---|
| 7.1以前 | 'ABORT' |
| 7.2から8.2 | 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT' |
| 8.3以降 | 'ABORT; DISCARD ALL' |
注意: ABORTは、PostgreSQL 7.4以降ではトランザクションブロックの中にいない場合には発行されません。
デフォルトは'ABORT; DISCARD ALL'です。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。