[Mulgara-dev] Transaction commit performance

Life is hard, and then you die ronald at innovation.ch
Fri Jun 13 19:06:28 UTC 2008


On Fri, Jun 13, 2008 at 09:53:57AM -0400, Alex Hall wrote:
> Paul Gearon wrote:
> > I already mentioned this to Alex, but it should be published to the  
> > group as well...
> > On Jun 11, 2008, at 11:25 AM, Alex Hall wrote:
> > 
> >> I'm having performance issues with Mulgara on my Windows laptop.
> >> Specifically, the transaction commit time seems to be slow.  I turn  
> >> off
> >> autocommit on a connection, make a series of modifications, and then
> >> turn autocommit back on.  Committing the transaction takes, on  
> >> average,
> >> a little more than 2 seconds.  Given that the commit operation is just
> >> pointing the current phase to the new tree root for each index (plus  
> >> the
> >> stringpool), this seems a bit excessive.  Even accounting for the time
> >> it takes to flush the files, it doesn't seem like it should take that
> >> long.  Does that sound right?  I'm hoping that maybe this is a Windows
> >> issue, and that once we start running our production server on Linux
> >> with better hardware the commit times will speed up.  Any thoughts?
> > 
> > Yes. A commit operation guarantees that everything on disk is complete  
> > and consistent. That means that everything that you wrote (and will be  
> > sitting in the write-back buffer cache) needs to be flushed.  
> > Unfortunately, that includes data in a lot of files, sometimes  
> > scattered around those files.
> 
> One thing that occurred to me is that it might benefit us to keep track 
> of which byte buffers have been modified in the current transaction, and 
> only force those to disk (the current approach is to force ALL mapped 
> byte buffers).  On further thought, though, forcing a non-modified 
> mapped byte buffer should be a no-op (assuming that the OS is smart 
> about managing its cache).  Do you agree?

I had a discussion with Paul about this a while back because I was
thinking the same thing, and he rightly pointed out that it's a no-op
(I even briefly played with some mods to track and flush only dirty
buffers, and it didn't help, at least on Linux).


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list