From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | pinker <pinker(at)onet(dot)eu> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Block size recommendation for Red Hat Linux 7.2 |
Date: | 2017-04-24 19:26:44 |
Message-ID: | CAOR=d=2vqobHSw9YeDScBNkxJAKd61fk++x_pd0_wbznbh8Bbg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Apr 24, 2017 at 12:43 PM, pinker <pinker(at)onet(dot)eu> wrote:
> I've seen very big differences with huge_pages set to on, especially in
> context of CPU usage on multiple socket servers.
>
> You could play as well with storage options, for instance inode size and
> check if there is any advantage for your db from inlining, which is
> supported by xfs. You can find more informations here:
> http://beegfs.com/wiki/StorageServerTuning
>
> An interesting option for WAL would be to add the mount option- allocsize -
> and set it to 16MB - so the exact size of WAL segment to reduce the risk of
> fragmentation and optimal streaming write throughput.
>
All good options. Also make sure zone reclaim mode is set to 0 on big
memory machines. It's a great setting for big VM hosts but a terrible
one for file or db servers.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Watson | 2017-04-24 19:39:05 | Re: Postgres 9.6.2 and pg_log |
Previous Message | David G. Johnston | 2017-04-24 19:14:33 | Re: Postgres 9.6.2 and pg_log |