<div dir="ltr">Hi Hackers.<div><br></div><div>Few years back we had a discussion on implementing the on-demand child process spawning and "<a href="mailto:zhoujianshen@highgo.com">zhoujianshen@highgo.com</a>" also<span style="color:rgb(0,0,0);white-space:pre-wrap"> shared a patch for that.</span><br></div><div>Ref: <a href="https://www.sraoss.jp/pipermail/pgpool-hackers/2020-September/003831.html">https://www.sraoss.jp/pipermail/pgpool-hackers/2020-September/003831.html</a></div><br class="gmail-Apple-interchange-newline"><div>The patch had a few issues and review comments and somehow or the other it never made it to the committable state. So I decided to take that up and re-work on that.</div><div><br></div><div>Little background:</div><div>The motivation behind this feature is that while deciding the value of num_init_children configuration, the administrator has to figure out the maximum number of concurrent client connections that needs to be supported by the setup even if that maximum number might only hit once in a day or even once in a month depending on the type of setup, and 90% of time only 5-10% of connections are required. But because Pgpool-II always spawns num_init_children number of child processes at the startup, so for such setups majority of the time the huge amount of child processes keep sitting idle and consume the system resources. This approach is suboptimal in terms of system resource usage and also causes problems like 'thundering herd' ( although we do have a serialize-accept to get around that) in some cases.</div><div><br></div><div>So the idea is to keep the spare child processes (processes that are sitting idle in 'waiting for connection' state) within the configured limits., and depending on the connected client count scale up/down the number of child processes.</div><div><br></div><div>Attached re-worked patch:</div><div>The original patch on the topic had few shortcomings but my biggest concern was the approach that it uses to scale down the child processes. IMHO the patch was too aggressive in bringing down the child process if max_spare_child and the victim process identification was not smart. Secondly the responsibility to manage the spare children was not properly segregated and was shared between main and child processes.</div><div><br></div><div>So I took up the patch and basically redesigned it from the ground up. The attached version of patch gives the responsibility of keeping the track of spare processes and scaling them to the main process and also implements three strategies of scaling down. On top of that it also adds the switch that can be used to turn off this auto scaling feature and brings back current behaviour.</div><div><br></div><div>Moreover instead of using a new configuration (max_children as in the original patch) the attached one uses the existing num_init_children config to keep the backward compatibility. </div><div><br></div><div>To summarise, the patch adds the following new config parameters to control the process scaling</div><div><br></div><div>-- process_management_mode (default = static )</div><div>can be set to either static or dynamic. while static keeps the current behaviour and dynamic mode enables the auto scaling of spare processes<br><br>-- process_management_strategy (default = gentle )<br>Configures the process management strategy to satisfy spare processes count.<br>Valid options:<br></div><div>lazy: </div><div>In this mode the scale down is performed gradually<br>and only gets triggered when excessive spare processes count<br>remains high for more than 5 mins<br></div><div>gentle:</div><div>In this mode the scale down is performed gradually<br>and only gets triggered when excessive spare processes count<br>remains high for more than 2 mins<br></div><div>aggressive:</div><div>In this mode the scale down is performed aggressively<br>and gets triggered more frequently in case of higher spare processes.<br>This mode uses faster and slightly less smart process selection criteria<br> to identify the child processes that can be serviced to satisfy max_spare_children<br><br>-- min_spare_children<br>Minimum number of spare child processes to keep in waiting for connection state<br>This works only for dynamic process management mode<br><br>--max_spare_children</div><div>Maximum number of spare child processes to keep in waiting for connection state<br>This works only for dynamic process management mode<br></div><div><br></div><div>Furthermore, the patch relies on existing conn_counter to keep track of connected children count, that means it does not add additional overhead of computing that information, and the documentation updates are still not part of the patch and I will add those once we have an agreement on the approach, and usability of the feature.</div><div><br></div><div><br></div><div>Meanwhile I am trying to figure out a way to benchmark this feature if it adds any performance benefits but haven't been able to figure out the way to do that currently. So any suggestions on this topic is welcome. </div><div><div><br></div><div></div></div><div>Thanks</div><div>Best rgards</div><div>Muhammad Usama</div><div><br></div><div><br></div></div>