3,固然作上部分工做前,分析了top -1 ,及看主进程中各线程中的运行状况;看了各核的使用状况;linux
1. Linux下,如何看每一个CPU的使用率:编程
#top -d 1缓存
(此时会显示以1s的频率刷新系统负载显示,能够看到总的CPU的负载状况,以及占CPU最高的进程id,进程名字等信息)服务器
(切换按下数字1,则能够在显示多个CPU和总CPU中切换)并发
以后按下数字1. 则显示多个CPU (top后按1也同样)负载均衡
Cpu0 : 1.0%us, 3.0%sy, 0.0%ni, 96.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stpost
这里对us,sy,ni,id,wa,hi,si,st进行分别说明:性能
us 列显示了用户模式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,可是若是长期大于50%,须要考虑优化用户的程序。大数据
sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,若是us+sy 大于 80%说明可能存在CPU不足。
ni 列显示了用户进程空间内改变过优先级的进程占用CPU百分比。优化
id 列显示了cpu处在空闲状态的时间百分比。
wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%,若是wa超过30%,说明IO等待严重,这多是磁盘大量随机访问形成的,也可能磁盘或者磁盘访问控制器的带宽瓶颈形成的(主要是块操做)。
hi
si
st
2. 在Linux下,如何确认是多核或多CPU:
#cat /proc/cpuinfo
若是有多个相似如下的项目,则为多核或多CPU:
processor : 0
......
processor : 1
3. 如何察看某个进程在哪一个CPU上运行:
#top -d 1
以后按下f.进入top Current Fields设置页面:
选中:j: P = Last used cpu (SMP)
则多了一项:P 显示此进程使用哪一个CPU。
Sam通过试验发现:同一个进程,在不一样时刻,会使用不一样CPU Core.这应该是Linux Kernel SMP处理的。
4. 配置Linux Kernel使之支持多Core:
内核配置期间必须启用 CONFIG_SMP 选项,以使内核感知 SMP。
Processor type and features ---> Symmetric multi-processing support
察看当前Linux Kernel是否支持(或者使用)SMP
#uname -a
5. Kernel 2.6的SMP负载平衡:
在 SMP 系统中建立任务时,这些任务都被放到一个给定的 CPU 运行队列中。一般来讲,咱们没法知道一个任务什么时候是短时间存在的,什么时候须要长期运行。所以,最初任务到 CPU 的分配可能并不理想。
为了在 CPU 之间维护任务负载的均衡,任务能够从新进行分发:将任务从负载重的 CPU 上移动到负载轻的 CPU 上。Linux 2.6 版本的调度器使用负载均衡(load balancing) 提供了这种功能。每隔 200ms,处理器都会检查 CPU 的负载是否不均衡;若是不均衡,处理器就会在 CPU 之间进行一次任务均衡操做。
这个过程的一点负面影响是新 CPU 的缓存对于迁移过来的任务来讲是冷的(须要将数据读入缓存中)。
记住 CPU 缓存是一个本地(片上)内存,提供了比系统内存更快的访问能力。若是一个任务是在某个 CPU 上执行的,与这个任务有关的数据都会被放到这个 CPU 的本地缓存中,这就称为热的。若是对于某个任务来讲,CPU 的本地缓存中没有任何数据,那么这个缓存就称为冷的。
不幸的是,保持 CPU 繁忙会出现 CPU 缓存对于迁移过来的任务为冷的状况。
6. 应用程序如何利用多Core :
开发人员可将可并行的代码写入线程,而这些线程会被SMP操做系统安排并发运行。
另外,Sam设想,对于必须顺序执行的代码。能够将其分为多个节点,每一个节点为一个thread.并在节点间放置channel.节点间形如流水线。这样也能够大大加强CPU利用率。
例如:
游戏能够分为3个节点。
1.接受外部信息,声称数据 (1ms)
2.利用数据,物理运算(3ms)
3.将物理运算的结果展现出来。(2ms)
若是线性编程,整个流程须要6ms.
但若是将每一个节点做为一个thread。但thread间又同步执行。则整个流程只须要3ms.
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/chenggong2dm/archive/2011/01/12/6131052.aspx