[系统资源攻略]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
ps
#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。