CPU子系统
想到的办法：
结束某些没有进程和服务
超频、超线程
升级cpu
中断 －－－－ cpu停止当前运行的指令，停下去执行更紧急的指令，一般都是IO产生中断，也可以网络IO导致网卡接受和发送数据。
上下文 －－－ 指令执行过程，需要的一些变量环境（cpu寄存器的一些数据）
上下文切换 －－－－ 一般由于内核进行调度或中断的产生，都会引起上下文切换。
内核调度 －－－－ 控制各个进程甚至是各个指令指令的优先级别
用户空间程序（普通应用程序）
运行队列
工具：
vmstat,mpstat,sar(sysstat),top,ps,uptime
# cat /proc/cpuinfo
# dmidecode -t processo
# dmidecode -t cache
# uptime
14:57:12 up 1:16, 3 users, load average: 2.82, 5.43, 3.85
系统负载： 在指定单位之间（1,5,15分钟）系统平均运行队列。数字越大，队列越长，系统就越忙。这里还与cpu物理核心（不算超线程）相关。
以15分钟平均负载作为例子：
单核cpu：
过去15分钟，cpu的运行队列平均为3.85（1进程正在被执行，2.85个在排队）
双核cpu：
过去15分钟，单个cpu核心的运行队列平均为(3.85/2~=1.9，1个正在被cpu执行，0.9在排队)
经验：如果单核cpu的运行队列超过3，一般说明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
0 0 120 55156 23864 1581996 0 0 700 25 1103 1221 13 7 77 3 0
procs
r b
0 0
r ,一分钟去平均值就是代表uptime的系统负载一分钟的平均值
b ,一般只要出现超过3，就非常值得注意。
--system-- -----cpu------
in cs us sy id wa st
1103 1221 13 7 77 3 0
in 中断次数
cs 上下文切换的次数，次数越多，说明内核进行的任务调度就越多。
us 用户空间使用的cpu时间片的百分比，cpu的大部分时间应该消耗在这里
sy 系统（内核完成任务：中断处理，上下文切换，任务调度）使用的cpu时间百分比
id 空闲
wa cpu花了多少百分比的时间在等待IO（硬盘IO），数字越大，一般说明是存在IO瓶颈
st 被虚拟化里的客户机“偷”掉的cpu时间百分比
经验：
us:sy ~= 7:3
wa 不能太大
id 非常小，不能说明cpu就不够，或者出现瓶颈，只能说明cpu被充分利用，最严重就只能说明一种趋势－－－系统再忙一点，cpu可能就不够用了
# vmstat 2
# vmstat 2 5
# mpstat 2 5
# mpstat 2 5 -P ALL
# sar -u 2 5
计划任务
# vim /etc/cron.d/sysstat
