On Fri, Jul 15, 2011 at 4:41 PM, Josh Berkus <j...@agliodbs.com> wrote: > (1) can you re-link me to the pgbench and sysbench setup you used to > test this originally? I'd like to implement those.
I didn't use sysbench. The pgbench command I used was something like: pgbench -n -S -T $TIME -c $CLIENTS -j $CLIENTS ...with varying times and client counts. Three minutes or so seems to be enough to get a reasonably good measurement. We have a report from another tester that -M prepared exacerbates the effect of the main fastlock patch (which I just committed) so that might be worth trying here, too. > (2) the max machine I can test these on is 16 cores. Is that adequate, > or do we need more cores for real testing? I think you should be able to see a small benefit on a machine of that size. My memory is a bit fuzzy because it's 1 AM and I haven't looked at this in over a week, but I believe that this patch produces only a small improvement in performance by itself, apparently because most of the gain that we get from reducing lock manager contention gets eaten up by additional spinlock contention. However, I think the change is worthwhile anyway, because the benefit of any changes we might make to reduce spinlock contention is going to be limited by the rate at which we can shove traffic through the lock manager. In other words, aside from whatever benefit this patch may have on its own, I believe it's an enabler for future performance work. In mulling over this patch, it's occurred to me that there are some stylistic things about it that can stand to be improved. So I'm going to do that for the next version. However, if you want to test on this version, feel free, because I think those changes are going to have little if any effect on performance. -- 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
