CPU调优
Cpu处理数据的方式：
1：批处理,顺序处理请求.(切换次数少,吞吐量大)
2：分时处理.(如同"独占",吞吐量小)(时间片，把请求分为一个一个的时间片，一片一片的分给 CPU 处理) 我们现在使用 x86 就是这种架构
3：实时处理.
批处理——以前的大型机（Mainframe）上所采用的系统，需要把一批程序事先写好（打孔纸带），然后计算得出结果
分时——现在流行的 PC 机和服务器都是采用这种运行模式，即把 CPU 的运行分成若干时间片分别处理不同的运算请求
实时——通常一般用于单片机上，比如电梯的上下控制，对于按键等动作要求进行实时处理
内核中断
grep HZ /boot/config-2.6.32-431.el6.x86_64 //是编译内核的参数文件
ONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000 #每一秒中有1000个中断
CONFIG_MACHZ_WDT=m
中断
中断是指在计算机执行期间，系统内发生任何非寻常的或非预期的急需处理事件，使得CPU暂时中断当前正在执行的程序而转去执行相应的时间处理程序。待处理完毕后又返回原来被中断处继续执行或调度新的进程执行的过程。中断是一种发生了一个外部的事件时调用相应的处理程序的过程。
硬中断
外围硬件发给CPU或者内存的异步信号就是硬中断信号。简言之：外设对CPU的中断, 因此具有随机性和突发性, , 硬件中断处理程序要确保它能快速地完成它的任务,这样程序执行时才不会等侍较长时间, 外部设备(如输入输出设备)请求引起的中断，也称为外部中断或I/O中断。例如（鼠标点击程序"取消"）
软中断
由软件本身发给操作系统内核的中断信号，称之为软中断。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调用(System Call)了。软中断发生的时间是由程序控制的
计算机为什么要采用中断
为了说明这个问题，举一例子。假设你有一个朋友来拜访你，但是由于不知道何时到达，你只能在大门等待，于是什么事情也干不了。如果在门口装一个门铃，你就不必在门口等待而去干其它的工作，朋友来了按门铃通知你，你这时才中断你的工作去开门，这样就避免等待和浪费时间。计算机也是一样，例如打印输出，CPU传送数据的速度高，而打印机打印的速度低，如果不采用中断技术，CPU将经常处于等待状态，效率极低。而采用了中断方式，CPU可以进行其它的工作，只在打印机缓冲区中的当前内容打印完毕发出中断请求之后，才予以响应，暂时中断当前工作转去执行向缓冲区传送数据，传送完成后又返回执行原来的程序。这样就大大地提高了计算机系统的效率。
调整进程优先级使用更多CPU
调整进程nice值，让进程使用更多的CPU
nice值的范围， -20 ~ 19 越小优先级越高 普通用户0－19
作用：以什么优先级运行进程 。默认优先级是0
语法： nice -n 优先级数字 命令
[root@localhost ~]#nice -n -5 vim a.txt //vim进程以-5级别运行
[root@localhost ~]# ps -axu | grep b.txt
Warning: bad syntax, perhaps a bogus'-'? See/usr/share/doc/procps-3.2.8/FAQ
root 24318 0.0 0.2 143624 3280 pts/4 S+ 17:00 0:00 vim b.txt
[root@localhost ~]# top -p 24318
PID USER PR NI VIRT RES SHR S%CPU%MEM TIME+ COMMAND
24219 root 15 -5 140m3336 2200 S 0.0 0.3 0:00.08 vim
renice 修改正在运行的进程的优先级，更改正在运行进程的优先级
renice -n 5 PID //修改进程优先级
[root@localhost ~]#renice -n 5 24318
[root@localhost ~]# top -p 24318
PID USER PR NI VIRT RES SHR S%CPU%MEM TIME+ COMMAND
24219 root 15 5 140m3336 2200 S 0.0 0.3 0:00.08 vim
nice值验证
[root@localhost~]# renice -n -21 24219
24219: old priority -20, new priority -20
[root@localhost ~]# renice -n 20 24219
24219: old priority -20, new priority 19
CPU亲和力
在多核情况下，可以认为指定一个进程在哪颗CPU上执行程序，减少进程在不同CPU之前切换的开销，使用taskset命令
[root@localhost ~]# rpm -ivh /media/Packages/util-linux-ng-2.17.2-12.4.el6.x86_64
语法： taskset -c N 命令 //-c=cuplist N=第几个CPU，也就是cpuinfo的#号
[root@localhost ~]# taskset -c 0 vim a.txt //本机是4核CPU ，指定vim命令在第一个CPU上运行，1号CPU ID是0
[root@localhost ~]# ps -axu | grep vim
Warning: bad syntax, perhaps a bogus'-'? See/usr/share/doc/procps-3.2.8/FAQ
root 2614 1.3 0.2 143696 3332 pts/0 S+ 18:39 0:00 vim a.txt
[root@localhost ~]# taskset -p 2614 //要查看的进程ID
pid2614's current affinity mask: 1 #CPU亲和力掩码，1代表第一个CPU核心
查sshd进程运行在哪几个CPU上
[root@localhost ~]# ps -axu | grep sshd
Warning: bad syntax, perhaps a bogus'-'? See/usr/share/doc/procps-3.2.8/FAQ
root 2030 0.0 0.0 64068 1140 ? Ss 18:26 0:00 /usr/sbin/sshd
[root@localhost ~]# taskset -p 2030
pid2030's current affinity mask: f #说明sshd在4颗CPU上随机进行切换。
关于换算方式
8个核心的CPU ID： 7 6 5 4 3 2 1 0
对应10的十进制数位： 128 64 32 16 8 4 2 1
十六进制的16个数是：0、1、2、3、4、5、6、7、8、9、A、B、C、D、E、F
对应每一个16进制的二进制位：0=0000,1=0001,2=0010,3=0011,4=0100,5=0101,6=0110,7=0111,8=1000,9=1001,A=1010,
B=1011,C=1100,D=1101,E=1110,F=1111
那么例如出现pid 8987's current affinity mask: ff ff是16进制，转换二进制：11111111，意思就是sshd在8个CPU上进行却换！所以对应每一个数值!
比如说16进制的40，那么转换二进制01000000，意思就是在第7块CPU上运作
[root@localhost ~]# taskset -c 1,5 vim 1.txt //在第一个cpu和6个cpu上运行
[root@localhost ~]# ps -aux | grep vim
Warning: bad syntax, perhaps a bogus'-'? See/usr/share/doc/procps-3.2.8/FAQ
root 7414 0.3 0.2 143528 3940 pts/1 S+ 11:17 0:00 vim1.txt
root 7417 0.0 0.0 103244 872 pts/0 S+ 11:18 0:00 grep vim
[root@localhost ~]#taskset -p 7414
pid7414's current affinity mask: 22
在哪个CPU上运行，二进制就在哪一个上赋值为1，那么二进制表示为：00100010
CPU利用率分配
如果一个 CPU 被充分使用,利用率分类之间均衡的比例应该是:
65% 70% User Time //用户态
30% 35% System Time //内核态
0% 5% Idle Time //空闲
Context Switches 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,有大量的上下文切换是正常的.
如果系统的中断多，我们可以判断系统进程正在高速运行
如果系统的上下文切换多，我们可以判断系统此时有很多进程/线程在运行
vmstat参数分析案例1：
[root@localhost ~]# vmstat 1 //本机为单核CPU，执行vmstat显示以下内容
procs --------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 130644 86244 609860 0 0 4 1 531 25 0 0 20 0 0
4 0 0 130620 86244 609860 0 0 0 0 638 62 0 0 14 0 0
2 0 0 130620 86244 609860 0 0 0 0 658 62 0 0 13 0 0
4 0 0 130620 86244 609860 0 0 0 0 688 62 0 0 11 0 0
根据观察值,我们可以得到以下结论:
1,有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程正在快速运行，如果进程多那么就会有大量的上下文切换，意思就是上下文的量可以看出进程的量，同时通过中断可以看出来，CPU暂时停止当前程序的执行转而执行处理新情况的程序和执行过程，也就是需要处理我们的进程！其他的进程在等待了，也就是在排队的情况！
2,进一步显示应用,user time(us) 经常在86%或者更多。
执行top — 按P — 查看使用CPU最多的进程
top- 12:00:53 up 2:31, 3 users, load average: 0.00, 0.00, 0.00
Tasks: 217 total, 3 running, 214 sleeping, 0 stopped, 0 zombie
Cpu(s): 89.7%us, 7.3%sy, 0.0%ni, 11.3%id, 10.6%wa, 0.0%hi, 0.1%si, 0.0%st
……
PID USER PR NI VIRT RES SHR S%CPU%MEM TIME+ COMMAND
3096 root 20 0 290m 13m9668 S21.9 1.3 0:03.58 gnome-terminal
3743 root 20 0 109m1280 900 R19.6 0.1 0:02.82 find
……
3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
4,这个系统的CPU被充分利用
vmstat参数分析案例2：
[root@localhost ~]# vmstat 1 10
procs --------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 130644 86244 609860 0 0 4 1 531 2556 0 0 20 70 0
4 0 0 130620 86244 609860 0 0 0 0 638 6234 0 0 14 60 0
2 0 0 130620 86244 609860 0 0 0 0 658 6212 0 0 13 65 0
4 0 0 130620 86244 609860 0 0 0 0 688 6123 0 0 11 46 0
1,上下文切换数目高于中断数目,说明当前系统中运行着大量的线程，kernel中相当数量的时间都开销在线程的”上下文切换“。
2,大量的上下文切换将导致CPU 利用率不均衡.很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us). 说明磁盘比较慢，磁盘是瓶颈
3,因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数量的可运行状态线程在等待执行.
4, 内核调度中的上下文切换处于饱和,瓶颈明显