it-swarm.cn

“正常”有多少个上下文切换(取决于CPU内核(或其他))?

嗨,Linux/UNIX霸主,

关于Linux服务器上Normal多少个上下文切换(每个处理器内核),您是否有一个经验法则?

我的大学在这里提出来,他正在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 vs IOwait(x10000比例)

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

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

  • 服务器工作的存储空间为0.5TB SAN通过FC
  • 有8GB的RAM,主要是缓存-无需交换。
37
Xerxes

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

系统调用

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

当我们查看来自Linux的write(2)syscall的定义时,这变得非常清楚:

 NAME 
写入-写入文件描述符
 
简介
 #include 
 
 ssize_t write(int fd,const void * buf,size_t count); 
 
 DESCRIPTION 
 write()写入从指向buf的缓冲区到指向文件
的字节数通过文件描述符fd。 [..] 
 
返回值
成功后,将返回写入的字节数(零表示
未写入任何内容)。如果出错,则返回-1,并正确设置errno 
。
 [..] 

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

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

多任务

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

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

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

进一步阅读

linfo.org对 上下文切换系统调用 的内容进行了很好的撰写。 Wikipedia 具有一般信息,并且在系统调用中包含一个Nice链接集合。

26
Michael Renner

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

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

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

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

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

再次编辑后图:当然看起来IO界。当上下文切换很高时,系统是否将大部分时间都花在SYS中?

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

编辑:嗯。是否有任何机会在您的SAN)在死时间期间使用bonnie ++或dbench访问某些基准测试?.

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

7
jay_dubya

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

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

您可以返回多远的数据?

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

1
wzzrd

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

1
hashei

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

0
Alex J