“正常”有多少个上下文切换（取决于CPU内核（或其他））？

嗨，Linux / UNIX霸主，

关于Linux服务器上“ 正常 ”多少个上下文切换（每个处理器内核），您是否有经验法则？

我的大学在这里提出来，他正在8核x86_64计算机上看到16K 。

这是最近几天sarface的一些统计信息...

替代文字http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

要查看流程创建统计信息，这是同一张图的对数视图...

替代文字http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

而且这8个核心无聊到死...

替代文字http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS与IOwait（x10000比例）

替代文字http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

万一有人问，更多无用的信息。

• 服务器使用的存储是通过FC的0.5TB SAN
• 有8GB的RAM，主要是缓存-无需交换。

这在很大程度上取决于您运行的应用程序的类型。如果您的应用程序非常适合WRT系统调用，那么您会期望看到大量的上下文切换。如果大多数应用程序闲置并且仅在套接字上发生事情时才唤醒，则可以预期上下文切换率会降低。

系统调用

系统调用根据其自身的性质导致上下文切换。当一个进程进行系统调用时，它基本上告诉内核从当前时间点和内存中接管该进程无权执行的事情，并在完成后返回同一位置。

当我们查看来自Linux的write（2）syscall的定义时，这变得非常清楚：

名称
       写-写入文件描述符

概要
       ＃包括 

       ssize_t write（int fd，const void * buf，size_t count）;

描述
       write（）写入以计数从指向buf的缓冲区到文件的字节数
       由文件描述符fd引用。[..]

返回值
       成功后，将返回写入的字节数（零表示
       什么都没写）。错误时，返回-1，并设置errno
       适当地。
       [..]

这基本上告诉内核从进程接管操作count，从指向的内存地址*buf到fd当前进程的文件描述符开始，移至字节，然后返回到该进程并告诉他进程如何。

一个很好的例子说明了这是基于Valve Source游戏的专用游戏服务器hlds。http://nopaste.narf.at/f1b22dbc9显示了由一个没有服务器的游戏服务器的单个实例完成的一秒钟的系统调用。在Xeon X3220（2.4Ghz）上，此过程大约需要3％的CPU时间，只是让您感觉到它的昂贵程度。

多任务

上下文切换的另一个来源可能是不执行系统调用的进程，但是需要移出给定的CPU才能为其他进程腾出空间。

可视化的一种好方法是cpuburn。cpuburn本身不会进行任何系统调用，它只会在自己的内存上进行迭代，因此它不应引起任何上下文切换。

以一台闲置的计算机为例，启动vmstat，然后为系统具有的每个CPU核心运行burnMMX（或cpuburn软件包中的任何其他测试）。届时您应该具有完整的系统利用率，但是几乎没有增加任何上下文切换。然后尝试开始其他一些过程。您会看到，随着进程开始争夺CPU内核的竞争，上下文切换速率会提高。切换的数量取决于进程/核心比率和内核的多任务分辨率。

进一步阅读

linfo.org很好地描述了上下文切换和系统调用。Wikipedia具有一般信息和有关系统调用的不错的链接集合。

我中等负载的Web服务器在大多数时间中处于每秒100-150交换机的位置，峰值达到数千。

高上下文切换率本身并不是问题，但它们可能会指出更严重的问题。

编辑：上下文切换是一种症状，而不是原因。您想在服务器上运行什么？如果您有一台多处理器计算机，则可能要尝试为主服务器进程设置cpu亲和力。

或者，如果您正在运行X，请尝试下拉至控制台模式。

再次编辑：以每秒16k cs的速度，每个cpu平均每毫秒两次切换-这是正常时间片的一半到六分之一。他可以运行许多IO绑定线程吗？

再次编辑帖子图：当然看起来与IO绑定。上下文切换较高时，系统是否将大部分时间都花在SYS中？

再次编辑：最后一张图中的高iowait和系统-完全使用户空间黯然失色。您有IO问题。
您正在使用哪种FC卡？

编辑：嗯。是否有机会在闲置时间使用bonnie ++或dbench对SAN访问进行一些基准测试？我想看看他们是否有相似的结果。

编辑：在周末考虑这个问题时，当bonnie执行“一次写入一个字节”传递时，我已经看到了类似的用法模式。这可能可以解释进行大量切换的原因，因为每次写入都需要单独的syscall。

我更倾向于关注系统状态的CPU占用率。如果它接近10％或更高，则意味着您的OS花费了太多时间进行上下文切换。尽管将某些进程移到另一台计算机上的速度要慢得多，但值得这样做。

这样的事情就是为什么您应该尝试保持服务器性能基准的原因。这样，您可以将突然注意到的事物与过去记录的事物进行比较。

就是说，我有正在运行的服务器（主要不是很繁忙的Oracle服务器），它们稳定在2k左右，峰值约4k。对于我的服务器，这是正常的，对于其他人的服务器而言，这可能太低或太高。

您可以返回多远的数据？

您可以给我们什么样的CPU信息？

没有经验法则。上下文切换只是CPU从处理一个线程转移到另一个线程。如果您运行许多进程（或一些高度线程化的进程），则会看到更多的开关。幸运的是，您不必担心有多少上下文切换-代价很小，或多或少是不可避免的。