Re: shared_buffers/effective_cache_size on 96GB server

From: Strahinja Kustudić <strahinjak(at)nordeus(dot)com>
To: sthomas(at)optionshouse(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Date: 2012-10-10 14:49:47
Message-ID: CADKbJJW-q+swRfYPmuy1wKeUh_w9=OcuyOhNSkSeSSeowpPLfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I will change those, but I don't think this is that big of an issue if most
of the IO is done by Postgres, since Postgres has it's own mechanism to
tell the OS to sync the data to disk. For example when it's writing a wal
file, or when it's writing a check point, those do not get cached.

Regards,
Strahinja

On Wed, Oct 10, 2012 at 4:38 PM, Shaun Thomas <sthomas(at)optionshouse(dot)com>wrote:

> On 10/10/2012 09:35 AM, Strahinja Kustudić wrote:
>
> #sysctl vm.dirty_ratio
>> vm.dirty_ratio = 40
>> # sysctl vm.dirty_background_ratio
>> vm.dirty_background_ratio = 10
>>
>
> Ouuuuch. That looks a lot like an old RHEL or CentOS system. Change those
> ASAP. Currently your system won't start writing dirty buffers until it hits
> 9.6GB. :(
>
>
> shows that these values are even higher by default. When you said
>> RAID buffer size, you meant the controllers cache memory size?
>>
>
> Yeah, that. :)
>
>
> --
> Shaun Thomas
> OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
> 312-444-8534
> sthomas(at)optionshouse(dot)com
>
> ______________________________**________________
>
> See http://www.peak6.com/email_**disclaimer/<http://www.peak6.com/email_disclaimer/>for terms and conditions related to this email
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2012-10-10 14:54:19 Re: shared_buffers/effective_cache_size on 96GB server
Previous Message Shaun Thomas 2012-10-10 14:38:15 Re: shared_buffers/effective_cache_size on 96GB server