Alvaro Herrera <alvherre@commandprompt.com> writes:
> henk de wit escribi�:
>>> How is the memory consumed? How are you measuring it? I assume you
>>> mean the postgres process that is running the query uses the memory.
>>> If so, which tool(s) are you using and what's the output that shows it
>>> being used?
>>
>> It's periodically measured and recorded by a script from which the relevant parts are:
>>
>> GET_VSZ="ps aux | grep $REQ_GREP | grep -v grep | grep -v $$ | awk '{print \$5}'
>> | sort -n | tail -n1";
>> GET_RSS="ps aux | grep $REQ_GREP | grep -v grep | grep -v $$ | awk '{print \$6}'
>> | sort -n | tail -n1";
On many variants of Unix, this is going to lead to a totally misleading
number. The first problem is that shared buffers will be counted
multiple times (once for each PG process). The second problem is that,
depending on platform, a specific page of shared memory is counted
against a process only after it first touches that page. This means
that when you run a big seqscan, or anything else that touches a lot of
buffers, the reported size of the process gradually increases from just
its local memory space to its local memory space plus the total size
of the Postgres shared buffer arena. This change in the reported size
is *utterly meaningless* in terms of actual memory consumption.
It's not easy to get useful measurements from "ps" when dealing with
heavy memory sharing. There have been some discussions recently of
alternative tools that let you get a clearer picture; check the
PG list archives.
regards, tom lane