[pgpool-general: 6797] Re: High load average on pgpool server

Radosław Szczygieł radoslaw.szczygiel at interia.pl
Fri Dec 20 18:43:27 JST 2019


I use the latest version of pgpool and pg12. I think that this high load cause after upgrade from 4.0 to 4.1. Before upgrade load average was about 2-5.Temat: Re: [pgpool-general: 6795] High load average on pgpool serverData: 2019-12-20 10:36Nadawca: "Bo Peng" Adresat: "Radosław Szczygieł" ; DW: pgpool-general at pgpool.net; > Hi,
> 
> > QUESTION: What can cause such an increase in server load?
> 
> A large number of connections may increase server load.
> Which version of pgpool do you use?
> 
> On Thu, 19 Dec 2019 13:32:26 +0100
> Radosław Szczygieł  wrote:
> 
> > Hello PGPOOL team,I have a problem regarding pgpool server load. Our cluster consists of 2 pgpool servers (watchdog) and 2 postgresql servers (master-slave). Within a few days of restarting the pgpool service, the average server load is at a high level load average : 15-20 on 15 min load. After restart pgpool load average drops to low values, but every day there is a successive increase in load average (but count of connections is the same all time). At the highest load average, the RAM usage is about 6,5GB, but the processor is used to the max.QUESTION: What can cause such an increase in server load? Currently, our PG cluster has a size of about 600GB, about 1000 connections to several bases, of which in many cases connections are short but there are many at once with high frequency. Pgpool server with centos 7 have Intel(R) Xeon(R) CPU X5650 @ 2.67GHz and 64GB ram.Below I present part of the configuration of pool connection and life time and attach screen from Icinga moni
>  tor of load average last 2 weeks.# -----listen_backlog_multiplier = 2                                   # Set the backlog parameter of listen(2) to                                   # num_init_children * listen_backlog_multiplier.                                   # (change requires restart)serialize_accept = off                           &nb
>  sp;       # whether to serialize accept() call to avoid thundering herd problem                                # (change requires restart)reserved_connections = 0#-----------num_init_children = 500                                   # Number of concurrent sessions allowed                                   # (change requires restart)max_pool = 4                    &nbs
>  p;              # Number of connection pool caches per connection                                   # (change requires restart)# - Life time -child_life_time = 300                   # Pool exits after being idle for this many secondschild_max_connections = 2005                                   # Pool exits after receiving that many connections                            
>         # 0 means no exitconnection_life_time = 1000                                   # Connection to backend closes after being idle for this many seconds                                   # 0 means no closeclient_idle_limit = 4000Regards,Radoslaw Szczygiel 
> 
> 
> -- 
> Bo Peng 
> SRA OSS, Inc. Japan
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20191220/9e75756a/attachment.html>


More information about the pgpool-general mailing list