On Wed, Oct 6, 2010 at 10:07 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> It's good to be you.
>
> They're HP BL465 G7's w/ 2x 12-core AMD processors and 48G of RAM.
> Unfortunately, they currently only have local storage, but it seems
> unlikely that would be an issue for this.
>
>> I don't suppose you could try to replicate the lseek() contention?
>
> I can give it a shot, but the impression I had from the paper is that
> the lseek() contention wouldn't be seen without the changes to the lock
> manager...? Or did I misunderstand?
<rereads appropriate section of paper>
Looks like the lock manager problems hit at 28 cores, and the lseek
problems at 36 cores. So your system might not even be big enough to
manifest either problem.
It's unclear to me whether a 48-core system would be able to see the
lseek issues without improvements to the lock manager, but perhaps it
would be possible by, say, increasing the number of lock partitions by
8x. It would be nice to segregate these issues though, because using
pread/pwrite is probably a lot less work than rewriting our lock
manager. Do you have tools to measure the lseek overhead? If so, we
could prepare a patch to use pread()/pwrite() and just see whether
that reduced the overhead, without worrying so much about whether it
was actually a major bottleneck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
