2011-09-05 13:29:10.806234+00:00 https://api.launchpad.net/1.0/bugs/470590 https://api.launchpad.net/1.0/~arjen-lentz https://api.launchpad.net/1.0/bugs/470590/linked_branches https://api.launchpad.net/1.0/bugs/470590/activity https://bugs.launchpad.net/bugs/470590 Arjen Lentz Kristian Nielsen Invalid Wishlist 2009-11-02 11:53:36.354987+00:00 bug Arjen Lentz added bug maria: importance Arjen Lentz tags Hakan Küçükyılmaz maria: assignee Hakan Küçükyılmaz maria: status Hakan Küçükyılmaz maria: assignee Arjen Lentz maria: importance Hakan Küçükyılmaz maria: importance Sergei maria: status Sergei maria: assignee Philip Stoev maria: status Kristian Nielsen Sergey Petrunia 0)]]> Arjen Lentz 0)]]> Could you please point at the offending fsync() calls or provide some > evidence that there are multiple syncs being done for one transaction? > (i.e. what has led you to suspect that there are more fsync calls done > when necessary?) Hearsay from people with a clue. Hadn't browsed the code for this myself. However, just doing a quick grep/less finds them within a few seconds. There's mysys/my_sync.c that contains my_sync() my_sync() gets called from sql/log.cc in several places, inside functions that do something... for instance when binlog is written, if sync_binlog is 1 or reaches its configured number, it's fsynced. This, by definition, implies that it's a separate sync from an InnoDB transaction or MariaDB action. That's two syncs already, that should in fact be one. And the binlog index should really also be part of that, to be resilient to crashes. It would also be less overhead than it is now, provided fsync/my_sync is only called once for a commit. Similarly, the relay log and relay index should be synced at the same time, and possibly master.info with it. I hope this provides you with sufficient detail to address the problem. Thanks Cheers, Arjen. ]]> Hakan Küçükyılmaz 0)]]> Kristian Nielsen 0)]]>