A
A
Alexey Lesovsky2013-02-08 08:28:19
PostgreSQL
Alexey Lesovsky, 2013-02-08 08:28:19

PG performance testing on different fs

Hello!
Friends! I wanted to test postgres performance on two fs ext4 and xfs.
I decided to do it this way:
- allocate a partition (LVM) 50GB;
- format under one fs (default formatting options);
— perform pgbench initialization of the database in such a way as to fill 90% of the section;
- run a one-hour pgbench (TPC-B) execution emulating the number of clients 8, 16, 32, 64, 96 (i.e. for one fs, I will get 5 results);
- format the same partition under the second fs and repeat all over again.
The postgres config is the same throughout all tests.

The question is, is it possible to trust the results of the tests received and make a decision in favor of using the winning fs (the one with the higher tps value)?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
A
Alexey Lesovsky, 2013-02-08
@lesovsky

Should I post the results when it's all over?

A
Alexey Lesovsky, 2013-02-15
@lesovsky

so new data
1. WAL needs to be resettled to a neighboring physical disk/reid
2. execution time needs more
3. iostat? whether and in what form it is necessary to collect it, the footcloth accumulated for several hours of the test still needs to be analyzed somehow

P
pasha_golub, 2013-02-08
@pasha_golub

In principle, the test is fair, but still remains synthetic. Postgres has a lot of options for fine-tuning. They are the ones who decide. The file system, as for me, is one of the non-key factors.

F
FYR, 2013-02-15
@FYR

I would suggest:
1. Move WAL and data to different partitions, remove iostat -x from both partitions during testing (too different load, constant sync or large write).
2. Working with the file system is better illustrated by arbitrary queries to random tables (random access to different files) with a small number of max_files_per_process (for example, about 30) so that you have to constantly open / close files.
3. It is also interesting to look at the checkpoint log again when writing / updating in a large number of tables.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question