Subject: Re: [boost] ACID transactions/flushing/MySQL InnoDB
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-12-10 18:02:03
Am Thursday 10 December 2009 21:47:53 schrieb Dean Michael Berris:
> On Fri, Dec 11, 2009 at 6:02 AM, Stefan Strasser <strasser_at_[hidden]>
> > thank you very much for both your answers.
> > but they don't solve the mystery, please see below.
> Let me try one more time. ;)
I was about to write you've got to try one more time, but...see below.
> When you say logged on commit, are you writing to a file that's
> already created with enough space, or are you writing to a file which
> is "grown" every time you add data to it?
I had tried that. and I've tried writing a sector instead of 1 byte. and I've
tried removing O_CREAT.
but you have to actually do ALL THREE, and one more: the sector writes need to
so, writing 512 bytes, aligned to 512 bytes, without O_CREAT, when the file
already exists, brings the desired results
2 seconds with much less disk usage.
that's some set of conditions.
thanks for helping with this.
> What InnoDB does is puts everything that fits in memory up there, and
> keeps it there. Small transactions will write to the log file, but not
> write all the data directly to disk right away.
that's almost equal to my approach. I do write to the data files, but only
sync them when a large transaction is committed or the log is rolled to a new
I should probably think about sector-aligning those data writes, too, given
the new insights.
> Because you're using fsync, you're asking the kernel to do it for you
> -- and if your file is already in the vfs cache, the chances of fsync
> returning quicker is higher due to write caching at the OS level.
I don't think the OS uses write caching in the case of fsync. it isn't
supposed to, is it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk