有多少上下文切换是“正常的”（作为 CPU 内核（或其他）的函数）？

姓名
       write - 写入文件描述符

概要
       ＃包括 

       ssize_t write(int fd, const void *buf, size_t count);

描述
       write() 从指向 buf 的缓冲区向文件写入 count 个字节
       由文件描述符 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 有一篇关于什么是上下文切换和系统调用的好文章。维基百科有通用信息和一个很好的系统调用链接集合。

Answer 2

jay*_*bya 7

我的中等负载的网络服务器在大多数时间里每秒大约有 100-150 个交换机，峰值达到数千个。

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

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

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

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

再次编辑张贴图：当然看起来受 IO 限制。当上下文切换很高时，系统是否将大部分时间花在 SYS 中？

再次编辑：最后一张图中的高 iowait 和系统 - 完全覆盖了用户空间。你有IO问题。
你用的是什么FC卡？

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

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

Answer 3

Ale*_*x J -1

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

实际上上下文切换的成本是**昂贵的**。这在虚拟机上更糟糕 - 几个月前我们做了一些测试，结果表明虚拟机性能的最大原因之一是上下文切换。 (6认同)

归档时间：	16 年，5 月前
查看次数：	90010 次
最近记录：	16 年，5 月前