> scale factor = 3000 > Client Count = number of concurrent sessions and threads (ex. -c 8 -j 8) > Duration of each individual run = 5mins > > All the data is in tps and taken using pgbench read-only load
Common configuration remains same as above.
Shared_Buffers = 500MB
Client Count/Patch_Ver
8
16
32
64
128
HEAD
56248
100112
121341
81128
56552
Patch
59389
112483
157034
185740
166725
..
Observations
---------------------
1. Performance improvement is upto 2~3 times for higher client
counts (64, 128).
2. For lower client count (8), we can see 2~5 % performance
improvement.
3. Overall, this improves the read scalability.
4. For lower number of shared buffers, we see that there is a minor
dip in tps even after patch (it might be that we can improve it by
tuning higher water mark for the number of buffers on freelist, I will
try this by varying high water mark).
I have taken performance data by varying high and low mater marks
for lower value of shared buffers which is as below:
Shared_buffers = 500MB
Scale_factor = 3000
HM - High water mark, 0.5 means 0.5% of total shared buffers
LM - Low water mark, 20 means 20% of HM.
Client Count/Patch_Ver (Data in tps)
128
HM=0.5;LM=20
166725
HM=1;LM=20
166556
HM=2;LM=30
166463
HM=5;LM=30
166107
HM=10;LM=30
167231
Observation
--------------------
a. There is hardly any difference by varying High and Low water marks
as compared to default values currently used in patch.
b. I think this minor dip as compare to 64 client count is because one
this m/c has 64 hardware threads due which scaling beyond 64 client
count is difficult and second at relatively lower buffer count (500MB),
there is still minor contention around Buf Mapping locks.
In general, I think with patch the scaling is much better (2 times) than
HEAD, even when shared buffers are less and client count is high,