Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance - Mailing list pgsql-hackers

From Dave Chinner
Subject Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Date
Msg-id 20140116232342.GA18112@dastard
Whole thread Raw
In response to Re: Linux kernel impact on PostgreSQL performance  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Wed, Jan 15, 2014 at 06:14:18PM -0600, Jim Nasby wrote:
> On 1/15/14, 12:00 AM, Claudio Freire wrote:
> >My completely unproven theory is that swapping is overwhelmed by
> >near-misses. Ie: a process touches a page, and before it's
> >actually swapped in, another process touches it too, blocking on
> >the other process' read. But the second process doesn't account
> >for that page when evaluating predictive models (ie: read-ahead),
> >so the next I/O by process 2 is unexpected to the kernel. Then
> >the same with 1. Etc... In essence, swap, by a fluke of its
> >implementation, fails utterly to predict the I/O pattern, and
> >results in far sub-optimal reads.
> >
> >Explicit I/O is free from that effect, all read calls are
> >accountable, and that makes a difference.
> >
> >Maybe, if the kernel could be fixed in that respect, you could
> >consider mmap'd files as a suitable form of temporary storage.
> >But that would depend on the success and availability of such a
> >fix/patch.
> 
> Another option is to consider some of the more "radical" ideas in
> this thread, but only for temporary data. Our write sequencing and
> other needs are far less stringent for this stuff.  -- Jim C.

I suspect that a lot of the temporary data issues can be solved by
using tmpfs for temporary files....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: wal_buffers = -1
Next
From: Dave Chinner
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance