Linux笔记 性能监测

性能监测指标

我们常说性能，无非就是以下四点，而对于性能监控来说，也无法就是要做到对以下四点的监控：

• CPU---vmstat、top
• 内存---free
• I/O---vmstat、iostat、pidstat、lsof
• 网络---ip、netstat、tcpdump、sar

而这四点又不是单独存在的，而是彼此影响的，对于这些性能监测，我们不能一味的去使用工具，看工具的输出内容而进行确定。必须要结合实际的Linux主机部署的业务进行分析。比如：

• I/O相关，I/O相关的应用通常用来处理大量数据，需要大量内存和存储，频繁I/O操作读、写数据，而对CPU的要求则较少，大部分时候CPU都在等待硬盘，比如，数据库服务器、文件服务器等；
• CPU相关，CPU相关的应用需要使用大量CPU，比如高并发的web/mail服务器、图像/视频处理、科学计算等都可被视作CPU相关的应用；
• 内存相关，现在的大型应用都会或多或少的使用内存数据库，而对于内存数据库来说，内存就是它的命根子，而对于部署内存数据库的服务器来说，我们就要关注它的内存和网络了；
• 网络相关，对于网络相关的，现在基本都是千兆、万兆的，出现网络的问题不大，但是一旦出现就是很棘手的问题，也是非常考验人的基本功的问题。

Linux性能监测：CPU篇

 

什么是CPU

中央处理器（CPU，Central Processing Unit）是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU主要包括运算器（算术逻辑运算单元，ALU，Arithmetic Logic Unit）和高速缓冲存储器（Cache）及实现它们之间联系的数据（Data）、控制及状态的总线（Bus）。它与内部存储器（Memory）和输入/输出（I/O）设备合称为电子计算机三大核心部件。

CPU的主要功能是解释计算机指令以及处理计算机软件中的数据，并执行指令。说简单点，就是我们编写的程序，经过编译后，最终都会变成一条条的指令，由CPU来进行最终的执行。通常CPU的运算速度、主频、缓存、核心数，这几个参数就决定了CPU的好坏，一般情况下，CPU的主频越高、缓存越大、核心数越多，这样的CPU运转速度就很快，处理图形图像文件起来，速度就越快，这种CPU的价格就比较贵。

除了上面的一些定义和常识外，我们还需要明白一些特殊名词的含义。

• 物理CPU
  主板上实际插入的cpu数量；这个是物理存在的设备。打开主板，我们是可以肉眼看到的。在Linux服务器上，我们可以通过以下命令查看物理CPU个数：

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

　　

• CPU核数
  核数就是指CPU上集中的处理数据的cpu核心个数，单核指cpu核心数一个，双核则指的是两个。通常每个CPU下的核数都是固定的，比如你的计算机有两个物理CPU，每个CPU是双核，那么计算机就是四核的。在Linux服务器上，我们可以通过以下命令查看CPU核数：

cat /proc/cpuinfo | grep "cpu cores" | wc -l

　　

• 逻辑CPU
  一般情况下，逻辑CPU=物理CPU个数×每颗核数，如果不相等的话，则表示服务器的CPU支持超线程技术（HT：简单来说，它可使处理器中的1颗内核像2颗内核那样在操作系统中发挥作用。这样一来，操作系统可使用的执行资源扩大了一倍，大幅提高了系统的整体性能，此时逻辑CPU=物理CPU个数×每颗核数x2）；可以通过以下命令来查看逻辑CPU个数：

cat /proc/cpuinfo | grep "processor" | wc -l

　　

• CPU过高会带来哪些问题

  CPU是用来运行各种程序，做各种计算的，一旦CPU处于高负荷状态，容易引起服务响应速度变慢，进而导致整个服务不可用，特别是在业务高峰期可能导致雪崩效应，最终整个系统出现瘫痪。

  如何检查CPU健康状态

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

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

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

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

  要监控CPU的性能，那我们就必须先知道每个参数的健康区间，一个评判的标准，这样才能初步判断CPU的健康状况。

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

  确定了评判标准后，那我们就需要通过工具实时的查看系统的这些重要参数是否在健康标准范围之内。主要有vmstat和top这两个工具。

Linux性能监测：IO篇

先说理论

而要说IO性能，就不得不先说说缺页中断了。Linux利用虚拟内存极大的扩展了程序地址空间，使得原来物理内存不能容下的程序也可以通过内存和硬盘之间的不断交换（把暂时不用的内存页交换到硬盘，把需要的内存页从硬盘读到内存）来赢得更多的内存，看起来就像物理内存被扩大了一样。事实上这个过程对程序是完全透明的，程序完全不用理会自己哪一部分、什么时候被交换进内存，一切都有内核的虚拟内存管理来完成。当程序启动的时候，Linux内核首先检查CPU的缓存和物理内存，如果数据已经在内存里就忽略，如果数据不在内存里就引起一个缺页中断（Page Fault），然后从硬盘读取缺页，并把缺页缓存到物理内存里。缺页中断可分为主缺页中断（Major Page Fault）和次缺页中断（Minor Page Fault），要从磁盘读取数据而产生的中断是主缺页中断；数据已经被读入内存并被缓存起来，从内存缓存区中而不是直接从硬盘中读取数据而产生的中断是次缺页中断。

上面的内存缓存区起到了预读硬盘的作用，内核先在物理内存里寻找缺页，没有的话产生次缺页中断从内存缓存里找，如果还没有发现的话就从硬盘读取。很显然，把多余的内存拿出来做成内存缓存区提高了访问速度，这里还有一个命中率的问题，运气好的话如果每次缺页都能从内存缓存区读取的话将会极大提高性能。要提高命中率的一个简单方法就是增大内存缓存区面积，缓存区越大预存的页面就越多，命中率也会越高。

内存缓存区（也叫文件缓存区File Buffer Cache）读取页比从硬盘读取页要快得多，所以Linux内核希望能尽可能产生次缺页中断（从文件缓存区读），并且能尽可能避免主缺页中断（从硬盘读），这样随着次缺页中断的增多，文件缓存区也逐步增大，直到系统只有少量可用物理内存的时候Linux才开始释放一些不用的页。我们运行Linux一段时间后会发现虽然系统上运行的程序不多，但是可用内存总是很少，这样给大家造成了Linux对内存管理很低效的假象，事实上Linux把那些暂时不用的物理内存高效的利用起来做预存（内存缓存区）了。

比如，以下这样的一个输出：

[root@Test_Server ~]# cat /proc/meminfo 
MemTotal:        1883496 kB
MemFree:          137236 kB
MemAvailable:     286512 kB
Buffers:          107028 kB
Cached:           150352 kB

　

可以看到内存一共大概2G（MemTotal），其中大概130M可用（MemFree），100多M用来做磁盘缓存（Buffers），150多M用来做文件缓存（Cached）。

好了，有了这些基本知识，我们再来看IO性能的分析。

再说实干

说到实际的，那就要说说实际运维工作中，我们如何发现IO性能瓶颈。

我们进行IO分析，第一步还是需要祭出我们的神器vmstat，通过vmstat的输出，重点关注b、bi、bo和wa字段。这几个值变大，都意味着IO的消耗增加。对于读请求大的服务器，一般b、bi、wa都会比较大，而对于写入量大的服务器，一般b、bo、wa都会比较大。

接下来就是使用第二个神器iostat。通过这个神器，我们就可以监视具体的磁盘性能了。

但是，在实际运维工作中，我们都希望找到是哪个进程消耗了IO，所以我们的终极目的是找到这个进程ID。可是通过vmstat和iostat都没法达到我们的目的。所以，神器pidstat命令就登场了，通过这个命令，我们就可以知道是谁在后台偷用IO了。

现在定位到进程级别了，很多时候，我们需要知道这个进程到底打开了哪些文件，这个进程到底和哪些进程关联，这个时候就不得不提到lsof命令了。

 

Linux性能监测：内存篇

物理内存和虚拟内存

说到内存，我们都会说到物理内存和虚拟内存的。物理内存就是真实的硬件设备，也就是咱们的内存条；虚拟内存（Virtual Memory）是把计算机的内存空间扩展到硬盘，物理内存（RAM）和硬盘的一部分空间（SWAP）组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间，好处是我们拥有的内存“变多了”，可以运行更多、更大的程序，坏处是把部分硬盘当内存用整体性能受到影响，硬盘读写速度要比内存慢几个数量级，并且RAM和SWAP之间的交换增加了系统的负担。

我们需要记住的一点是Linux会在物理内存不足时，使用交换分区的虚拟内存。

free命令详解

free命令可以显示Linux系统中空闲的、已用的物理内存及swap内存，及被内核使用的buffer。在Linux系统监控的工具中，free命令是最经常使用的命令之一。虽然在《Linux top命令详解》和《Linux vmstat命令详解》这两篇文章中也有详细的说内存和性能相关的内容，但是很多时候，我们还是会先敲上free -m先看看内存信息。所以，我们需要会用free命令，以及可以看到free命令输出的信息。

free命令习惯上有以下几种形式：

free -k # 以KB为单位显示内存使用情况
free -m # 以MB为单位显示内存使用情况
free -g # 以GB为单位显示内存使用情况
free -h # 以人类友好的方式显示内存使用情况

　　

当我们输入free -m时，系统就会输出以下内容：

[root@Test_MC]# free -m
​
             total       used       free     shared    buffers     cached
Mem:         32168      30119       2048          0       4438      11097
-/+ buffers/cache:      14583      17584
Swap:        31996       1899      30097

 

现在对free命令输出的每行进行详细的解释：

• total：内存总数，物理内存总数
• used：已经使用的内存数
• free：空闲的内存数
• shared：多个进程共享的内存总额
• buffers：缓冲内存数
• cached：缓存内存数
• - buffers/cached：应用使用内存数
• + buffers/cached：应用可用内存数
• Swap：交换分区，虚拟内存

我们通过free命令查看机器空闲内存时，会发现free的值很小。这主要是因为，在Linux系统中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。

在使用free命令时，我们都是需要重点关注- buffers/cached和+ buffers/cached。

• - buffers/cached，即used - buffers/cached，表示应用程序实际使用的内存
• + buffers/cached，即free + buffers/cached，表示理论上都可以被使用的内存

可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。

 

 

 

 

 

Linux性能监测：网络篇

前言

网络的监测是所有Linux子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与Linux主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为Linux网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。

细读以下几遍文章

说到网络性能，肯定也要通过一些工具来发现这些性能问题。下面说的这些工具，就是作为运维人员不得不会的。

• 《Linux ip命令详解》
• 《Linux netstat命令详解》
• 《Linux tcpdump命令详解》
• 《Linux sar命令详解》

经验分享

即使掌握了上面的几个命令，如果没有实际的经验，也是很难把住网络这个难题的命脉的。在实际工作中，主要观察点分为以下两点：

• UDP监控
  • 对于UDP监控而言，我们需要查看所有监听端口的网络情况，通过netstat -anu命令进行查看，对于Recv-Q和Send-Q两个指标值为0，或者在时间区间内对应的值不大都说明是正常的；
  • 同时对于UDP服务而言，查看丢包情况，即网卡收到了，但是应用层没有处理过来的而造成的丢包。主要通过netstat -su命令查看，确认是否有大量错误包。
• TCP监控
  • 对于TCP服务而言，这个就比较复杂；因为TCP涉及到重传，所以我们就需要重点关注这个重传率。通过netstat -st命令查看segments send out和segments retransmited指标，对比一段时间内，这两个指标的增长率就是对应的重传率，发生重传说明网络传输有丢包，基本上从3个点去定位：客户端网络情况、服务端网络情况、中间链路网络情况：
    • 客户端机器网络异常
    • 服务端网卡流量跑满，网卡有丢包现象，关注ifconfig的error输出
    • 中间网络连路拥塞，比如交换机上联、核心交换机链路等，需要逐个排查链路流量情况
  • 另一个关注点就是网卡吞吐率，我们可以通过sar -n DEV 2 3命令来查看，将rxkB/s和txkB/s进行相加，得到网卡设备的实际吞吐率，然后再和网卡的硬件指标进行比对即可。比如一个网卡的rxkB/s指标为21999.10，txkB/s指标为482.56，那这个网卡的吞吐率大概在22Mbytes/s，即176 Mbits/sec，没有达到1Gbit/sec的硬件上限。

附录

计算重传率的Shell脚本：

#!/bin/bash
export PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin'
SHELLDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
​
netstat -s -t > /tmp/netstat_s 2>/dev/null
​
s_r=`cat /tmp/netstat_s | grep 'segments send out' | awk '{print $1}'`
s_re=`cat /tmp/netstat_s  | grep 'segments retransmited' | awk '{print $1}'`
​
[ -e ${SHELLDIR}/s_r ] || touch ${SHELLDIR}/s_r
[ -e ${SHELLDIR}/s_re ] || touch ${SHELLDIR}/s_re
​
l_s_r=`cat ${SHELLDIR}/s_r`
l_s_re=`cat ${SHELLDIR}/s_re`
​
echo $s_r > ${SHELLDIR}/s_r
echo $s_re > ${SHELLDIR}/s_re
​
tcp_re_rate=`echo "$s_r $s_re $l_s_r $l_s_re" | awk '{printf("%.2f",($2-$4)/($1-$3)*100)}'`
echo $tcp_re_rate
 

　　

 

 

 

 

 

 

 

来源： https://www.jellythink.com/archives/486