|
|
It seems that we met the same problem(Bug 436). After investigation, we found that when too many stmt objects created(if you use php with pdo, each query statment will create a stmt), when a long session(that is what you talk about a connection will not disconnect) used, the pgpool child process(which handle the connection) will use too much memory and cpu resource. |
|
|
Hanyugang01, Thanks for that. Did you take any action to prevent that? The only thing I can think of is changing applications to disconnect from time to time and then configure pgpool to recycle processes after N connections, this can be done with the parameter child_max_connections. |
|
|
In our environment, we need a daemon process to fetch data from the message queue, and then import data to postgresql. The dataset is huge, so connection which disconnected from time to time is not acceptable, we just using the pgpool to get the master postgresql instance, and then connect to the master postgresql server directly. |
|
|
Could you provide a test program to reproduce this problem? |
|
|
hello, U can use this test tool to reproduce this problem. Usage of this tool: -d string database name (default "test") -h string host (default "localhost") -n int insert number (default 10000) -p string port (default "9999") -t string test type (default "good") -u string user (default "postgres") -w string passwd (default "postgres") specially, -t parameter includes "good" and "bad" , U can switch this parameter to compare this two situation. By the way, I use the flame tool to inspect the bad situation, I found that in bad situation these three functions consume too much CPU time("can_query_context_destroy" && "pool_remove_sent_message"&&"pool_get_sent_message" ) Thanks very much! pgpool_in_bad_situation_flame.svg (133,529 bytes) |
- Anonymous
