In this blog post, I’ll look at MySQL and Linux context switches and what is the normal number per second for a database environment. >>本博客，我们来谈谈，对于一个用来跑数据库的服务器，如何判断系统的 context switches值是否正常？
You might have heard many times about the importance of looking at the number of context switches to indicate if MySQL is suffering from the internal contention issues. I often get the question of what is a “normal” or “acceptable” number, and at what point should you worry about the number of context switches per second? >>我们通过观察系统的 context switches 值 来判断 MySQL数据库是否存在争用的问题。那么我们如何判断我们当前系统的 正常 context switches值的范围呢？
First, let’s talk about what context switches are in Linux. This StackOverflow Thread provides a good discussion, with a lot of details, but basically it works like this: >>首先我们来讨论一什么是context switches(linux 下)。This StackOverflow Thread 对context switches进行了详细的介绍(有需要可以参数)。这里我们只是大概的介绍一下 context switches
The process (or thread in MySQL’s case) is running its computations. Sooner or later, it has to do some blocking operation: disk IO, network IO, block waiting on a mutex or yield. The execution switches to the other process, and this is called voluntary context switch.On the other hand, the process/thread may need to be preempted by the scheduler because it used an allotted amount of CPU time (and now other tasks need to run) or because it is required to run high priority task. This is called involuntary context switches. When all the process in the system are added together and totaled, this is the system-wide number of context switches reported (using, for example, vmstat): >>
This is a global number. In many cases, however, it is better to look at it as context switches per CPU logical core. This is because cores execute tasks independently. As such, they have mostly independent causes for context switches. If you have a large number of cores, there can be quite a difference: >>上面通过vmstat 观察到的是系统上所有逻辑cpu context switches值的和，具体的观察每个逻辑cpu的 context switches值效果更好(因为每个逻辑cpu 独立的执行任务)。因为每个逻辑cpu 独立的处理任务，所以他们各自的 context switches 值差别可能很大。
The number of context switches per second on this system looks high (at more than 1,000,000). Considering it has 56 logical cores, however, it is only about 30,000 per second per logical core (which is not too bad). >>上面图中系统的 context switches 值比较高，超过1000000，但是系统有56个逻辑cpu，那么每个逻辑cpu上的 context switches值大概是30000(这并不是一个很高的值)。
So how do we judge if the number of context switches is too high in your system? One answer is that it is too high if you’re wasting too much CPU on context switches. This brings up the question: how many context switches can the system handle if it is only doing context switches? >>那么我们如何判断系统当前的 context switches 值是否过高？ 判断方法之一是，如果在 context switches 上花费了过多的cpu时间，那么我们就认为这时的 context switches 对当前系统来说是过高的。那么我们又如何去判断当前系统能够处理的最大 context switches(系统 只处理context switches的情况下)呢？
It is easy to find this out! >>这个很简单，我们可以通过sysbench 加 --threads 参数来测试出当前系统能够处理的最大 context switches值
Sysbench has a “threads” test designed specifically to measure this. For example:
Check the vmstat output or the Context Switches PMM graph:
We can see this system can handle up to 35 million context switches per second in total (or some 500K per logical CPU core on average). >>从上面的图中我们可以看出，测试的系统 每秒钟能够处理 35 million 次 context switches，平均每个cpu 每秒处理 500000次。
I don’t recommend using more than 10% of CPU resources on context switching, so I would try to keep the number of the context switches at no more than 50K per logical CPU core. >>在正常的系统上，建议context switches 值不超过 系统最大处理量的10%。所以上面的测试系统中，单个逻辑cpu 每秒钟处理的 context switches值 最好不要超过 50000。
Now let’s think about context switches from the other side: how many context switches do we expect to have at the very minimum for given load? Even if all the stars align and your query to MySQL doesn’t need any disk IO or context switches due to waiting for mutexes, you should expect at least two context switches: one to the client thread which processes the query and one for the query response sent to the client. >>现在我们从另一个角度来考虑 context switches：在给定的负载下，系统最小的 context switches 值是多少？在理论上一个query会产生两次 context switch，一次是处理客户端发送的 query，一次是给客户端发送查询的结构。
Using this logic, if we have 100,000 queries/sec we should expect 200,000 context switches at the very minimum. >>根据上面的逻辑来分析，如果我们数据库 qps为 100000，那么系统的最小的 context switches值是 200000.
In the real world, though, I would not worry about contention being a big issue if you have less than ten context switches per query. >>在真实环境中，如果系统的 context switches值 小于 数据库 qps的10倍，那么我们可以认为不存在 争用问题。
It is worth noting that in MySQL not every contention results in a context switch. InnoDB implements its own mutexes and RW-locks, which often try to “spin” to wait for a resource to become available. This wastes CPU time directly rather than doing a context switch. >>值得注意的是，对于mysql 来说，并不是所有的争用都会导致 context switch。innodb存储引擎有自己的 mutexes和 RW-locks 机制，当资源不可用时会进行自旋，等待资源。这时只是会消耗cpu时间，而不是产生 context switch。
Summary:
- Look at the number of context switches per logical core rather than the total for easier-to-compare numbers >>建议观察每个逻辑cpu的 context switches
- Find out how many context switches your system can handle per second, and don’t get too concerned if your context switches are no more than 10% of that number >>找到你的系统能够处理的最大 context switches值(使用 sysbench测试)
- Think about the number of context switches per query: the minimum possible is two, and values less than 10 make contention an unlikely issue >>对于每个查询，最少会产生两个 context switches，如果系统的 context switches 值小于 数据库qps的10倍，基本不用担心占用的问题
- Not every MySQL contention results in a high number of context switches >>并不是所有的Mysql 数据库争用都会导致很高的 context switches值
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
