☰

多少次上下文切换是“正常的”（作为 CPU 核心（或其他）的功能）？

tag-icon • tag-icon linux performance context-switch
多少次上下文切换是“正常的”（作为 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，大部分是缓存 - 没有交换。

答案1

这在很大程度上取决于您运行的应用程序类型。如果您的应用程序非常频繁地触发 WRT 系统调用，您可以预期会看到大量的上下文切换。如果您的大多数应用程序处于空闲状态并且只在套接字上发生事情时才唤醒，您可以预期会看到较低的上下文切换率。

系统调用

系统调用本身就会导致上下文切换。当进程执行系统调用时，它基本上会告诉内核从当前时间点接管并占用内存来执行进程无权执行的任务，并在完成后返回到同一位置。

当我们查看 Linux 的 write(2) 系统调用的定义时，这一点变得非常清楚：

姓名
       写入——写入文件描述符

概要
       ＃包括

       ssize_t 写入（int fd， const void *buf， size_t count）；

描述
       write() 将指向缓冲区 buf 的 count 个字节写入文件
       由文件描述符 fd 引用。[..]

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

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

一个很好的例子就是 Valve Source 游戏的专用游戏服务器，持有量。http://nopaste.narf.at/f1b22dbc9显示了游戏服务器单个实例在没有玩家的情况下一秒钟执行的系统调用。此过程在 Xeon X3220 (2.4Ghz) 上占用大约 3% 的 CPU 时间，只是为了让您了解这是多么昂贵。

多任务处理

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

一个很好的可视化方法是中央处理器. cpuburn 本身不执行任何系统调用，它只是在其自己的内存中进行迭代，因此它不会引起任何上下文切换。

拿一台闲置的机器，启动 vmstat，然后对系统的每个 CPU 核心运行 burnMMX（或来自 cpuburn 包的任何不同测试）。到那时，您的系统应该已经完全利用，但几乎没有增加上下文切换。然后尝试启动更多进程。您将看到，随着进程开始争夺 CPU 核心，上下文切换率会增加。切换量取决于进程/核心比率和内核的多任务分辨率。

进一步阅读

linfo.org 对此进行了很好的描述上下文切换和系统调用是。维基百科包含有关系统调用的一般信息和良好的链接集合。

答案2

我的中等负载的网络服务器大部分时间每秒进行大约 100-150 次切换，峰值可达数千次。

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

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

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

再次编辑：在每秒 16k cs 的情况下，每个 CPU 平均每毫秒切换两次 - 即正常时间片的一半到六分之一。他可能正在运行大量 IO 绑定线程吗？

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

再次编辑：最后一张图中的 iowait 和系统很高 - 完全遮蔽了用户空间。您有 IO 问题。
您使用的是哪种 FC 卡？

编辑：嗯。在死区时间内，是否有机会使用 bonnie++ 或 dbench 对 SAN 访问进行一些基准测试？我很想知道它们是否有类似的结果。

编辑：周末我一直在思考这个问题，当 bonnie 执行“一次写入一个字节”操作时，我看到了类似的使用模式。这也许可以解释大量切换的原因，因为每次写入都需要单独的系统调用。

答案3

我更倾向于关注系统状态的 CPU 占用率。如果它接近 10% 或更高，则意味着您的操作系统花费了太多时间进行上下文切换。虽然将一些进程移到另一台机器是很多慢一点，这是值得的。

答案4

没有经验法则。上下文切换只是 CPU 从处理一个线程转移到另一个线程。如果您运行大量进程（或几个高度线程化的进程），您会看到更多切换。幸运的是，您不必担心有多少上下文切换——成本很小，而且或多或少是不可避免的。

相关内容