[系统资源攻略]CPU

linux系统中如何查看cpu信息？

查看linux版本、cpu、位数、内核、内存等信息 linux下查看CPU，内存，机器型号，网卡等信息的方法查看服务器物理CPU数和CPU核数方法介绍

可以用/proc/cpuinfo 查看CPU 的信息。

该文件包含系统上每个处理器的数据段落。/proc/cpuinfo 描述中有 6 个条目适用于多内核和超线程（HT）技术检查：processor, vendor id, physical id, siblings, core id 和 cpu cores。

processor：包括这一逻辑处理器的唯一标识符。
physical id ：包括每个物理封装的唯一标识符。
core id ：保存每个内核的唯一标识符。
siblings ：列出了位于相同物理封装中的逻辑处理器的数量。
cpu cores ：包含位于相同物理封装中的内核数量。
如果处理器为英特尔处理器，则 vendor id 条目中的字符串是 GenuineIntel。

拥有相同 physical id 的所有逻辑处理器共享同一个物理插座。每个 physical id 代表一个唯一的物理封装。Siblings 表示位于这一物理封装上的逻辑处理器的数量。逻辑处理器可能支持也可能不支持超线程（HT）技术。每个 core id 均代表一个唯一的处理器内核。所有带有相同 core id 的逻辑处理器均位于同一个处理器内核上。如果有一个以上逻辑处理器拥有相同的 core id 和 physical id，则说明系统支持超线程（HT）技术。如果有两个或两个以上的逻辑处理器拥有相同的 physical id，但是 core id 不同，则说明这是一个多内核处理器。cpu cores 条目也可以表示是否支持多内核。

查看CPU 信息

可以通过/proc/cpuinfo 这个文件来查看CPU 的信息。

#more /proc/cpuinfo

查看CPU 是否支持64bit

结果大于0, 说明支持64bit计算. lm指long mode, 支持lm则是64bit。

[root@qs-wgdb-1 proc]# cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l

16

逻辑CPU个数

#cat /proc/cpuinfo | grep 'processor' | wc -l

24

注意：这里是逻辑CPU。就是在cpuinfo中看到的processor。

物理CPU个数：

#cat /proc/cpuinfo | grep 'physical id' | sort | uniq | wc -l

2

这里指的是物理CPU，就是在服务器上看到的2个CPU 插槽。

每个物理CPU中Core的个数

#cat /proc/cpuinfo | grep 'cpu cores' | wc -l

24

是否为超线程

如果有两个逻辑CPU具有相同的”core id”，那么超线程是打开的。

每个物理CPU中逻辑CPU(可能是core, threads或both)的个数。

#cat /proc/cpuinfo | grep 'siblings'siblings        : 8

触发瓶颈

CPU 的占用主要取决于什么样的资源正在 CPU 上面运行，比如拷贝一个文件通常占用较少 CPU，因为大部分工作是由 DMA（Direct Memory Access）完成，只是在完成拷贝以后给一个中断让 CPU 知道拷贝已经完成；科学计算通常占用较多的 CPU，大部分计算工作都需要在 CPU 上完成，内存、硬盘等子系统只做暂时的数据存储工作。要想监测和理解 CPU 的性能需要知道一些的操作系统的基本知识，比如：中断、进程调度、进程上下文切换、可运行队列等。这里用个例子来简单介绍一下这些概念和他们的关系，CPU 很无辜，是个任劳任怨的打工仔，每时每刻都有工作在做（进程、线程）并且自己有一张工作清单（可运行队列），由老板（进程调度）来决定他该干什么，他需要和老板沟通以便得到老板的想法并及时调整自己的工作（上下文切换），部分工作做完以后还需要及时向老板汇报（中断），所以打工仔（CPU）除了做自己该做的工作以外，还有大量时间和精力花在沟通和汇报上。

CPU 也是一种硬件资源，和任何其他硬件设备一样也需要驱动和管理程序才能使用，我们可以把内核的进程调度看作是 CPU 的管理程序，用来管理和分配 CPU 资源，合理安排进程抢占 CPU，并决定哪个进程该使用 CPU、哪个进程该等待。操作系统内核里的进程调度主要用来调度两类资源：进程（或线程）和中断，进程调度给不同的资源分配了不同的优先级，优先级最高的是硬件中断，其次是内核（系统）进程，最后是用户进程。每个 CPU 都维护着一个可运行队列，用来存放那些可运行的线程。线程要么在睡眠状态（blocked 正在等待 IO）要么在可运行状态，如果 CPU 当前负载太高而新的请求不断，就会出现进程调度暂时应付不过来的情况，这个时候就不得不把线程暂时放到可运行队列里。VPSee 在这里要讨论的是性能监测，上面谈了一堆都没提到性能，那么这些概念和性能监测有什么关系呢？关系重大。如果你是老板，你如何检查打工仔的效率（性能）呢？我们一般会通过以下这些信息来判断打工仔是否偷懒：

打工仔接受和完成多少任务并向老板汇报了（中断）；
打工仔和老板沟通、协商每项工作的工作进度（上下文切换）；
打工仔的工作列表是不是都有排满（可运行队列）；
打工仔工作效率如何，是不是在偷懒（CPU 利用率）。

现在把打工仔换成 CPU，我们可以通过查看这些重要参数：中断、上下文切换、可运行队列、CPU 利用率来监测 CPU 的性能。

Linux 性能监测：介绍提到了性能监测前需要知道底线，那么监测 CPU 性能的底线是什么呢？通常我们期望我们的系统能到达以下目标：

CPU 利用率，如果 CPU 有 100％利用率，那么应该到达这样一个平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time；
上下文切换，上下文切换应该和 CPU 利用率联系起来看，如果能保持上面的 CPU 利用率平衡，大量的上下文切换是可以接受的；
可运行队列，每个可运行队列不应该有超过1－3个线程（每处理器），比如：双处理器系统的可运行队列里不应该超过6个线程。

CPU负载(CPU可运行队列)

什么是CPU负载
- 负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息，也就是cpu使用队列的长度统计信息，这个数字越小越好
CPU负载多少算合理？
- 每个可运行队列不应该有超过1－3个线程（每处理器），比如：双处理器系统的可运行队列里不应该超过6个线程。

CPU使用率

总CPU使用率,单coreCPU使用率，可以使用mpstat命令查看
```
#mpstat -P ALL 1 10
```
CPU使用率多少合理？
- 如果 CPU 有 100％利用率，那么应该到达这样一个平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time；
CPU负载和CPU使用率的区别

其他命令

tsar

#tsar --cpu -li1

Time              -----------------------cpu----------------------

Time                user     sys    wait    hirq    sirq    util

15/03/17-14:07:40   0.00    0.00    0.00    0.00    0.00    0.00

15/03/17-14:07:41   0.00    0.04    0.00    0.00    0.00    0.04

mpstat

Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle

Average:     all    0.03    0.00    0.06    0.00    0.00    0.00    0.00    0.00    0.00   99.92

Average:       0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

#while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'syslog-ng'; sleep 1; done

  1088   0  19  0.0  21 syslog-ng

  1088   0  19  0.0  21 syslog-ng

pidstat 1

pidstat命令输出进程的CPU占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态。如上的输出，可以看见两个JAVA进程占用了将近1600%的CPU时间，既消耗了大约16个CPU核心的运算资源。

$ pidstat 1

Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)

07:41:02 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0

07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave

07:41:03 PM     0      4354    0.94    0.94    0.00    1.89     8  java

07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java

07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java

07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat

07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave

07:41:04 PM     0      6521 1590.00    1.00    0.00 1591.00    27  java

07:41:04 PM     0      6564 1573.00   10.00    0.00 1583.00    28  java

07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass

07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat

^C

案例

举两个现实中的例子来实际分析一下：

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 4  0    140 2915476 341288 3951700  0    0     0     0 1057  523 19 81  0  0  0

 4  0    140 2915724 341296 3951700  0    0     0     0 1048  546 19 81  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1044  514 18 82  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0    24 1044  564 20 80  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1060  546 18 82  0  0  0

从上面的数据可以看出几点：

interrupts（in）非常高，context switch（cs）比较低，说明这个 CPU 一直在不停的请求资源；
user time（us）一直保持在 80％以上，而且上下文切换较低（cs），说明某个进程可能一直霸占着 CPU；
run queue（r）刚好在4个。

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0

17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0

20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0

17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0

16  0    140 2904580 341912 3952108  0    0     0     0 1055 9808 34 65  1  0  0

从上面的数据可以看出几点：

context switch（cs）比 interrupts（in）要高得多，说明内核不得不来回切换进程；
进一步观察发现 system time（sy）很高而 user time（us）很低，而且加上高频度的上下文切换（cs），说明正在运行的应用程序调用了大量的系统调用（system call）；
run queue（r）在14个线程以上，按照这个测试机器的硬件配置（四核），应该保持在12个以内。

参数介绍：

r，等待在CPU资源的进程数。这个数据比平均负载更加能够体现CPU负载情况，数据中不包含等待IO的进程。如果这个数值大于机器CPU核数，那么机器的CPU资源已经饱和。
b，被 blocked 的进程数，正在等待 IO 请求；
in，被处理过的中断数
cs，系统上正在做上下文切换的数目
us，用户占用 CPU 的百分比
sys，内核和中断占用 CPU 的百分比
wa，所有可运行的线程被 blocked 以后都在等待 IO，这时候 CPU 空闲的百分比
id，CPU 完全空闲的百分比
si, so：交换区写入和读取的数量。如果这个数据不为0，说明系统已经在使用交换区（swap），机器物理内存已经不足。

上述这些CPU时间，可以让我们很快了解CPU是否出于繁忙状态。一般情况下，如果用户时间和系统时间相加非常大，CPU出于忙于执行指令。如果IO等待时间很长，那么系统的瓶颈可能在磁盘IO。