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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Дата
Msg-id 16636.1286414707@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  (Ivan Voras <ivoras@freebsd.org>)
Ответы Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  (Ivan Voras <ivoras@freebsd.org>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance