From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ivan Voras <ivoras@freebsd.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Date: Wed, 06 Oct 2010 21:25:07 -0400
Message-ID: <16636.1286414707@sss.pgh.pa.us> (raw)
In-Reply-To: <i8itbn$kre$1@dough.gmane.org>
References: <AANLkTimW2UgVPGw6MRUBj9HabvwmsmkZasL3hKv-nUJ2@mail.gmail.com>
<20101004175545.GA2690@csail.mit.edu>
<4CAA21C7.1030701@agliodbs.com>
<i8itbn$kre$1@dough.gmane.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, ivoras@freebsd.org
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
In-Reply-To: <16636.1286414707@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox