Skip site navigation (1) Skip section navigation (2)

Re: How to monitor resources on Linux.

From: John R Allgood <jallgood(at)the-allgoods(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org
Subject: Re: How to monitor resources on Linux.
Date: 2007-08-28 19:40:03
Message-ID: 46D47A13.3060907@the-allgoods.net (view raw or flat)
Thread:
Lists: pgsql-admin
We are using the defaults for these values. Keep in mind we are allowing 
between 5-50 max connections per postmaster.  Here is an example of our 
largest database. It is 7.9GB we allow 50 max connections and the 
buffers are set to 16000/125MB. This is our master database and it has a 
lot of activity as compared to the other databases. We run VACUUM at 
midday VACUUM FULL at night, VACUUM ANALYZE on weekends.

Thanks

Alvaro Herrera wrote:
> John R Allgood wrote:
>   
>> Hey Tom
>>
>>    Thanks for responding. This issue came around because of a situation 
>> yesterday with processes being killed off by the kernel.  I believe my co 
>> worker Geof Myers sent a post yesterday and the response was to adjust the 
>> vm.commit_memory=2. Several time throughout the day we see memory usage 
>> peak and then it will go down. We have multiple postmasters running for 
>> each of our division so that I we have a problem with a database it only 
>> affects that one. It make it diffucult to tune a system with this many 
>> postmasters running. Each database is tuned according to need. We allow 
>> anywhere between 5-50 max connections. So what I am looking for is?  
>>     
>
> Any of work_mem or maintenance_worm_mem set too high can cause excessive
> memory usage.  What do you have these set to?
>
>   

In response to

Responses

pgsql-admin by date

Next:From: Andrew SullivanDate: 2007-08-28 19:55:54
Subject: Re: How to monitor resources on Linux.
Previous:From: Tom LaneDate: 2007-08-28 19:34:42
Subject: Re: How to import CSV file?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group