Re: Memory Leakage Problem

We're seeing memory problems on one of our postgres databases. We're
using 7.4.6, and I suspect the kernel version is a key factor with this
problem.

One running under Redhat Linux 2.4.18-14smp #1 SMP and the other Debian
Linux 2.6.8.1-4-686-smp #1 SMP

The second Debian server is a replicated slave using Slony.

We NEVER see any problems on the "older" Redhat (our master) DB, whereas
the Debian slave database requires slony and postgres to be stopped
every 2-3 weeks.

This server just consumes more and more memory until it goes swap crazy
and the load averages start jumping through the roof.

Stopping the two services restores the server to some sort of normality
- the load averages drop dramatically and remain low. But the memory is
only fully recovered by a server reboot.

Over time memory gets used up, until you get to the point where those
services require another stop and start.

Just my 2 cents...

John

Will Glynn wrote:
> Mike Rylander wrote:
>
>> Right, I can definitely see that happening. Some backends are upwards
>> of 200M, some are just a few since they haven't been touched yet.
>>
>>
>>> Now, multiply that effect by N backends doing this at once, and you'll
>>> have a very skewed view of what's happening in your system.
>>>
>>
>> Absolutely ...
>>
>>> I'd trust the totals reported by free and dstat a lot more than summing
>>> per-process numbers from ps or top.
>>>
>>
>> And there's the part that's confusing me: the numbers for used memory
>> produced by free and dstat, after subtracting the buffers/cache
>> amounts, are /larger/ than those that ps and top report. (top says the
>> same thing as ps, on the whole.)
>>
>
> I'm seeing the same thing on one of our 8.1 servers. Summing RSS from
> `ps` or RES from `top` accounts for about 1 GB, but `free` says:
>
> total used free shared buffers cached
> Mem: 4060968 3870328 190640 0 14788 432048
> -/+ buffers/cache: 3423492 637476
> Swap: 2097144 175680 1921464
>
> That's 3.4 GB/170 MB in RAM/swap, up from 2.7 GB/0 last Thursday, 2.2
> GB/0 last Monday, or 1.9 GB after a reboot ten days ago. Stopping
> Postgres brings down the number, but not all the way -- it drops to
> about 2.7 GB, even though the next most memory-intensive process is
> `ntpd` at 5 MB. (Before Postgres starts, there's less than 30 MB of
> stuff running.) The only way I've found to get this box back to normal
> is to reboot it.
>
>>>> Now, I'm not blaming Pg for the apparent discrepancy in calculated vs.
>>>> reported-by-free memory usage, but I only noticed this after upgrading
>>>> to 8.1.
>>>>
>>> I don't know of any reason to think that 8.1 would act differently from
>>> older PG versions in this respect.
>>>
>>
>> Neither can I, which is why I don't blame it. ;) I'm just reporting
>> when/where I noticed the issue.
>>
> I can't offer any explanation for why this server is starting to swap --
> where'd the memory go? -- but I know it started after upgrading to
> PostgreSQL 8.1. I'm not saying it's something in the PostgreSQL code,
> but this server definitely didn't do this in the months under 7.4.
>
> Mike: is your system AMD64, by any chance? The above system is, as is
> another similar story I heard.
>
> --Will Glynn
> Freedom Healthcare
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match