[Patch v2] Make block and file size for WAL and relations defined atcluster creation

Поиск

Список

Период

Сортировка

От	Remi Colinet
Тема	[Patch v2] Make block and file size for WAL and relations defined atcluster creation
Дата	4 января 2018 г. 03:45:36
Msg-id	CADdR5nzdJBTTDSrGBOSc2tA337HFVvNYdh2bJqeGEivQYJ3OiQ@mail.gmail.com обсуждение исходный текст
Ответы	Re: [Patch v2] Make block and file size for WAL and relationsdefined at cluster creation
Список	pgsql-hackers

Дерево обсуждения

Hello,

This is version 2 of the patch to make the file and block sizes for WAL and relations, run-time configurable at initdb.

So far, the relation's block and file sizes have been defined statically at server build time. This is also the case for the WAL block size. This means that it is not possible to share the same Postgresql binary if using different block and file sizes for the WAL and the relations of different server instances/databases, on the same host.

Recently, the value definition of the WAL file size has been converted from server build time to cluster creation time. The current patch goes further in this direction with the relation block and file sizes and with the WAL block size. And some more could be done with LOBLKSIZE for instance (TBD).

Below patch makes block and file sizes defined at cluster creation for both the WAL and the relations. This avoids having different Postgresql server builds for each possible combination of block size and file sizes. With the patch, the values of the block and file sizes are kept in the control file (This has been the case so far) and are provided to initdb when creating the cluster. If no value is specified, the default values are used.

Names and values

Values which can be defined at cluster creation time are:

- the WAL block size
- the WAL file size
- the relation block size
- the relation file size

I noticed that the names of these parameters can slightly vary throughout the source code, whether it is the name or the unit.

Such names are:

BLCKSZ: the relation block size in bytes
RELSEG_SIZE: maximum number of blocks allowed in one disk file
XLOG_BLCKSZ: the WAL block size in bytes
XLOG_SEG_SIZE: the WAL file size in bytes
blcksz (in control file): the relation block size in bytes (same as BLCKSZ)
relseg_size (in control file): the relation file size in blocks (same as RELSEG_SIZE)
xlog_blcksz (in control file): WAL block size in bytes (same as XLOG_BLCKSZ)
xlog_seg_size (in control file); the WAL file size in bytes (same as XLOG_SEG_SIZE)

WalSegSz (in pg_resetwal.c): the WAL segment size in bytes

wal_segment_size (in xlog.c): the WAL segment size in bytes

segment_size (in guc.c): the relation segment size

For the current patch, I have defined common names to be used throughout in the source code, whether this in the server or in the different utilities with units in:

- bytes for the blocks sizes

- blocks for the files sizes

These are:

- wal_blck_size: which replaces XLOG_BLCKSZ

- wal_file_blck

- wal_file_size: which is wal_blck_size * wal_file_blck. It replaces XLOG_SEG_SIZE and wal_segment_size

- rel_blck_size: which replaces BLCKSZ

- rel_file_blck: it replaces RELSEG_SIZE and segment_size

- rel_file_size: which is rel_blck_size * rel_file_blck.

Lower case letters are used to remind that these values are not statically defined at compile time.

Patch

The patch is made only of small changes unless a few files which require some more work with palloc/pfree.

The most concerned files are:

src/backend/access/heap/pruneheap.c

src/backend/access/nbtree/nbtree.c

src/backend/access/nbtree/nbtsearch.c

src/backend/access/transam/generic_xlog.c

src/backend/access/transam/xlog.c

src/backend/nodes/tidbitmap.c

src/bin/initdb/initdb.c

tidbitmap.c is most concerned file because it includes the simplehash.h header.

But even for this file, the change is eventually straightforward.

Other affected files have tiny changes or changes which do not incur any hurdle.

The patch is built on top of commit 0772c152b9bd02baeca6920c3371fce95e8f13dc (Mon Nov 27 20:56:46 2017 -0500).

I will rebase with the latest version once I have completed all the initial tests with the different possible combinations of blocks and files sizes, both for the relations and the WAL files.

Rationale

Justifications are:

- we may test different combinations of file and block sizes, for the relation and the WAL in order to have the better performances of the server.

Avoiding a compilation for each combination of values seems to make sense.

- the same binary can be used on the same host with several databases instances/cluster, each using different values for block and file sizes.

This is what I did to test the patch. I have created about 20 different combinations of values for the file and block sizes of the relation and WAL files.

- Linux distributions deliver Postgresql with a binary already compiled with the default values.

This means DBAs need to rebuild the binary for each combination of block and file sizes, whether this is for the WAL or the relations.

- Selecting the correct values for file and block sizes is a DBA task, and not a developer task.

For instance, when someone wants to create a Linux filesystem with a given block size, he is not forced to accept a given value chosed by the developer of the file system driver when this later was compiled.

- The file and block sizes should depend mostly of the physical server and physical storage. Not on the database software itself.

Regarding the cost of using run-time configurable values for file and block sizes of the WAL and relations, this cost is low both :

- from a developer point of view: the source code changes are spread in many files but only a few one have significant changes.

Mainly the tidbitmap.c is concerned the change. Other changes are minor changes.

- from a run-time point of view. The overhead is only at the start of the database instance.
And moreover, the overhead is still very low at the start of the server, with only a few more dynamic memory allocations.

Test cases

Below combinations of values have been tested so far, by creating a cluster and filling a table with 10 to 200 millions rows.

WAL file and WAL block sizes were nopt changed so far.

rel_blck_size
--rel_blck_size=1024 --rel_file_blck=1048576 --wal_blck_size=8192 --wal_file_blck=32768 ok      (1GB file relation files/ 256MB wal files)
--rel_blck_size=2048 --rel_file_blck=524288 --wal_blck_size=8192 --wal_file_blck=32768 ok       (1GB file)
--rel_blck_size=4096 --rel_file_blck=262144 --wal_blck_size=8192 --wal_file_blck=32768 ok       (1GB file)
--rel_blck_size=8192 --rel_file_blck=131072 --wal_blck_size=8192 --wal_file_blck=32768 ok       (1GB file)
--rel_blck_size=16384 --rel_file_blck=65536 --wal_blck_size=8192 --wal_file_blck=32768 ok       (1GB file)
--rel_blck_size=32768 --rel_file_blck=32768 --wal_blck_size=8192 --wal_file_blck=32768 ok       (1GB file)

rel_file_blck
--rel_blck_size=8192 --rel_file_blck=262144 --wal_blck_size=8192 --wal_file_blck=32768 ok       (2GB files)
--rel_blck_size=8192 --rel_file_blck=524288 --wal_blck_size=8192 --wal_file_blck=32768 ok       (4GB files)
--rel_blck_size=8192 --rel_file_blck=1048576 --wal_blck_size=8192 --wal_file_blck=32768 ok      (8GB files)

Further tests are going to be done with different combinations of block and file sizes for the WAL.

To do

Convert large object compile time block and file size to run-time parameters

Further tests with different combinations of block and file sizes.

Rebase on latest commit of master Postgresql tree.

Remove debugging code introduced by the current patch

Split current patch into smaller chunks.

Change log

Fixed bug in simplehash.h caused by &data[i] dereferences for which data is an array of PageTableentry.

Removed debugging code from tidbitmap.c and simplehash.h

Fixed REL_FILE_SIZE macros overflow warning caused by missing types in pg_control_def.h macros

Tests done with above cases

Initial version of the patch not yet fully tested

Вложения

blkfilesizes_v2.patch

В списке pgsql-hackers по дате отправления:

Предыдущее

От: Stephen Frost
Дата: 04 января 2018 г., 03:21:42
Сообщение: Re: CFM for January commitfest?

Следующее

От: Greg Stark
Дата: 04 января 2018 г., 03:57:01
Сообщение: LIKE foo% optimization easily defeated by OR?

Вход в личный кабинет

Восстановление пароля

Подтверждение аккаунта

Изменение пароля

[Patch v2] Make block and file size for WAL and relations defined atcluster creation

Вложения

Предыдущее

Следующее