向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除|赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.

背景：Zabbix的图形里有一项CPU jumps，里面有两条曲线， Context switches per second Interrupts per second。
前言：
这种单文件行可能是相当inefficent并且有的时候你想有一个计算机在一次处理很多不同的东西，而不是在一个时间一两件事。例如，大多数计算机依靠的外设输入，但这些外设通常比处理器本身慢得多。例如，当一个程序需要一些数据，它可能必须先读取硬盘数据。这可能只需要几毫秒的时间，但在这段时间内CPU将空闲-非常低效的。为了提高效率，计算机使用多任务处理。一个CPU仍只能运行一个进程的时间，但多任务得到周围，通过调度哪些任务将在任何特定时间运行。从一个任务切换到另一个的行为称为上下文切换。具有讽刺意味的是，上下文切换的行为给计算过程增加了相当多的开销。为确保原始运行程序不会失去所有进程，计算机必须先将CPU的当前状态保存在内存中，然后再切换到新程序。之后，当切换回原来的时候，计算机必须从内存中加载CPU的状态。幸运的是，这种开销常常被频繁的上下文切换所带来的效率所抵消。


Context Switches 上下文切换，有时也被称为进程切换(process switch)或任务切换。是一个重要的性能指标。

CPU从一个线程切换到另外一个线程，需要保存当前任务的运行环境，恢复将要运行任务的运行环境，必然带来性能消耗。

Context Switches 上下文切换简介

操作系统可以同时运行多个进程， 然而一颗CPU同时只能执行一项任务，操作系统利用时间片轮转的方式，让用户感觉这些任务正在同时进行。 CPU给每个任务都服务一定的时间, 然后把当前任务的状态保存下来, 在加载下一任务的状态后, 继续服务下一任务。任务的状态保存及再加载, 这段过程就叫做上下文切换。

时间片轮转的方式使多个任务在同一颗CPU上执行变成了可能, 但同时也带来了保存现场和加载现场的直接消耗。

上下文切换的性能消耗

Context Switchs过高，导致CPU就像个搬运工一样，频繁在寄存器(CPU Register)和运行队列(run queue)之间奔波，系统更多的时间都花费在线程切换上，而不是花在真正做有用工作的线程上。

直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉。

间接消耗：多核的cache之间得共享数据。间接消耗对于程序的影响要看线程工作区操作数据的大小。

性能分析查看Context Switches的方法

linux中可以通过工具vmstat, dstat, pidstat来观察CS的切换情况。vmstat, dstat只能观察整个系统的切换情况，而pidstat可以更精确地观察某个进程的上下文切换情况。

windows中可以使用查看进程的神器processxp，进程列表中可以添加Context Switchs和Context Switchs Delta列，另外进程属性Threads标签页可查看线程对应的Context Switchs。

另windows中还可以使用“性能计数器”监控Context Switchs的变化趋势，方便性能分析。添加System\Context Switches/sec或Thread(_Total)\Context Switches/sec计数器即可。

引起上下文切换的原因

对于我们经常使用的抢占式操作系统来说, 引起上下文切换的原因大概有以下几种:

1. 当前执行任务的时间片用完之后, 系统CPU正常调度下一个任务

2. 当前执行任务碰到IO阻塞, 调度器将挂起此任务, 继续下一任务

3. 多个任务抢占锁资源, 当前任务没有抢到,被调度器挂起, 继续下一任务

4. 用户代码挂起当前任务, 让出CPU时间

5. 硬件中断


来自：http://www.6san.com/469/

作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/9637/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！