<div dir="ltr"><div>Hi Ishii San,</div><div><br></div><div>Please find the rebased version attached.</div><div><br></div><div>Best regards</div><div>Muhammad Usama</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 13, 2022 at 9:06 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Usama,<br>
<br>
> Thanks!<br>
> <br>
> I will look into this and get back to you.<br>
<br>
Unfortunately your patch does not apply any more because of recent<br>
commit.  Can you please rebase it? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
$ git apply ~/dynamic_spare_process_management.diff <br>
error: patch failed: src/main/pgpool_main.c:115<br>
error: src/main/pgpool_main.c: patch does not apply<br>
<br>
> Best reagards,<br>
> --<br>
> Tatsuo Ishii<br>
> SRA OSS LLC<br>
> English: <a href="http://www.sraoss.co.jp/index_en/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en/</a><br>
> Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
> <br>
>> Hi Hackers.<br>
>> <br>
>> Few years back we had a discussion on implementing the on-demand child<br>
>> process spawning and "<a href="mailto:zhoujianshen@highgo.com" target="_blank">zhoujianshen@highgo.com</a>" also shared a patch for that.<br>
>> Ref:<br>
>> <a href="https://www.sraoss.jp/pipermail/pgpool-hackers/2020-September/003831.html" rel="noreferrer" target="_blank">https://www.sraoss.jp/pipermail/pgpool-hackers/2020-September/003831.html</a><br>
>> <br>
>> The patch had a few issues and review comments and somehow or the other it<br>
>> never made it to the committable state. So I decided to take that up and<br>
>> re-work on that.<br>
>> <br>
>> Little background:<br>
>> The motivation behind this feature is that while deciding the value of<br>
>> num_init_children configuration, the administrator has to figure out the<br>
>> maximum number of concurrent client connections that needs to be supported<br>
>> by the setup even if that maximum number might only hit once in a day or<br>
>> even once in a month depending on the type of setup, and 90% of time only<br>
>> 5-10% of connections are required. But because Pgpool-II always spawns<br>
>> num_init_children number of child processes at the startup, so for such<br>
>> setups majority of the time the huge amount of child processes keep sitting<br>
>> idle and consume the system resources. This approach is suboptimal in terms<br>
>> of system resource usage and also causes problems like 'thundering herd' (<br>
>> although we do have a serialize-accept to get around that) in some cases.<br>
>> <br>
>> So the idea is to keep the spare child processes (processes that are<br>
>> sitting idle in 'waiting for connection' state) within the configured<br>
>> limits., and depending on the connected client count scale up/down the<br>
>> number of child processes.<br>
>> <br>
>> Attached re-worked patch:<br>
>> The original patch on the topic had few shortcomings but my biggest concern<br>
>> was the approach that it uses to scale down the child processes. IMHO the<br>
>> patch was too aggressive in bringing down the child process if<br>
>> max_spare_child and the victim process identification was not smart.<br>
>> Secondly the responsibility to manage the spare children was not properly<br>
>> segregated and was shared between main and child processes.<br>
>> <br>
>> So I took up the patch and basically redesigned it from the ground up. The<br>
>> attached version of patch gives the responsibility of keeping the track of<br>
>> spare processes and scaling them to the main process and also implements<br>
>> three strategies of scaling down. On top of that it also adds the switch<br>
>> that can be used to turn off this auto scaling feature and brings back<br>
>> current behaviour.<br>
>> <br>
>> Moreover instead of using a new configuration (max_children as in the<br>
>> original patch) the attached one uses the existing num_init_children config<br>
>> to keep the backward compatibility.<br>
>> <br>
>> To summarise, the patch adds the following new config parameters to control<br>
>> the process scaling<br>
>> <br>
>> -- process_management_mode (default = static )<br>
>> can be set to either static or dynamic. while static keeps the current<br>
>> 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>
>> lazy:<br>
>> 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>
>> gentle:<br>
>> 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>
>> aggressive:<br>
>> 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<br>
>> max_spare_children<br>
>> <br>
>> -- min_spare_children<br>
>> Minimum number of spare child processes to keep in waiting for connection<br>
>> state<br>
>> This works only for dynamic process management mode<br>
>> <br>
>> --max_spare_children<br>
>> Maximum number of spare child processes to keep in waiting for connection<br>
>> state<br>
>> This works only for dynamic process management mode<br>
>> <br>
>> Furthermore, the patch relies on existing conn_counter to keep track of<br>
>> connected children count, that means it does not add additional overhead of<br>
>> computing that information, and the documentation updates are still not<br>
>> part of the patch and I will add those once we have an agreement on the<br>
>> approach, and usability of the feature.<br>
>> <br>
>> <br>
>> Meanwhile I am trying to figure out a way to benchmark this feature if it<br>
>> adds any performance benefits but haven't been able to figure out the way<br>
>> to do that currently. So any suggestions on this topic is welcome.<br>
>> <br>
>> Thanks<br>
>> Best rgards<br>
>> Muhammad Usama<br>
> _______________________________________________<br>
> pgpool-hackers mailing list<br>
> <a href="mailto:pgpool-hackers@pgpool.net" target="_blank">pgpool-hackers@pgpool.net</a><br>
> <a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-hackers</a><br>
</blockquote></div></div>