Thank you very much! <div><br /><div>Unfortunately i won't be able to test this patch and report the results till august,15.</div><div><br /><br /><br /><br />09.08.2017, 13:14, "Tatsuo Ishii" &lt;ishii@sraoss.co.jp&gt;:<br /><blockquote type="cite"><p>Ok, I have just committed/pushed the fix for this.<br /><br /><a href="https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=65aace20bf54c0caada76b644656927b6a1067e7">https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=65aace20bf54c0caada76b644656927b6a1067e7</a><br /><br />Back patched to 3.6 and 3.5 stable branches.<br /><br />Best regards,<br /></p><span>-- <br />Tatsuo Ishii<br />SRA OSS, Inc. Japan<br />English: <a href="http://www.sraoss.co.jp/index_en.php">http://www.sraoss.co.jp/index_en.php</a><br />Japanese:<a href="http://www.sraoss.co.jp">http://www.sraoss.co.jp</a><br /></span><p><br /></p><blockquote> Hello.<br /><br /> We started testing our project under heavy load and encountered out of<br /> memory  condition  if pgpool is running with memory_cache_enabled=on, both<br /> with shmem and memcached.<br /><br /> Under simulated heavy load pgpool consumes all available memory (16Gb)<br /> in just a few minutes and then kernel kills it.<br /><br /> I've found this old similar bug thread: <a href="http://www.pgpool.net/mantisbt/view.php?id=52">http://www.pgpool.net/mantisbt/view.php?id=52</a><br /> and  tried  running  pgpool  with  valgrind,  but (perhaps due to high<br /> number  of pgpool childs?) system was almost unresponsive and i had to<br /> restart pgpool without valgrind.<br /><br /> I'm  attaching pgpool log which was written during the short period of<br /> valgrind activity.<br /> There  are some records, but I have zero experience in this area and I<br /> have  no  idea  if  they  are  indicating a problem or not. One of the<br /> records:<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    by 0x448063: save_ps_display_args (ps_status.c:173)<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    by 0x407F41: main (main.c:192)<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612== LEAK SUMMARY:<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    definitely lost: 96 bytes in 1 blocks<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    indirectly lost: 343 bytes in 11 blocks<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==      possibly lost: 0 bytes in 0 blocks<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==    still reachable: 254,475 bytes in 3,102 blocks<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==         suppressed: 0 bytes in 0 blocks<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612== Reachable blocks (those to which a pointer was found) are not shown.<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612== To see them, rerun with: --leak-check=full --show-leak-kinds=all<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612==<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612== For counts of detected and suppressed errors, rerun with: -v<br /> Jul 26 09:27:59 ip-<span>172-31-26-132</span> pgpool2[3707]: ==4612== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)<br /><br /><br /><br /> "ulimit  -a"  output  of  user  postgres (pgpool is running under this<br /> account):<br /> postgres@ip-<span>172-31-26-132</span>:~$ ulimit -a<br /> core file size          (blocks, -c) 0<br /> data seg size           (kbytes, -d) unlimited<br /> scheduling priority             (-e) 0<br /> file size               (blocks, -f) unlimited<br /> pending signals                 (-i) 64124<br /> max locked memory       (kbytes, -l) 64<br /> max memory size         (kbytes, -m) unlimited<br /> open files                      (-n) 10000<br /> pipe size            (512 bytes, -p) 8<br /> POSIX message queues     (bytes, -q) 819200<br /> real-time priority              (-r) 0<br /> stack size              (kbytes, -s) 8192<br /> cpu time               (seconds, -t) unlimited<br /> max user processes              (-u) 64124<br /> virtual memory          (kbytes, -v) unlimited<br /> file locks                      (-x) unlimited<br /><br /><br /><br /><br /> -- <br /> Best regards,<br />  Pavel                          mailto:<a href="mailto:balroga3@yandex.ru">balroga3@yandex.ru</a><br /></blockquote></blockquote></div></div>