Dear List,
Hmmm , lemme test efficacy of pg_tune.
I would reduce shared buffers also.
regarding concurrent queries:
its now non business hours and
SELECT procpid,current_query from pg_stat_activity where
current_query not ilike '%idle%' ;
is just 5-10, i am yet to measure it during business hours.
Warm Regds
Rajesh Kumar Mallah.
On Fri, Jun 25, 2010 at 4:58 PM, Yeb Havinga <yebhavinga@gmail.com> wrote:
> Rajesh Kumar Mallah wrote:
>>
>> A scary phenomenon is being exhibited by the server , which is the server
>> is slurping all the swap suddenly
>> 8 1 4192912 906164 6100 27873640 0 0 2277 858 13440 16235
>> 63 8 19 10 0
>>
>> I reduced work_mem from 4GB to 2GB to 512MB (now). I clearly remember that
>> this
>> abnormal consumption of swap was NOT there even when work_mem was 4GB.
>> eg during happier times swap utilisation was: http://pastebin.com/bnE1pFZ9
>> the question is whats making postgres slurp the swap? i am posting my
>> current postgresql.conf
>> once again.
>>
>> # cat postgresql.conf | grep -v "^\s*#" | grep -v "^\s*$"
>> listen_addresses = '*' # what IP address(es) to listen on;
>> port = 5432 # (change requires restart)
>> max_connections = 300 # (change requires restart)
>>
>
> Hello Rajesh,
>
> In constrast with e.g. shared_buffers and effective_cache_size, work_mem is
> amount of memory per 'thing' (e.g. order/group by) that wants some working
> memory, so even a single backend can use several pieces of work_mem memory.
>
> Looking at your postgresql.conf, other memory values seem a bit too high as
> well for a 32GB ram server. It is probably a good idea to use pgtune (on
> pgfoundry) to get some reasonable ball park settings for your hardware.
>
> regards,
> Yeb Havinga
>
>