the trifecta
I'm not saying that O_DIRECT is easy or perfect, but it seems to me
to be a more robust, secure, maintainable and simpler solution than
trying to give applications direct control over complex internal
kernel structures and algorithms.
Cheers,
Dave.
--
Dave Chinner
da
.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
provide.
Just food for thought
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
dirty_background_bytes, dirty_bytes and
dirty_expire_centiseconds to be much smaller should make the kernel
start writeback much sooner and so you shouldn't have to limit the
amount of buffers the application has to prevent major fsync
triggered stalls...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Jan 15, 2014 at 08:03:28AM +1300, Gavin Flower wrote:
On 14/01/14 14:09, Dave Chinner wrote:
On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote:
On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund and...@2ndquadrant.com
wrote:
[...]
The more ambitious and interesting direction
On Tue, Jan 14, 2014 at 03:03:39PM -0800, Kevin Grittner wrote:
Dave Chinner da...@fromorbit.com write:
Essentially, changing dirty_background_bytes, dirty_bytes and
dirty_expire_centiseconds to be much smaller should make the
kernel start writeback much sooner and so you shouldn't have
On Tue, Jan 14, 2014 at 05:38:10PM -0700, Jonathan Corbet wrote:
On Wed, 15 Jan 2014 09:23:52 +1100
Dave Chinner da...@fromorbit.com wrote:
It appears to me that we are seeing large memory machines much more
commonly in data centers - a couple of years ago 256GB RAM was only
seen
On Tue, Jan 14, 2014 at 09:54:20PM -0600, Jim Nasby wrote:
On 1/14/14, 3:41 PM, Dave Chinner wrote:
On Tue, Jan 14, 2014 at 09:40:48AM -0500, Robert Haas wrote:
On Mon, Jan 13, 2014 at 5:26 PM, Mel Gorman mgor...@suse.de
wrote: Whether the problem is with the system call or the
programmer
On Wed, Jan 15, 2014 at 10:12:38AM -0500, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 01/15/2014 07:50 AM, Dave Chinner wrote:
FWIW [and I know you're probably sick of hearing this by now], but
the blk-io throttling works almost perfectly with applications
On Wed, Jan 15, 2014 at 02:29:40PM -0800, Jeff Janes wrote:
On Wed, Jan 15, 2014 at 7:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 01/15/2014 07:50 AM, Dave Chinner wrote:
FWIW [and I know you're probably sick of hearing this by now
it
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 15, 2014 at 07:13:27PM -0500, Tom Lane wrote:
Dave Chinner da...@fromorbit.com writes:
On Wed, Jan 15, 2014 at 02:29:40PM -0800, Jeff Janes wrote:
And most importantly, Also, please don't freeze up everything else in the
process
If you hand writeback off to the kernel
On Wed, Jan 15, 2014 at 07:08:18PM -0500, Tom Lane wrote:
Dave Chinner da...@fromorbit.com writes:
On Wed, Jan 15, 2014 at 10:12:38AM -0500, Tom Lane wrote:
What we'd really like for checkpointing is to hand the kernel a boatload
(several GB) of dirty pages and say how about you push all
On Wed, Jan 15, 2014 at 07:31:15PM -0500, Tom Lane wrote:
Dave Chinner da...@fromorbit.com writes:
On Wed, Jan 15, 2014 at 07:08:18PM -0500, Tom Lane wrote:
No, we'd be happy to re-request it during each checkpoint cycle, as
long as that wasn't an unduly expensive call to make. I'm
On Thu, Jan 16, 2014 at 03:58:56PM -0800, Jeff Janes wrote:
On Thu, Jan 16, 2014 at 3:23 PM, Dave Chinner da...@fromorbit.com wrote:
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
data issues can be solved by
using tmpfs for temporary files
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 16, 2014 at 08:48:24PM -0500, Robert Haas wrote:
On Thu, Jan 16, 2014 at 7:31 PM, Dave Chinner da...@fromorbit.com wrote:
But there's something here that I'm not getting - you're talking
about a data set that you want ot keep cache resident that is at
least an order of magnitude
than memory so tmpfs isn't the solution here. :)
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
concurrency and scalability...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
20 matches
Mail list logo
