On Tue, Sep 23, 2014 at 5:50 PM, Robert Haas <robertmh...@gmail.com> wrote: > The patch I attached the first time was just the last commit in the > git repository where I wrote the patch, rather than the changes that I > made on top of that commit. So, yes, the results from the previous > message are with the patch attached to the follow-up. I just typed > the wrong git command when attempting to extract that patch to attach > it to the email.
Here are some more results. TL;DR: The patch still looks good, but we should raise the number of buffer mapping partitions as well. On the IBM POWER7 machine, I ran read-only pgbench tests with 1 client, 8 clients, and all multiples of 16 up to 96. I ran these tests at scale factor 1000 and scale factor 3000. I tested four builds: master as of commit df4077cda2eae3eb4a5cf387da0c1e7616e73204, that same commit with the number of buffer mapping partitions raised to 128, that commit with reduce-replacement-locking.patch applied, and that commit with reduce-replacement-locking.patch applied AND the number of buffer mapping partitions raised to 128. The results from each configuration are reported in that order on each of the lines below; each is the median of three results. shared_buffers=8GB for all tests. scale factor 1000 1 8119.907618 8230.853237 8153.515217 8145.045004 8 65457.006762 65826.439701 65851.010116 65703.168020 16 125263.858855 125723.441853 125020.598728 129506.037997 32 176696.288187 182376.232631 178278.917581 186440.340283 48 193251.602743 214243.417591 197958.562641 226782.327868 64 182264.276909 218655.105894 190364.759052 256863.652885 80 171719.210488 203104.673512 179861.241080 274065.020956 96 162525.883898 190960.622943 169759.271356 277820.128782 scale factor 3000 1 7690.357053 7723.925932 7772.207513 7684.079850 8 60789.325087 61688.547446 61485.398967 62546.166411 16 112509.423777 115138.385501 115606.858594 120015.350112 32 147881.211900 161359.994902 153302.501020 173063.463752 48 129748.929652 153986.160920 136164.387103 204935.207578 64 114364.542340 132174.970721 116705.371890 224636.957891 80 101375.265389 117279.931095 102374.794412 232966.076908 96 93144.724830 106676.309224 92787.650325 233862.872939 Analysis: 1. To see the effect of reduce-replacement-locking.patch, compare the first TPS number in each line to the third, or the second to the fourth. At scale factor 1000, the patch wins in all of the cases with 32 or more clients and exactly half of the cases with 1, 8, or 16 clients. The variations at low client counts are quite small, and the patch isn't expected to do much at low concurrency levels, so that's probably just random variation. At scale factor 3000, the situation is more complicated. With only 16 bufmappinglocks, the patch gets its biggest win at 48 clients, and by 96 clients it's actually losing to unpatched master. But with 128 bufmappinglocks, it wins - often massively - on everything but the single-client test, which is a small loss, hopefully within experimental variation. 2. To see the effect of increasing the number of buffer mapping locks to 128, compare the first TPS number in each line to the second, or the third to the fourth. Without reduce-replacement-locking.patch, that's a win at every concurrency level at both scale factors. With that patch, the 1 and 8 client tests are small losses at scale factor 1000, and the 1 client test is a small loss at scale factor 3000. The single-client results, which are often a concern for scalability patches, bear a bit of further comment. In this round of testing, either patch alone improved things slightly, and both patches together made them slightly worse. Even if that is reproducible, I don't think it should be cause for concern, because it tends to indicate (at least to me) that the shifting around is just the result of slightly different placement of code across cache lines, or other minor factors we can't really pin down. So I'm inclined to (a) push reduce-replacement-locking.patch and then also (b) bump up the number of buffer mapping locks to 128 (and increase MAX_SIMUL_LWLOCKS accordingly so that pg_buffercache doesn't get unhappy). Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers