内容简介：Usually, this approach gives rather stable results; for example, benchmarking MySQL with Sysbench OLTP Read-Only workload I get a variance of less than one percent between 1-minute runs.In this case, though, I was seeing some
When I run a benchmark and want to measure the CPU efficiency of something, I find it’s often a good choice to run a benchmark program, as well as the database, on the same server. This is in order to eliminate network impact and to look at single-thread performance, to eliminate contention.
Usually, this approach gives rather stable results; for example, benchmarking MySQL with Sysbench OLTP Read-Only workload I get a variance of less than one percent between 1-minute runs.
In this case, though, I was seeing some 20 percent difference between the runs, which looked pretty random and would not go away even with longer 10-minute runs.
The benchmark I did was benchmarking MySQL through ProxySQL (all running on the same machine):
Sysbench -> ProxySQL -> MySQL
As I thought more about possible reasons, I thought CPU scheduling might be a problem. As requests pass from one process to another, does Linux Kernel schedule requests at the same CPU core or a different one? Even though only one process can really be busy processing a request at the same time in this setup, there is the question of CPU cache usage, as well as other implications of scheduling work on the single CPU core or a different one.
To validate my assumptions, I used taskset , a little utility available in modern Linux distributions, which allows the mapping of a set process CPU affinity, essentially mapping it to some of the CPU cores.
I set MySQL and ProxySQL to be limited to different CPU cores:
taskset -pc 0 `pidof mysqld` taskset -pc 1 8601 #pid of ProxySQL main process
And run sysbench bound to the given CPU core too:
taskset -c 2 sysbench --rand-type=uniform --db-driver=mysql --db-ps-mode=auto --mysql-socket="/tmp/proxysql.sock" --mysql-user=sbtest --mysql-password=sbtest --mysql-db=sbtest /usr/share/sysbench/oltp_point_select.lua --table-size=10000000 --threads=1 --time=60 --rate=0 --percentile=99 run
With this change, I’m back to having very stable benchmark results. So if you ever run to a similar problem, see if setting process affinity with taskset helps!
以上所述就是小编给大家介绍的《Benchmarking: More Stable Results with CPU Affinity Setting》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
测试驱动开发的艺术
Lasse Koskela / 李贝 / 人民邮电出版社 / 20101023 / 59.00元
在传统的软件开发中，开发人员对于代码是否正确心中无底，一切依赖于后期的测试环节。极限编程反其道而行之，主张采用测试驱动开发（TDD）的方法，即通过测试定义所要开发的功能的接口，然后实现功能的开发过程。TDD通过不断地测试推动代码的开发，既简化了代码，又保证了软件质量。 本书采用“手把手”的教学方式，通过大量实例来解释TDD，还专门用几章的篇幅来讲解如何为难于测试的技术编写单元测试。全书内容循......一起来看看 《测试驱动开发的艺术》 这本书的介绍吧!
