CPU子系统

 想到的办法：
  结束某些没有进程和服务
  超频、超线程
  升级cpu
dmidecode  -t processor | grep Socket （物理cpu个数）

dmidecode | grep Size | grep MB  （物理内存大小）

dmidecode | grep Size | grep MB | wc -l （物理内存个数）

 中断  －－－－ cpu停止当前运行的指令，停下去执行更紧急的指令，一般都是IO产生中断，也可以网络IO导致网卡接受和发送数据。

 上下文 －－－ 指令执行过程，需要的一些变量环境（cpu寄存器的一些数据）

 上下文切换 －－－－ 一般由于内核进行调度或中断的产生，都会引起上下文切换。
 内核调度 －－－－ 控制各个进程甚至是各个指令指令的优先级别
 用户空间程序（普通应用程序）
 运行队列

 

 工具：

  vmstat,mpstat,sar(sysstat),top,ps,uptime

# cat /proc/cpuinfo 
# dmidecode  -t processor
# 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