From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vincent Dautremont <vincent(at)searidgetech(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: out of memory error |
Date: | 2012-05-22 17:33:43 |
Message-ID: | 3902.1337708023@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Vincent Dautremont <vincent(at)searidgetech(dot)com> writes:
> after a few days, i'm seeing the following logs in a database (postgresql
> 8.3.15 on Windows)
> running with rubyrep 1.2.0 for syncing a few table small that have frequent
> update / insert/ delete.
> I don't understand it and I'd like to know what happens and why. How to get
> rid of it.
Well, this is a bit unusual:
> TopMemoryContext: 197681816 total in 24131 blocks; 394104 free (24179
> chunks); 197287712 used
It's not normal to have so much stuff in TopMemoryContext. That could
represent a leak, but it's also possible that that's just management
overhead for all of these contexts:
> SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
> SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
> .
> .
> . there it goes for about 80MB of log then it ends
> .
> .
> SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
That's a *heck* of a lot of SPI plans. You haven't provided any
information that would let anybody diagnose why you have so many,
though. Tell us about your usage patterns, especially of PL-language
functions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vincent Dautremont | 2012-05-22 18:04:39 | Re: out of memory error |
Previous Message | Vincent Dautremont | 2012-05-22 16:44:41 | out of memory error |