From: | Vick Khera <vivek(at)khera(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: shared_buffers 8GB maximum |
Date: | 2018-02-18 16:58:52 |
Message-ID: | CALd+dceMKo=-tA+w_CavPzF6rSjtkLF6GaanFeH6UCY1NA4izA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Feb 18, 2018 at 7:41 AM, Vitaliy Garnashevich <
vgarnashevich(at)gmail(dot)com> wrote:
>
> In the case when shared_buffers cover most of RAM, most of writes should
> happen by checkpointer, and cache hit ratio should be high. So a
> hypothetical question: Could shared_buffers=200GB on a 250 GB RAM server
> ever be a reasonable setting? (assuming there are no other applications
> running except postgres, and 50GB is enough for allocating
> work_mem/maintenance_work_mem and for serving queries)
That amount of shared buffers is not sensible. I found on a 256 GB box that
anything over about 50-100GB was counter productive. That was a FreeBSD
system where I ran the database on top of ZFS, so there was a lot of data
also stored in the ARC (memory cache). There is a setting in postgres to
tell it how much RAM your system is using for the disk cache, so set that
to a fair estimate of how much your system will use. I set mine to 50% of
RAM. I did not limit the cache at the OS level since it is good about
giving up that memory for the needs of the running processes.
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Shepard | 2018-02-18 17:30:18 | Re: Need to fix one more glitch in upgrade to -10.2 |
Previous Message | Adrian Klaver | 2018-02-18 16:56:58 | Re: Need to fix one more glitch in upgrade to -10.2 |