Re: shared_buffer optimization - Mailing list pgsql-performance

From Ruben Rubio
Subject Re: shared_buffer optimization
Date
Msg-id 44D9BDE5.9060202@rentalia.com
Whole thread Raw
In response to Re: shared_buffer optimization  (Christopher Browne <cbbrowne@acm.org>)
List pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So ...
I have tried different values. The best one for one day sentences seems
to be 24576

IO in vmstat has the lowest values
"id" (idle) has the biggest values.

I have created an script that executes all day sentences to try that.

By the way, could u explain a little bit this?

"The "rule of thumb" is to set shared buffers to the lesser of 10000
 and 15% of system memory.  In your case, that would be the lesser of
 10000 and 78643, which is 10000."

Im sorry but im not understanding it at all.

Thanks in advance.


Christopher Browne wrote:
> Quoth ruben@rentalia.com (Ruben Rubio):
>> Hi, I have a question with shared_buffer.
>>
>> Ok, I have a server with 4GB of RAM
>> -----
>> # cat /proc/meminfo
>> MemTotal:      4086484 kB
>> [...]
>> -----
>>
>> So, if I want to, for example, shared_buffer to take 3 GB of RAM then
>> shared_buffer would be 393216 (3 * 1024 * 1024 / 8)
>>
>> Postmaster dont start.
>> Error: FATAL:  shmat(id=360448) failed: Invalid argument
>>
>>
>> I can set a less value, but not higher than 3 GB.
>>
>> Am I doing something wrong?
>> Any idea?
>
> Yes, you're trying to set the value way too high.
>
> The "rule of thumb" is to set shared buffers to the lesser of 10000
> and 15% of system memory.  In your case, that would be the lesser of
> 10000 and 78643, which is 10000.
>
> I'm not aware of any actual evidence having emerged that it is of any
> value to set shared buffers higher than 10000.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE2b3kIo1XmbAXRboRAh12AKCodmhmXZWamrG7MnAf9mhVfubjgwCfa75v
7bgmSzq4F7XpBoEkSpyDqnE=
=3lMc
-----END PGP SIGNATURE-----

pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Hardware upgraded but performance still ain't good enough
Next
From: Patrice Beliveau
Date:
Subject: Re: Optimizing queries