Re: testing ProcArrayLock patches
От | Kevin Grittner |
---|---|
Тема | Re: testing ProcArrayLock patches |
Дата | |
Msg-id | 4ECA328F0200002500043310@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: testing ProcArrayLock patches ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: testing ProcArrayLock patches
(Pavan Deolasee <pavan.deolasee@gmail.com>)
|
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > I can run one more set of tests tonight before I have to give it > back to the guy who's putting it into production. It sounds like > a set like the above except with synchronous_commit = off might be > desirable? OK, that's what I did. This gave me my best numbers yet for an updating run of pgbench: tps = 38039.724212 for prepared statements using the flexlock patch. This patch is a clear win when you get to 16 clients or more. sm1 tps = 1312.501168 (including connections establishing) sf1 tps = 1376.678293 (including connections establishing) sm2 tps = 2705.571856 (including connections establishing) sf2 tps = 2689.577938 (including connections establishing) sm4 tps = 5461.403557 (including connections establishing) sf4 tps = 5447.363103 (including connections establishing) sm8 tps = 10524.695338 (including connections establishing) sf8 tps = 10448.012069 (including connections establishing) sm16 tps = 18952.968472 (including connections establishing) sf16 tps = 18969.505631 (including connections establishing) sm32 tps = 27392.393850 (including connections establishing) sf32 tps = 29225.974112 (including connections establishing) sm64 tps = 28947.675549 (including connections establishing) sf64 tps = 31417.536816 (including connections establishing) sm80 tps = 28053.684182 (including connections establishing) sf80 tps = 29970.555401 (including connections establishing) sm96 tps = 25885.679957 (including connections establishing) sf96 tps = 28581.271436 (including connections establishing) sm128 tps = 22261.902571 (including connections establishing) sf128 tps = 24537.566960 (including connections establishing) pm1 tps = 2082.958841 (including connections establishing) pf1 tps = 2052.328339 (including connections establishing) pm2 tps = 4287.257860 (including connections establishing) pf2 tps = 4228.770795 (including connections establishing) pm4 tps = 8653.196863 (including connections establishing) pf4 tps = 8592.091631 (including connections establishing) pm8 tps = 16071.432101 (including connections establishing) pf8 tps = 16196.992207 (including connections establishing) pm16 tps = 27146.441216 (including connections establishing) pf16 tps = 27441.966562 (including connections establishing) pm32 tps = 34983.352396 (including connections establishing) pf32 tps = 38039.724212 (including connections establishing) pm64 tps = 33182.643501 (including connections establishing) pf64 tps = 34193.732669 (including connections establishing) pm80 tps = 30686.712607 (including connections establishing) pf80 tps = 33336.011769 (including connections establishing) pm96 tps = 24692.015615 (including connections establishing) pf96 tps = 32907.472665 (including connections establishing) pm128 tps = 24164.441954 (including connections establishing) pf128 tps = 25742.670928 (including connections establishing) At lower client numbers the tps values within each set of five samples were very tightly grouped. With either protocol, and whether or not the patch was applied, the higher concurrency groups tended to be bifurcated within a set of five samples between "good" and "bad" numbers. The patch seemed to increase the number of clients which could be handled without collapse into the bad numbers. It really looks like there's some sort of performance "collapse" at higher concurrency which may or may not happen in any particular five minute run. Just as one example, running the simple protocol with the flexlock patch: tps = 24491.653873 (including connections establishing) tps = 24537.566960 (including connections establishing) tps = 28462.276323 (including connections establishing) tps = 24403.373002 (including connections establishing) tps = 28458.902549 (including connections establishing) -Kevin
В списке pgsql-hackers по дате отправления: