Re: [HACKERS] Should we cacheline align PGXACT?
От | Ashutosh Sharma |
---|---|
Тема | Re: [HACKERS] Should we cacheline align PGXACT? |
Дата | |
Msg-id | CAE9k0P=84-naHEpyaTYmcev7LBJ99fmeJuxNVZMz-CHPCqYquA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Should we cacheline align PGXACT? (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Should we cacheline align PGXACT?
|
Список | pgsql-hackers |
On Tue, Feb 28, 2017 at 11:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
Okay, I already had the results for read-oly workload but just forgot to share it along with the results for read-write test. Here are the results for read-only
test,
On 28 February 2017 at 11:34, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:So, Here are the pgbench results I got with 'reduce_pgxact_access_AtEOXact.v2.patch' on a read-write workload. Thanks for performing a test.I see a low yet noticeable performance gain across the board on that workload.That is quite surprising to see a gain on that workload. The main workload we have been discussing was the full read-only test (-S). For that case the effect should be much more noticeable based upon Andres' earlier comments.Would it be possible to re-run the test using only the -S workload? Thanks very much.
Okay, I already had the results for read-oly workload but just forgot to share it along with the results for read-write test. Here are the results for read-only
test,
CLIENT COUNT | TPS (HEAD) | TPS (PATCH) | % IMPROVEMENT |
4 | 26322 | 31259 | 18.75617354 |
8 | 63499 | 69472 | 9.406447346 |
16 | 181155 | 186534 | 2.96928045 |
32 | 333504 | 337533 | 1.208081462 |
64 | 350341 | 353747 | 0.9721956608 |
72 | 366339 | 373898 | 2.063389374 |
128 | 443381 | 478562 | 7.934710779 |
180 | 299875 | 334118 | 11.41909129 |
196 | 269194 | 275525 | 2.351835479 |
256 | 220027 | 235995 | 7.257291151 |
The pgbench settings and non-default params are,
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading -S postgres
where, time_for_reading = 10mins
non default param:
shared_buffers=8GB
max_connections=300
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www. enterprisedb.com
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading -S postgres
where, time_for_reading = 10mins
non default param:
shared_buffers=8GB
max_connections=300
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.
pgbench settings:
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading postgres
where, time_for_reading = 30mins
non default GUC param
shared_buffers=8GB
max_connections=300
pg_wal is located in SSD.
CLIENT COUNT TPS (HEAD) TPS (PATCH) % IMPROVEMENT 4 2588 2601 0.5023183926 8 5094 5098 0.0785237534 16 10294 10307 0.1262871576 32 19779 19815 0.182011224 64 27908 28346 1.569442454 72 27823 28416 2.131330194 128 28455 28618 0.5728342998 180 26739 26879 0.5235797898 196 27820 27963 0.5140186916 256 28763 28969 0.7161978931
Also, Excel sheet (results-readwrite-300-SF.xlsx) containing the results for all the 3 runs is attached. --Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: