CPU子系统调优

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