From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | valgog(at)gmail(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #12183: Memory leak in long running sessions |
Date: | 2014-12-08 19:02:00 |
Message-ID: | 31927.1418065320@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
valgog(at)gmail(dot)com writes:
> We experience a situations, that some of the sessions (in our case the
> oldest ones) do not give the memory back.
You have not shown any evidence of an actual problem. In particular,
if you are looking at ps RSS output and claiming that there's a leak,
you are probably simply wrong. The output shown here looks like normal
behavior of the RSS stat: it does not count shared memory pages for a
particular process until that process has touched the individual pages.
So the usual behavior of long-lived PG processes is that the reported
RSS starts small and gradually grows until it includes all of shared
memory ... and that looks like what you've got here, especially since
the larger RSS numbers are pretty similar to the VSZ numbers which are
nearly common across all the backends.
If you had some individual processes with RSS/VSZ greatly exceeding
your shared memory allocation, then I'd believe you had a leak problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sackville-West | 2014-12-08 23:55:52 | Re: regression, deadlock in high frequency single-row UPDATE |
Previous Message | valgog | 2014-12-08 18:46:18 | BUG #12183: Memory leak in long running sessions |