Please keep in mind what MySQL Documentation says on sync_binlog:
If the value of this variable is greater than 0, the MySQL server synchronizes its binary log to disk (using fdatasync()) after sync_binlog commit groups are written to the binary log. The default value of sync_binlog is 0, which does no synchronizing to disk—in this case, the server relies on the operating system to flush the binary log's contents from time to time as for any other file. A value of 1 is the safest choice because in the event of a crash you lose at most one commit group from the binary log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).
Apparently, you are writing lots of commit groups in one write operation to the binary log.
- Setting sync_binlog to 0 lets the OS flush commit groups to disk (on its own time)
- Setting sync_binlog to 1 lets mysqld flush commit groups to disk on each write
You could set sync_binlog > 1 to throttle mysqld's flush of the binlog.
You should expect setting sync_binlog to create more disk I/O, not less.
If your DB Server is a bare-metal server, you may need to check your disk controller and either change the batteries or get a better disk controller.
UPDATE 2015-04-02 10:57 EST
You just mentioned in your comment that you are using SSDs. I wrote a post over a year ago (MySQL on SSD - what are the disadvantages?) stating that SSDs are not all that good for sequential writes. In your case, the sequential writes are happening on the binlogs. SSD write performance is the same regardless of sequential writes and random writes. I would consider moving your binary logs to HDD rather than on SSD.
