>> total used free shared buffers
>> cached
>> Mem: 16432296 16273964 158332 0 173536
>> 14321340
>> -/+ buffers/cache: 1779088 14653208
>> Swap: 2096440 560 2095880
>
> That certainly looks fine.. And you've got 14G or so which should be
> available for this query. Was this near the time the query was running?
> Could you give us what 'free' returns when the query is close to the
> out-of-memory error? I'd expect the 2nd row under 'free' to be getting
> low for the allocation to fail.
It was near the time... here's free just before executing the query:
total used free shared buffers cached
Mem: 16432296 16342056 90240 0 116868 14561200
-/+ buffers/cache: 1663988 14768308
Swap: 2096440 448 2095992
And then here is free close to the time the query runs out of memory (but
while the query is still running):
total used free shared buffers cached
Mem: 16432296 16348260 84036 0 41344 14167384
-/+ buffers/cache: 2139532 14292764
Swap: 2096440 448 2095992
> Uhh.. I saw that your system was 64-bit, but is your PG process
> compiled as 64bit? Maybe you're hitting an artificial 32-bit limit,
> which isn't exactly helped by your shared_buffers being set up so high
> to begin with?
Yes, it's compiled as 64-bit:
/opt/lms/postgres-8.3_64/bin/postgres: ELF 64-bit LSB executable, AMD
x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses
shared libs), for GNU/Linux 2.6.9, not stripped
We've had nagging memory-related issues with 8.3 that manifest themselves
like memory leaks... some posts I've made in the past have led to some
leaks getting fixed... but I've not been able to track down more specific
causes. It's just that over time Postgres seems to accumulate memory and
then we start to see out-of-memory errors like this one. Again, this query
could have nothing to do with the root cause, but this is just the example
I have to work with at the moment.
Regards,
Matt