From 709196da3628090d58cfd524de7039546dd5d02f Mon Sep 17 00:00:00 2001 From: Tatsuo Ishii Date: Tue, 9 Apr 2019 16:14:55 +0900 Subject: [PATCH] Add more section to peformance chapter. --- doc/src/sgml/performance.sgml | 89 ++++++++++++++++++++++++++++++++++- 1 file changed, 87 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/performance.sgml b/doc/src/sgml/performance.sgml index d7df79056..86e3f1389 100644 --- a/doc/src/sgml/performance.sgml +++ b/doc/src/sgml/performance.sgml @@ -10,8 +10,8 @@ There are many configuration parameters that affect the performance of - Pgpool-II. In this chapter explanations - how to tune them are given. + Pgpool-II. In this chapter we present + how to tune them. @@ -74,6 +74,91 @@ Process memory requirement in total (in mega bytes) = + Disk Requirement + + Pgpool-II does not consume much + disk space. Also it does not require high speed disk because + disk I/O traffic caused + by Pgpool-II is small. However, + if you plan to emit much logs, of course you need disk space + for them. + + + + + Managing Client Connections + + As the number of client connections accepted is growing, the + number of Pgpool-II child process + which can accept new connections from client is decreasing and + finally reaches to 0. In this new clients need to wait until a + child process becomes free. Under heavy load, it could be + possible that the queue of waiting clients could be getting + longer and longer and finally hits the system's limit (you might + see "535 times the listen queue of a socket overflowed" + error"). In this case you need to increase the queue + limit. There are several ways to deal with this problem. + + + + Controling num_init_children + + The obvious way is increasing the number of child + process. This can be done by + tweaking . However + increasing child process requires more CPU and memory + resource. Also you have to be very careful about + max_connections parameter + of PostgreSQL because once the + number of child process is greater than + max_connections, PostgreSQL refuses + to accept new connections, and failover will be triggered. + + + Another drawback of increasing num_init_children is, so called + "thundering herd problem". When new connection request comes + in, the kernel wake up any sleeping child process to issue + accept() system call. This triggers fight of process to get + the socket and could give heavy load to the system. To + mitigate the problem, you could set serialize_accept to on so + that there's only one process to grab the accepting socket. + + + + + Controling listen_backlog_multiplier + + Another solution would be increasing the connection request + queue. This could be done by + increasing . + + + + + When to use reserved_connections + + However, none of above solutions guarantees that the + connection accepting the queue would not be filled up. If a + client connection request arrives quicker than the rate of + processing queries, the queue will be filled in someday. For + example, if there are some heavy queries that take long time, + it could easily trigger the problem. + + + The solution is + setting so that + overflowed connection requests are rejected + as PostgreSQL already does. This + gives visible errors to applications ("Sorry max_connections + already") and force them retrying. So the solution should only + be used when you cannot foresee the upper limit of system + load. + + + + -- 2.39.5