public inbox for [email protected]
help / color / mirror / Atom feedFrom: Rick Otten <[email protected]>
To: Charles Nadeau <[email protected]>
Cc: pgsql-performa. <[email protected]>
Subject: Re: Very poor read performance, query independent
Date: Wed, 12 Jul 2017 10:10:27 -0400
Message-ID: <CAMAYy4Lyjt3iSUi9wQtasX+q_SZoH8GCHvJeYmiSj1owWrzUSQ@mail.gmail.com> (raw)
In-Reply-To: <CADFyZw6McexkAV=p2POXrmHBDgNS7dw-izUvFDmTWyoXeTkp0g@mail.gmail.com>
References: <CADFyZw7aGoD0AaStxdyHByR5Qta=M5wx0v=iptKLhPUp+EOKvA@mail.gmail.com>
<CAMAYy4LiT925ZqouMs6Vs8fz=P53ev_SLH3qK7_7EtUWwUFMBg@mail.gmail.com>
<CADFyZw6McexkAV=p2POXrmHBDgNS7dw-izUvFDmTWyoXeTkp0g@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-performance>
On Wed, Jul 12, 2017 at 9:38 AM, Charles Nadeau <[email protected]>
wrote:
> Rick,
>
> Should the number of page should always be correlated to the VmPeak of the
> postmaster or could it be set to reflect shared_buffer or another setting?
> Thanks!
>
>
The documentation implies that you may need to adjust its size when you
change shared_buffer settings.
I usually check it every now and then (I haven't build a formal monitor
yet.) to see if all of the huge pages are free/used and if it looks like
they are all getting consumed - consider bumping it higher. If there are
lots free, you are probably fine.
cat /proc/meminfo | grep -i "^huge"
--
Also regarding my note on effective_io_concurrency, which I'm not sure you
tried tweaking yet.
With file system and hardware caching between you and your spindles, your
best setting for effective_io_concurrency may be much higher than the
actual number of spindles. It is worth experimenting with. If you can,
try several values. You can use pg_bench to put consistent workloads on
your database for measurement purposes.
Charles
>
> On Mon, Jul 10, 2017 at 5:25 PM, Rick Otten <[email protected]>
> wrote:
>
>> Although probably not the root cause, at the least I would set up
>> hugepages ( https://www.postgresql.org/docs/9.6/static/kernel-resourc
>> es.html#LINUX-HUGE-PAGES ), and bump effective_io_concurrency up quite a
>> bit as well (256 ?).
>>
>>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Very poor read performance, query independent
In-Reply-To: <CAMAYy4Lyjt3iSUi9wQtasX+q_SZoH8GCHvJeYmiSj1owWrzUSQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox