Обсуждение: [GENERAL] Block size recommendation for Red Hat Linux 7.2

On Mon, Apr 24, 2017 at 9:41 AM, chiru r <chirupg@gmail.com> wrote:
> Hello,
>
> I am building new server to run PostgreSQL 9.5.4 version on it. Please
> provide the recommended Block size for Linux systems.
>
> We are using PostgreSQL blocks size is 8k default one.
>
> postgres=# show block_size ;
>  block_size
> ------------
>  8192
> (1 row)
>
> Is there any recommendation for separate block sizes on OS level for
> Pg_xlog, pg_log  and  Actual data files to improve the performance for
> reads/Writes?.

Unless you've done some testing to show some other block size is
better, it's best to stick to 8k block size. Keep in mind that while
it is configurable at compile time, it doesn't get much testing at
other sizes and you could run into corner cases where there are
problems and the only acceptable fix is to compile with 8k blocks and
reload your whole db etc.

tl;dr: Stick to 8k blocks.

--
To understand recursion, one must first understand recursion.

Stick to 4k linux block size and you should be OK. I've yet to run
into a situation where changing either has made any measurable
difference.

On Mon, Apr 24, 2017 at 11:58 AM, chiru r <chirupg@gmail.com> wrote:
> Thanks Scott.
> Please suggest the OS block sizes for Linux redhat 7.2, where as default
> Linux block size is 4k.
>
> If we keep 8k block size at OS level is it improves PostgreSQL performance?
> Please suggest what is the suggestible default OS block size for Linux
> systems to install PostgreSQL.
>
> Thanks,
> Chiru
>
> On Mon, Apr 24, 2017 at 12:29 PM, Scott Marlowe <scott.marlowe@gmail.com>
> wrote:
>>
>> On Mon, Apr 24, 2017 at 9:41 AM, chiru r <chirupg@gmail.com> wrote:
>> > Hello,
>> >
>> > I am building new server to run PostgreSQL 9.5.4 version on it. Please
>> > provide the recommended Block size for Linux systems.
>> >
>> > We are using PostgreSQL blocks size is 8k default one.
>> >
>> > postgres=# show block_size ;
>> >  block_size
>> > ------------
>> >  8192
>> > (1 row)
>> >
>> > Is there any recommendation for separate block sizes on OS level for
>> > Pg_xlog, pg_log  and  Actual data files to improve the performance for
>> > reads/Writes?.
>>
>> Unless you've done some testing to show some other block size is
>> better, it's best to stick to 8k block size. Keep in mind that while
>> it is configurable at compile time, it doesn't get much testing at
>> other sizes and you could run into corner cases where there are
>> problems and the only acceptable fix is to compile with 8k blocks and
>> reload your whole db etc.
>>
>> tl;dr: Stick to 8k blocks.
>>
>> --
>> To understand recursion, one must first understand recursion.
>
>



--
To understand recursion, one must first understand recursion.

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.



--
View this message in context:
http://www.postgresql-archive.org/Block-size-recommendation-for-Red-Hat-Linux-7-2-tp5958026p5958066.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

On Mon, Apr 24, 2017 at 12:43 PM, pinker <pinker@onet.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.