衡量Linux CPU使用的指标
需要关注以下地方：
第一段需要关注的值：
·使用率
·在用户空间所消耗的时间百分比
·在系统空间锁消耗的时间百分比
·消耗在IO等待上的时间
如果一个主机上有大量的cpu消耗在IO等待上，那么说明IO活动非常频繁，而IO子系统性能非常差。
因此我们看到wite的时间居高不下时，说明IO活动非常频繁的，IO子系统非常差
但如果wite的时间不是特别离谱，一般而言问题都不大
第二段需要关注的值：
·空闲时间
·平均负载，CPU等待运行活动队列中等待运行的进程的个数
·可运行的进程数，处于等待状态的进程数，这个数值一般不能超出所有cpu物理核心的10倍，如果超出则意味着CPU性能差
·阻塞进程，一般引起阻塞是由IO调用引起的，IO调用长时间不能得到满足则会引起阻塞，而处于非可中断的状态
·上下文切换的个数
·中断的个数，一旦有IO发生，这个对应的设备则会发起中断请求，中断了CPU正在进行的进程而转而中断处理程序
在任何CPU上如果中断量很大的话也意味着cpu被打断的次数频繁，所以衡量一个cpu是否被频繁打断的话，不仅要衡量context switch还要衡量interrupts
绑定CPU
如果我们期望某一颗cpu上只运行某一进程
以nginx为例：
我们有2个4核的cpu，8个核心，我们可以实现2个核心运行内核线程以及nginx的master进程，而其他6个核心运行worker线程
实现绑定：
在启动系统时向内核传递参数，手动隔离专用的物理核心，在隔离完成之后手动启动起来了，并且手动去分配这被隔离的6个核心
隔离物理核心并不意味着没有切换，因为有些不是切换而是中断处理，隔离了其他进程但不能隔离这个CPU中断的能力
因为我们有8颗物理核心，当任何一个进程的中断，有可能会被8颗中的某1颗所处理，所以可能包括当前已经隔离出的CPU，也就是说只是隔离的进程而没有隔离中断，而我们为了做到绝不处理任何额外的程序，还需要隔离中断
可以明确定义某个中断号的中断只关联到某特定的CPU上，而不中断到已经被隔离出的CPU
总结如下：
在启动系统时向内核传递参数，手动隔离专用的物理核心，在隔离完成之后手动启动起来了，并且手动去分配这被隔离的6个核心
还要将隔离出的CPU从中断处理中隔离出来，绑定进程到CPU上
如何实现在启动系统时隔离CPU并且在启动之后使用taskset绑定其他进程
在/etc/grub.conf 向内核中传递参数：
isolcpus=cpu number,..cpu number
将隔离出的CPU，后面跟上隔离出来的号码比如8颗CPU，将0和1正常使用，将2到7都隔离出来，于是
isolcpus=2,3,4,..cpu number
这样以来 这些CPU将不再处理了
启动完成后手动将几个worker进程绑定在taskset上，明确说明启动几个线程，完后将从隔离的cpu上脱离出来即可
脱离中断处理程序
明确定义每个中断，只能够运行在哪个CPU上，用来实现将一个irq（中断请求处理），只关联到负责运行在其他cpu上的应用程序，我们被称为cpumask
[root@mysql_node1 ~]#ls /proc/irq/0 10 12 14 2 25 4 6 8 default_smp_affinity1 11 13 15 24 3 5 7 9
查看默认是实现的关联性
[root@mysql_node1 ~]#cat /proc/irq/default_smp_affinity3
查看第1号中断下所关联的cpu
[root@mysql_node1 ~]# cat /proc/irq/1/smp_affinity3
这是在第3课cpu上运行的，我们继续看
[root@mysql_node1 ~]# cat /proc/irq/10/smp_affinity3[root@mysql_node1 ~]# cat /proc/irq/11/smp_affinity1
默认情况下可能都会关联到同一CPU上去，而默认我们给的是mask
而这些mask完全可以使用cpu的号码或响应mask值响应定义的，而我们记得这些中断的处理我们必须手动指定专门隔离出来之外的cpu上
而我们指定的话直接使用echo就可以了（比如我们指定0号和1号cpu）
[root@mysql_node1 ~]# echo cpu_mask /proc/irq/ irq_num /smp_affinity
这些操作必须手动进行
实现调度器的定义
对于一个系统而言最核心的资源是CPU和内存，因此我们完全可以将一个主机上的所有可能cpu并将其归类到根上，而后将其分资源组，可能每个组里分配不均，资源组织有CPU是不能运行进程的，所以我们还要对其划分内存资源
但是注意的是内存是无法分段的，因为内存只有一段
如果真的要跨段访问的话，首先要通知给自己的内存控制器，自己的内存控制器发现不是自己本段内存的，于是向对方内存控制器发送请求，所以我们的周期需要在6次之内才能完成，于是跨段内存访问在numa架构上性能比较差的，所以在很多时候，内核默认策略是每隔1秒钟的时候就重新均衡一次，也就是说在numa结构上一个进程有可能随时被调度到其他CPU上去，那也就意味着跨段内存访问也很常见，为了提高numa架构的性能，应该启用cpu清元性，尽可能不做均衡，除非在不均衡情况非常糟糕的情况下
如果资源组有numa这种机制的话，说明每个物理cpu本地都对应都一段物理内存，一般比较常见的是有两个cpu，每个CPU有N个核心的这种方式
linux如果使用资源组的机制，那么我们需要使用cpusets这种虚拟文件系统来完成了
简单来讲，我们需要分为2个步骤：
1、划分资源组，并且将资源组内哪些资源划分进来
2、将某个进程绑定到组内，就能实现将实现只能在这个资源组内，尽可能实现本地资源的本地性
RHEL6 自带就有其机制，可以自动完成资源组的划分和归派
手动划分资源组：
[root@node3 ~]# mkdir /cgroup
编辑fstab，加入以下参数
cpuset /cgroup cpuset defaults 0 0
挂载虚拟文件系统
[root@node3 ~]# mount -a
进入cgroup
[root@node3 ~]# cd /cgroup/[root@node3 cgroup]# lscgroup.event_control memory_spread_pagecgroup.procs memory_spread_slabcpu_exclusive memscpus notify_on_releasemem_exclusive release_agentmem_hardwall sched_load_balancememory_migrate sched_relax_domain_levelmemory_pressure tasksmemory_pressure_enabled
里面会自动生成很多文件，其中有一个为cpus，为归类到根组中的cpu有哪些
[root@node3 cgroup]# cat cpus0-3
很显然的看到，我们的所有cpu都归类到根组中
查看自动归类到根组中的内存资源有哪些
[root@node3 cgroup]# cat mems0
很显然，我们不是非一致内存访问结构，所有只有第0段
查看关联到此组的所有进程PID
[root@node3 cgroup]# cat tasks123
###略###
我们在这个根组下创建的任何子目录都是一级组，我们来测试一下：
[root@node3 cgroup]# mkdir group{1,2}[root@node3 cgroup]# lscgroup.event_control memory_pressure_enabledcgroup.procs memory_spread_pagecpu_exclusive memory_spread_slabcpus memsgroup1 notify_on_releasegroup2 release_agentmem_exclusive sched_load_balancemem_hardwall sched_relax_domain_levelmemory_migrate tasksmemory_pressure
[root@node3 cgroup]# ls group1/cgroup.event_control memory_spread_pagecgroup.procs memory_spread_slabcpu_exclusive memscpus notify_on_releasemem_exclusive sched_load_balancemem_hardwall sched_relax_domain_levelmemory_migrate tasksmemory_pressure
查看cpus，发现是空的
[root@node3 cgroup]# cat group1/cpus[root@node3 cgroup]#
将其归类
将某个group归类到某个cpu中
[root@node3 cgroup]# cd group1/[root@node3 group1]# echo 0 cpus[root@node3 group1]# cat cpus0
再归类到mems中
[root@node3 group1]# echo 0 mems[root@node3 group1]# cat mems0
然后切换至group2中去 见其归类
[root@node3 group1]# cd ../group2/[root@node3 group2]# echo 1 cpus[root@node3 group2]# echo 0 mems
#因为只有第0段内存
由此，这两个组分好了，那么查看组2内的任务tasks
[root@node3 group2]# cat tasks[root@node3 group2]#
发现文件是空的，因为里面没有任何任务在执行，因此有些时候可以自己实现将某个任务只能运行在某个资源组上
那么我们来查看以下根组的tasks,随便找一个PID，将此PID值能运行在组1上
[root@node3 group2]# more ../tasks
比如将进程httpd只运行在组1上
[root@node3 group2]# ps -aux | grep httpdWarning: bad syntax, perhaps a bogus ‘-‘? See /usr/share/doc/procps-3.2.8/FAQapache 2760 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2762 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2765 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2766 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2767 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2768 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2771 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdapache 2772 0.0 0.5 480180 9836 ? S Sep21 0:00 /usr/sbin/httpdroot 20120 0.0 1.0 480044 20200 ? Ss Sep19 0:08 /usr/sbin/httpdroot 20736 0.0 0.0 103256 804 pts/0 R+ 16:12 0:00 grep httpd
将2760的进程号定义到组0上去
[root@node3 cgroup]# echo 2760 group1/tasks[root@node3 cgroup]# cat ./group1/tasks2760
那么这个进程只能在组1内，也就是0号CPU运行
[root@node3 cgroup]# ps axo comm,pid,psr | grep httpdhttpd 2760 0httpd 2762 2httpd 2765 3httpd 2766 1httpd 2767 0httpd 2768 3httpd 21124 0[root@node3 cgroup]# ps axo comm,pid,psr | grep httpdhttpd 2760 0httpd 2762 2httpd 2765 3httpd 2766 1httpd 2767 0[root@node3 cgroup]# ps axo comm,pid,psr | grep httpdhttpd 2760 0httpd 2762 2httpd 2765 3httpd 2766 1一个任务只能关联到一个组中，要在一级组上就不能在根组上，因为不能同时调度
那么我们讲进程号2762 绑定到组2的task中，再来观察根组的task
[root@node3 cgroup]# grep 2762 tasks2762
将其绑定到group2，那么之前的group中的tasks内的进程号则会消失
[root@node3 cgroup]# echo 2762 group2/tasks[root@node3 cgroup]# grep 2762 tasks[root@node3 cgroup]# grep 2762 group2/tasks2762
所以说一个任务只能绑定在一个组内
控制numa策略
在numa结构上，如果每次都使用手动操作可能是一件非常痛苦的事情，好在numa本身可以实现cpu管理的
numactl使用指定的调度或内存放置策略运行进程，使得可以自动关联一个进程到某个numa资源组中
numactl的使用
在numa结构中，如果频繁手动挂载文件系统，会很麻烦，好在umactl提供了numactl命令手动绑定一个进程到某个资源组上的，一个numa节点包含numa内的所有cpu和本地内存
numactl –show 查看当前情况
numactl –hardware 显示系统中可用的节点清单
numactl –membind 只从指定节点分配内存，明确说明进程绑定到哪一段内存中
numactl –cpunodebind 绑定在多个cpu节点上，每个本地的资源组，有的时候我们允许它在两个节点上使用，这时候可以使用这个参数
numactl –preferred 更加期望运行在哪个节点上
CPU亲和性管理进程 numad
使用numa命令管理节点后 numad自动启动为守护进程，并且自动监控保证某些进程只能运行在特定上，numad可对基准性能有50%的提高，要想实现目的，numad会周期性访问/proc/文件系统中的信息，而借此信息实现资源绑定
所以将numad服务启动起来，在numa结构上会提高性能
而numa中常用的另外一个命令叫做numastat，主要显示进程运行状态
默认跟踪分类
numa_hit
numa_miss
第一次在此节点运行，之后依然在此节点运行被称为命中，如果第一次在此节点运行，往后被负载均衡到其他节点上运行，意味着所有本地资源无法命中
hit越高，说明提升的性能越好
numa_foreign
等等。。。。。不再一一介绍
总结
CPU进程优化思路：
#一定做到CPU切换次数较低，尽可能做到上下文切换次数较低，这样额外的系统性能开销就会减小，那么降低的方法无非是将进程绑定在cpu上
常用的方法：
1.taskset 简单绑定，cpu的亲缘性
2.使用cpuset，cpu内存资源组的概念来实现基于虚拟文件系统的cpu亲缘性绑定
3.在numa体系上使用numa的控制功能
以上都为CPU的亲缘性，只不过使用的手段和途径不同
一个最有效的隔离方式是实现开机之后将cpu直接隔离出来，因为绑定之后这个cpu还处于工作状态，它还是需要进行切换的，为了避免切换，可以使用内核参数
通过内核参数：
isolcpus = #
其次将中断处理从隔离出来的CPU上玻璃掉，使用taskset绑定进程至其专用的cpu
再一就是定义进程的优先级别
关注磁盘IO活动情况查看：
常用工具
iostat
dstat
[root@ip-172-31-21-32 ~]# iostat -x /dev/xvdj 1 5Linux 2.6.32-431.11.2.el6.x86_64 (ip-172-31-21-32) 09/28/14 _x86_64_ (4 CPU)avg-cpu: %user %nice %system %iowait %steal %idle 12.76 0.00 2.85 0.07 0.03 84.30Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilxvdj 0.00 69.14 0.00 64.07 0.00 1065.66 16.63 0.51 7.91 0.43 2.74avg-cpu: %user %nice %system %iowait %steal %idle 6.53 0.00 2.01 0.00 0.00 91.46Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilxvdj 0.00 0.00 0.00 48.00 0.00 384.00 8.00 0.12 2.60 0.31 1.50avg-cpu: %user %nice %system %iowait %steal %idle 3.52 0.00 1.01 0.00 0.00 95.48Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilxvdj 0.00 0.00 0.00 24.00 0.00 192.00 8.00 0.07 2.83 0.33 0.80avg-cpu: %user %nice %system %iowait %steal %idle 5.99 0.00 1.75 0.25 0.00 92.02Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilxvdj 0.00 0.00 0.00 33.00 0.00 264.00 8.00 0.15 4.64 0.24 0.80avg-cpu: %user %nice %system %iowait %steal %idle 8.29 0.00 6.28 0.00 0.00 85.43Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilxvdj 0.00 0.00 0.00 25.00 0.00 200.00 8.00 0.07 2.76 0.36 0.90
对于繁忙的服务器来讲，读写应该是很大的
如果我们发现%util始终居高不下，意味着IO性能低下
使用dstat
[root@node3 group1]# dstatTerminal width too small, trimming output.—-total-cpu-usage—- -dsk/total- -net/total- usr sys idl wai hiq siq| read writ| recv send 0 0 100 0 0 0| 838B 10k| 0 0 0 0 100 0 0 0| 0 0 | 652B 1577B 0 0 100 0 0 0| 0 984k| 17k 12k 0 0 100 0 0 0| 0 0 |3165B 2248B 0 0 99 0 0 0| 0 104k|2908B 3347B 0 0 100 0 0 0| 0 0 | 732B 615B 0 0 100 0 0 0| 0 0 |1552B 2159B
因此我们总结出
iostat 通常使用 -x参数
iostat -x /dev/xxxx
dstat 通常使用 -d -r参数
dstat -d -r
还可以使用dstat –top-io 来查看哪个进程最占用IO
[root@node3 group1]# dstat -d -r –top-io-dsk/total- –io/total- —-most-expensive—-read writ| read writ| i/o process838B 10k|0.04 0.79 |init 8038B 1160B 0 0 | 0 0 |zabbix_serv1041B 556B 0 0 | 0 0 |zabbix_serv 634B 201B 0 0 | 0 0 |sshd: root@ 144B 196B 0 176k| 0 28.0 |mongod 0 8601B 0 96k| 0 8.00 |mongod 0 8192B 0 0 | 0 0 |zabbix_serv2494B 1196B
通过这种方式来观测哪个进程最消耗IO
以上，为linux常用系统评估的一些方法，感谢各位看官
可是我知道结果是惨淡的，但还是心存希望！
