<div dir="ltr">I can confirm this experience with long-lived connections.<div>My workaround was to ensure I had no long-lived clients</div><div>and to configure the pools to take a max of 10K connections.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 2, 2014 at 6:53 PM, Tatsuo Ishii <span dir="ltr">&lt;<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was able to reproduce the problem with 3.4.0<br>
<br>
1) run pgbench -i<br>
2) run pgbench -T 600  -S -c 1 -M extended test<br>
3) run ps x as pgpool user and find pgpool process which is bound to the pgbench session #2<br>
4) run ps and watch the process size like &#39;while true; do ps l 22942; sleep 1; done&#39;<br>
<br>
I see in #4, the process size increases rapidly:<br>
1  1000 22942 22432  20   0 5145776 5109900 -   S    pts/25     1:14 pgpool: t-i<br>
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND<br>
1  1000 22942 22432  20   0 5170364 5134368 -   R    pts/25     1:15 pgpool: t-i<br>
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND<br>
1  1000 22942 22432  20   0 5194952 5159100 -   S    pts/25     1:15 pgpool: t-i<br>
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND<br>
1  1000 22942 22432  20   0 5227736 5187716 -   R    pts/25     1:16 pgpool: t-i<br>
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND<br>
1  1000 22942 22432  20   0 5252324 5212448 -   S    pts/25     1:16 pgpool: t-i<br>
<br>
Note that even if I remove &#39;-M extended&#39; part (which means using<br>
extended protocol, i.e. prepare statements), I see the memory usage<br>
growing. So it seems this is nothing to do with whether prepared<br>
statement is used or not.<br>
<br>
We will look into this.<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<div><div class="h5"><br>
&gt; Dear pgpool users<br>
&gt;<br>
&gt; I&#39;m running two pgpool-II 3.4.0 instances in master/slave streaming<br>
&gt; replication mode, with enabled watchdog and virtual IP control. In the<br>
&gt; backend are two PostgreSQL 9.3.5 servers (one master and one slave)<br>
&gt; involved. In the frontend are two Wildfly 8.1.0 application servers<br>
&gt; having a xa-data-source configured, which connects to the VIP of the<br>
&gt; pgpool instances.<br>
&gt;<br>
&gt; After around two days, the memory of the active pgpool-II instance (the<br>
&gt; one holding the VIP) gets depleted completely and all the pgpool-II<br>
&gt; processes together use around 6 GiB of memory until the kernels<br>
&gt; out-of-memory manager kicks in or one stops the instance manually.<br>
&gt;<br>
&gt; The applications running within the Wildfly application servers are<br>
&gt; proprietary, so I don&#39;t have access to the source code. What I see,<br>
&gt; after turning statement logging on on the PostgreSQL server, is that the<br>
&gt; following queries hit the master all two seconds from both servers:<br>
&gt;<br>
&gt; postgres[20069]: [86-1] LOG:  execute &lt;unnamed&gt;: select user0_.id as<br>
&gt; id1_20_, user0_.company as company2_20_, user0_.created as created3_20_,<br>
&gt; user0_.credentials_id as credent10_20_, user0_.email as email4_20_,<br>
&gt; user0_.firstName as firstNam5_20_, user0_.lastModified as lastModi6_20_,<br>
&gt; user0_.mergedTo as mergedTo7_20_, user0_.name as name8_20_,<br>
&gt; user0_.organisation as organis11_20_, user0_.phone as phone9_20_ from<br>
&gt; bcUser user0_ where user0_.email=$1<br>
&gt; postgres[20069]: [86-2] DETAIL:  parameters: $1 = &#39;<a href="mailto:system@example.com">system@example.com</a>&#39;<br>
&gt;<br>
&gt; The queries are triggered from the HTTP load-balancer&#39;s alive-check,<br>
&gt; which is executed every two seconds on one of the applications running<br>
&gt; within the Wildfly servers.<br>
&gt;<br>
&gt; Does anyone have an idea why pgpool is allocating all the memory, or how<br>
&gt; to further debug this?<br>
&gt;<br>
&gt; It would also be very helpful if anyone having a similar working setup<br>
&gt; (Wildfly or JBoss) could share the data-source settings.<br>
&gt;<br>
&gt; There was a similar thread (3162 - Memory leaks) on the mailing list<br>
&gt; around September [1].<br>
&gt;<br>
&gt;<br>
&gt; Attached you will find an anonymised pgpool-II and xa-data-source<br>
&gt; configuration, please let me know if you need more.<br>
&gt;<br>
&gt;<br>
&gt; Many thanks in advance<br>
&gt; Christian<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; [1]<br>
&gt; <a href="http://www.pgpool.net/pipermail/pgpool-general/2014-September/003204.html" target="_blank">http://www.pgpool.net/pipermail/pgpool-general/2014-September/003204.html</a><br>
</div></div>_______________________________________________<br>
pgpool-general mailing list<br>
<a href="mailto:pgpool-general@pgpool.net">pgpool-general@pgpool.net</a><br>
<a href="http://www.pgpool.net/mailman/listinfo/pgpool-general" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-general</a><br>
</blockquote></div><br></div>