On Wed, Oct 6, 2010 at 10:07 PM, Stephen Frost <sfrost@xxxxxxxxxxx> wrote: > * Robert Haas (robertmhaas@xxxxxxxxx) 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
