I'm seeing this also with pgpool-II-2.2.5 running on ubuntu server, kernel 2.6.24. Given pgpool's handling method for connections over the num_init_children (queuing), I have to set num_init_children high enough to ensure children are never depleted (> 1000). When all those children respawn every $child_life_time seconds I see load spikes upwards of 60
That said, there does not appear to be any operational impact on the pgpool server, I am just seeing load spikes similar to what Aleksey mentioned turning my monitoring solution red multiple times a day. I would think that one work around would be to set child_max_connections sufficiently low that children respawn because they have reached child_max_connections rather than than child_life_time. If I'm understanding the situation correctly this would cause child respawns to happen more serially rather than all children respawning together every $child_life_time seconds. -s On Tue, Nov 24, 2009 at 4:38 AM, Glyn Astill <[email protected]> wrote: > > > --- On Tue, 24/11/09, Aleksey Tsalolikhin <[email protected]> wrote: > > > From: Aleksey Tsalolikhin <[email protected]> > > Subject: [Pgpool-general] pgpool-II 2.2.5 slamming the CPU > > To: [email protected] > > Date: Tuesday, 24 November, 2009, 0:26 > > Hi. We have our pgpool-II > > configured with > > > > num_init_children = 64 > > > > and I see the number of processes in the run queue goes > > from nothing to 64 > > then to nothing again; this causes the load average to > > spike sharply which > > rings alarm bells in the monitoring system. > > > > I don't suppose it's possible to spread this workload out a > > bit so it does not > > spike so sharp? > > > > > > Out of interest, what kernel are you on? > > > > _______________________________________________ > Pgpool-general mailing list > [email protected] > http://pgfoundry.org/mailman/listinfo/pgpool-general >
_______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
