Hi Jeff!
No, the process that seems to grow indefinitely is postgres process
created for each active connection. The app side is fine.
Altogether we have 50 tables, only two are in the 200 mb range, the rest
is <50mb. While we query one of the big tables constantly (once every
min) but each connection process growing to 100mb in memory footprint is
something we haven't experienced with the 8.3.
Of course one solution would be to configure the connection pooler to
expire the connections from time to time, but I am still not convinced
that what we see is normal.
regards
Eliott
On 2013.12.07. 21:53, Jeff Janes wrote:
On Sat, Dec 7, 2013 at 1:10 AM, Eliott <eliott...@gmail.com
<mailto:eliott...@gmail.com>> wrote:
Dear Community,
we've recently moved one of our production databases from a 8.3
based server to a 9.2 installation. Our usage patterns remained
the same, however, we noticed that the swap space in the server
started to decrease with time.
We have roughly 16 connections to this database in an almost
constant basis, pooled by a java connection pooler on the app
side. This connections never expire (nor did they do with the 8.3 db).
However, as you can see on this memory usage chart
http://i.imgur.com/2sRRj1J.png it shows a rolleccoaster like
pattern. When we restart our application, the connections are
closed and the memory is freed.
Our work_mem is 2MB, so it does not warrant the large memory
allocation. Also I am completely sure that this is the pg
connection process that's eating up the memory.
Is it the process on the client side or the server side that is using
the memory?
How many tables are in the database? Every additional table touched
will pull in some more metadata, so over the course of a long lived
connection in the pool, it could grow a lot if you have a lot of tables.
Cheers,
Jeff