[ZODB-Dev] Re: ZODB Benchmarks

[Dieter Maurer]

Benji York wrote at 2008-3-25 09:40 -0400:
>Christian Theune wrote:
>> I talked to Brian Aker (MySQL guy) two weeks ago and he proposed that we
>> should look into a technique called `group commit` to get rid of the "commit
>> contention".
> ...
>Summary: fsync is slow (and the cornerstone of most commit steps), so 
>try to gather up a small batch of commits to do all at once (with only 
>one call to fsync).

Our commit contention definitely is not caused by "fsync".
Our "fsync" is quite fast. If only "fsync" would need to be considered,
we could easily process at least 1.000 transactions per second -- but
actually with 10 transactions per second we get contentions a few times
per week.



We do not yet precisely the cause of our commit contentions.
Almost surely there are several causes that all can lead to contention.

We already found:

  *  client side causes (while the client helds to commit lock)
  
    - garbage collections (which can block a client in the order of
      10 to 20 s)

    - NFS operations (which can take up to 27 s in our setup -- for
      still unknown reasons)

    - invalidation processing, espicially ZEO ClientCache processing

  *  server side causes

    - commit lock hold during copy phase of pack

    - IO trashing during the reachability analysis in pack

    - non deterministic server side IO anomalities
      (IO suddently takes several times longer than usual -- for still
      unknown reasons)
> Somewhat like Nagle's algorithm, but for fsync.
>
>The kicker is that OSs and hardware often lie about fsync (and it's 
>therefore fast) and good hardware (disk arrays with battery backed write 
>cache) already make fsync pretty fast.
>
>Not to suggest that group commit wouldn't speed things up, but it would 
>seem that the technique will make the largest improvement for people 
>that are using a non-lying fsync on inappropriate hardware.
>-- 
>Benji York
>Senior Software Engineer
>Zope Corporation

-- 
Dieter