From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance |
Date: | 2010-10-04 18:49:43 |
Message-ID: | 4CAA21C7.1030701@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Dan,
(btw, OpenSQL Confererence is going to be at MIT in 2 weeks. Think
anyone from the MOSBENCH team could attend?
http://www.opensqlcamp.org/Main_Page)
> The big takeaway for -hackers, I think, is that lock manager
> performance is going to be an issue for large multicore systems, and
> the uncontended cases need to be lock-free. That includes cases where
> multiple threads are trying to acquire the same lock in compatible
> modes.
Yes; we were aware of this due to work Jignesh did at Sun on TPC-E.
> Currently even acquiring a shared heavyweight lock requires taking out
> an exclusive LWLock on the partition, and acquiring shared LWLocks
> requires acquiring a spinlock. All of this gets more expensive on
> multicores, where even acquiring spinlocks can take longer than the
> work being done in the critical section.
Certainly, the question has always been how to fix it without breaking
major features and endangering data integrity.
> Note that their implementation of the lock manager omits some features
> for simplicity, like deadlock detection, 2PC, and probably any
> semblance of portability. (These are the sort of things we're allowed
> to do in the research world! :-)
Well, nice that you did! We'd never have that much time to experiment
with non-production stuff as a group in the project. So, now we have a
theoretical solution which we can look at maybe implementing parts of in
some watered-down form.
> The other major bottleneck they ran into was a kernel one: reading from
> the heap file requires a couple lseek operations, and Linux acquires a
> mutex on the inode to do that. The proper place to fix this is
> certainly in the kernel but it may be possible to work around in
> Postgres.
Or we could complain to Kernel.org. They've been fairly responsive in
the past. Too bad this didn't get posted earlier; I just got back from
LinuxCon.
So you know someone who can speak technically to this issue? I can put
them in touch with the Linux geeks in charge of that part of the kernel
code.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Adams | 2010-10-04 18:50:43 | Re: Basic JSON support |
Previous Message | Tom Lane | 2010-10-04 18:42:12 | Re: ALTER DATABASE RENAME with HS/SR |
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Ports | 2010-10-04 19:22:32 | Re: MIT benchmarks pgsql multicore (up to 48)performance |
Previous Message | Joshua D. Drake | 2010-10-04 18:44:26 | Re: Issue for partitioning with extra check constriants |