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
>
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 |