On Mon, Nov 14, 2016 at 9:33 AM, Michael Paquier <
michael.paquier@gmail.com> wrote:
> On Mon, Nov 14, 2016 at 12:49 PM, Kyotaro HORIGUCHI
> <
horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> At Sat, 12 Nov 2016 10:28:56 +0530, Amit Kapila <
amit.kapila16@gmail.com> wrote in <
CAA4eK1K0gGQTBxCyKqi6QnqOWGzEoVVPHCgPJ_RkOBoLPejCTA@mail.gmail.com>
>>> I think it is good to check the performance impact of this patch on
>>> many core m/c. Is it possible for you to once check with Alexander
>>> Korotkov to see if he can provide you access to his powerful m/c which
>>> has 70 cores (if I remember correctly)?
>
> I heard about a number like that, and there is no reason to not do
> tests to be sure.
>
Okay, I have done some performance tests with this patch and found that it doesn't have any noticeable impact which is good. Details of performance tests is below:
Machine configuration:
2 sockets, 28 cores (56 including Hyper-Threading)
RAM = 64GB
Data directory is configured on the magnetic disk and WAL on SSD.
Non-default postgresql.conf parameters
shared_buffers=8GB
max_connections=200
bgwriter_delay=10ms
checkpoint_completion_target=0
Keeping above parameters as fixed, I have varied checkpoint_timeout for various tests. Each of the below results is a median of 3, 15min pgbench TPC-B tests. All the tests are performed at 64 and or 128 client-count (Client Count = number of concurrent sessions and threads (ex. -c 8 -j 8)). All the tests are done for pgbench scale factor - 300 which means data fits in shared buffers.
checkpoint_timeout=30s
| client_count/patch_ver | 64 | 128 |
| HEAD | 5176 | 6853 |
| Patch | 4963 | 6556 |
checkpoint_timeout=60s
client_count/patch_ver
| 64 | 128 |
| HEAD | 4962 | 6894 |
| Patch | 5228 | 6814 |
checkpoint_timeout=120s
client_count/patch_ver
| 64 | 128 |
| HEAD | 5443 | 7308 |
| Patch | 5453 | 6937 |
checkpoint_timeout=150s
client_count/patch_ver
| 128 |
| HEAD | 7316 |
| Patch | 7188 |
In above results, you can see that in some cases (example, for checkpoint_time=30s, @128-client count) TPS with the patch is slightly lower(1~5%), but I find that as a run-to-run variation, because on repeating the tests, I could not see such regression. The reason of keeping low values for checkpoint_timeout and bgwriter_delay is to test if there is any impact due to new locking introduced in checkpointer and bgwriter. The conclusion from my tests is that this patch is okay as far as performance is concerned.