… first I’d like to note that this experiment isn’t really running the iiBench problem. The point of iiBench problem… to measure the cost of index maintenance. This experiment isn’t measuring the cost of index maintenance. Transaction-id is auto… iibench is slightly incorrect. The correct URL for version you used is http://tokutek.com/downloads/iiBench-1.0.3.1…

Aaron, No particular reasons, it doesn’t matter if you have 4 1G or 2 2GB log files, as they are all concatenated together by InnoDB and written to in a circular fashion.

Justin, I would be doing another benchmark and use ‘innodb_ibuf_accel_rate’ together with tuning other IO related parameters that I can tune to good affect, and I will post my results.

@Time Callaghan, I did not test with innodb_flush_log_at_trx_commit=1 because the durability requirements are not that stringent. And following is how I invoked iiBench: iibench -T $tbl_name -D iiBench -r 200000000 -M 1 -s 1000000 -t 100000 -I 1 -a -S

Interesting results, and well presented. Would you mind sharing the command line you used for your iiBench clients? Also, did you run a test with innodb_flush_log_at_trx_commit = 1?

Partitioning probably reduces the stress on the insert buffer. Does XtraDB/Percona Server have an option to use more IO for insert buffer merges when the ibuf gets too big?