Friday, January 6, 2012

Postgresql - pgpool : num_init_children

Yesterday I was hitting my head against a wall trying to figure out why pgbench got stuck while doing a simple test involving 50 concurrent clients. It turns out that I was overlooking the "num_init_children" parameter in the pgpool configuration.

  • pgpool-II accepts up to num_init_children concurrent sessions. If the number of concurrent sessions reach num_init_children, new session will be queued
  • pgbench creates concurrent connections before starting actual transactions. So if the number of concurrent transactions specified by "-c" exceeds num_init_children, pgbench will stuck because it will wait for pgpool accepting connections forever.
  • On the other hand PostgreSQL does not accept concurrent sessions more than max_connections.
  • If you want to test pgpool-II's connection queuing, you can use psql instead of pgbench.
Reference. Question number 10.

I guess I need to follow what's usually told in this cases : RTFM!
Then the default value for that parameter is 32, setting it up to 51:

transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 50
number of threads: 2
number of transactions per client: 10
number of transactions actually processed: 500/500
tps = 33.339290 (including connections establishing)
tps = 33.685822 (excluding connections establishing)

Not that bad, but it can improve, that's for sure.

No comments:

Post a Comment