MySQL Performance: Some results comparing InnoDB log size impact @dbSTRESS benchmark

MySQL Performance: innodb log size 影响比较的一些结果

原文： http://dimitrik.free.fr/blog/archives/06-01-2009_06-30-2009.html#55

Following my previous post (where I've also told about a significant performance gain by using a bigger InnoDB log size ), I'd like to present you some results obtained on the Read+Write workload and log size equal to 1024MB. I've labeled it on graphs as "FF" (Fast & Furious :-)) as within a such configuration MySQL server may go very fast until it'll meet a "furious flushing" to free some space within a log file... :-)

延续之前我的那篇文章(我谈了关于 使用大的innodb log size 可以获得客观的性能提升), 我想给你看下在logsize为1024M时，一些读/写压力测试结果. 我已经在图上使用'FF'(又快又猛)标出来了, MySQL server使用了这样的配置的话可能跑的很快，除非，他需要 疯狂的flushing以在log file中释放更多空间。

However, the speed-up is quite important, so if you don't worry too much if time to time your production activity may have a short drop on performance - you have to consider this option as one of the first to test to improve your throughput! :-)

这个速度的提升是很重要的, 因此如果你不太担心你的生产环境或许有时会有少量的性能下滑，你应该首先考虑测试这个选项以提升你的系统的吞吐量。

As you may see from the following graphs, most of engines performing with 1024M redo log even better than previously tested MySQL 5.4 with 128M log. But with a bigger redo log MySQL 5.4 is also going more far. And perf version build5 performs even better.

从下面的图中可以看到，大部分的使用了1024Mredo log的引擎的性能要不之前的测试的使用了128Mlog的MySQL5.4的要好。但是使用了更大的redo log的MySQL5.4性能也更好. perf  version build5 尤其表现的好。

On the same time the test is not long enough to present a real avg TPS when each engine is running on its full power (all results should be better). But you still may recognize the moment when each engine met its "furious flushing" - throughput is shortly dropped on one moment or another...

As usually, X-axis represents the number of concurrent clients (sessions), and Y-axis the obtained TPS level.

X轴表示当前clients的数目， Y轴表示获得TPS.

Read+Write @8cores

Read+Write @16cores: