Message-ID: <4E9356E5.6000308@gmail.com>
Date: Mon, 10 Oct 2011 17:34:45 -0300
From: alexandre - aldeia digital <adaldeia@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
CC: pgsql-performance@postgresql.org
Subject: Re: Adding more memory = hugh cpu load
References: <4E92F294.9010405@gmail.com> <4E92FB87.1030703@peak6.com>
	<4E932BFC.7070007@gmail.com>
	<4E92E9340200002500041CD5@gw.wicourts.gov>
	<4E933F4B.2080808@gmail.com>
	<4E9303A00200002500041CFE@gw.wicourts.gov>
In-Reply-To: <4E9303A00200002500041CFE@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Em 10-10-2011 16:39, Kevin Grittner escreveu:
> alexandre - aldeia digital<adaldeia@gmail.com>  wrote:
>
>>  From the point of view of the client, the question is simple:
>> until the last friday (with 16 GB of RAM), the load average of
>> server rarely surpasses 4. Nothing change in normal database use.
>
> Really?  The application still performs as well or better, and it's
> the load average they care about?  How odd.
>
> If they were happy with performance before the RAM was added, why
> did they add it?  If they weren't happy with performance, what led
> them to believe that adding more RAM would help?  If there's a
> performance problem, there's generally one bottleneck which is the
> limit, with one set of symptoms.  When you remove that bottleneck
> and things get faster, you may well have a new bottleneck with
> different symptoms.  (These symptoms might include high load average
> or CPU usage, for example.)  You then figure out what is causing
> *that* bottleneck, and you can make things yet faster.

Calm down: if the client plans to add , for example, another database
in his server in a couple of weeks, he must only upgrade when this new 
database come to life and add another point of doubt ??? IMHO, the 
reasons to add MEMORY does not matters in this case. I came to the list 
to see if anyone else has experienced the same problem, that not 
necessarily is related with Postgres. Shaun and Greg apparently had the 
same the same problems in CentOS and the information provided by they 
helped too much...