Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance - Mailing list pgsql-performance

From Tom Lane
Subject Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Date
Msg-id 16636.1286414707@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  (Ivan Voras <ivoras@freebsd.org>)
Responses Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  (Ivan Voras <ivoras@freebsd.org>)
List pgsql-performance
Ivan Voras <ivoras@freebsd.org> writes:
> On 10/04/10 20:49, Josh Berkus wrote:
>>> 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.

> Hmmm... lseek? As in "lseek() then read() or write()" idiom? It AFAIK
> cannot be fixed since you're modifying the global "strean position"
> variable and something has got to lock that.

Um, there is no "global stream position" associated with an inode.
A file position is associated with an open-file descriptor.

If Josh quoted the problem correctly, the issue is that the kernel is
locking a file's inode (which may be referenced by quite a lot of file
descriptors) in order to change the state of one file descriptor.
It sure sounds like a possible source of contention to me.

            regards, tom lane

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance