> * Matt Magoffin (postgresql....@msqr.us) wrote:
>> Just running top, it does appear to chew through a fair amount of memory.
>> Here's a snapshot from top of the postgres processing running this query
>> from just before it ran out of memory:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 4486 postgres 18 0 4576m 3.6g 3.3g R 90 23.1 0:34.23 postgres:
>> postgres lms_nna [local] EXPLAIN
>>
>> These values did start out low, for example the RES memory started in the
>> 130MB range, then climbed to the 3.6GB you see here.
That is almost certainly meaningless; it just reflects the process
touching a larger and larger fraction of shared buffers over its
existence. The number to pay attention to is the non-shared memory size
(VIRT - SHR is probably the right number here).
Stephen Frost <sfr...@snowman.net> writes:
> 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? Run 'file' on your postgres binary, like so:
I think it must be compiled 64-bit, or he'd not be able to get
shared_buffers that high to start with. However, it's possible that the
postmaster's been started under a ulimit setting that constrains each
backend to just a few hundred meg of per-process memory.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
