Linux服务器的那些性能参数指标

时间 2019-11-19

原文原文链接

Linux服务器的那些性能参数指标

一个基于Linux操做系统的服务器运行的同时，也会表征出各类各样参数信息。一般来讲运维人员、系统管理员会对这些数据会极为敏感，可是这些参数对于开发者来讲也十分重要，尤为当你的程序非正常工做的时候，这些蛛丝马迹每每会帮助快速定位跟踪问题。
　　这里只是一些简单的工具查看系统的相关参数，固然不少工具也是经过分析加工/proc、/sys下的数据来工做的，而那些更加细致、专业的性能监测和调优，可能还须要更加专业的工具(perf、systemtap等)和技术才能完成哦。毕竟来讲，系统性能监控自己就是个大学问。
php

1、CPU和内存类

1.1 top

　　➜ ~ top

　　第一行后面的三个值是系统在以前一、五、15的平均负载，也能够看出系统负载是上升、平稳、降低的趋势，当这个值超过CPU可执行单元的数目，则表示CPU的性能已经饱和成为瓶颈了。html

　　第二行统计了系统的任务状态信息。running很天然没必要多说，包括正在CPU上运行的和将要被调度运行的；sleeping一般是等待事件(好比IO操做)完成的任务，细分能够包括interruptible和uninterruptible的类型；stopped是一些被暂停的任务，一般发送SIGSTOP或者对一个前台任务操做Ctrl-Z能够将其暂停；zombie僵尸任务，虽然进程终止资源会被自动回收，可是含有退出任务的task descriptor须要父进程访问后才能释放，这种进程显示为defunct状态，不管是由于父进程提早退出仍是未wait调用，出现这种进程都应该格外注意程序是否设计有误。

　　第三行CPU占用率根据类型有如下几种状况：
　　(us) user: CPU在低nice值(高优先级)用户态所占用的时间(nice<=0)。正常状况下只要服务器不是很闲，那么大部分的CPU时间应该都在此执行这类程序
　　(sy) system: CPU处于内核态所占用的时间，操做系统经过系统调用(system call)从用户态陷入内核态，以执行特定的服务；一般状况下该值会比较小，可是当服务器执行的IO比较密集的时候，该值会比较大
　　(ni) nice: CPU在高nice值(低优先级)用户态以低优先级运行占用的时间(nice>0)。默认新启动的进程nice=0，是不会计入这里的，除非手动经过renice或者setpriority()的方式修改程序的nice值
　　(id) idle: CPU在空闲状态(执行kernel idle handler)所占用的时间
　　(wa) iowait: 等待IO完成作占用的时间
　　(hi) irq: 系统处理硬件中断所消耗的时间
　　(si) softirq: 系统处理软中断所消耗的时间，记住软中断分为softirqs、tasklets(实际上是前者的特例)、work queues，不知道这里是统计的是哪些的时间，毕竟work queues的执行已经不是中断上下文了
　　(st) steal: 在虚拟机状况下才有意义，由于虚拟机下CPU也是共享物理CPU的，因此这段时间代表虚拟机等待hypervisor调度CPU的时间，也意味着这段时间hypervisor将CPU调度给别的CPU执行，这个时段的CPU资源被”stolen”了。这个值在我KVM的VPS机器上是不为0的，但也只有0.1这个数量级，是否是能够用来判断VPS超售的状况？
　　CPU占用率高不少状况下意味着一些东西，这也给服务器CPU使用率太高状况下指明了相应地排查思路：
　　(a) 当user占用率太高的时候，一般是某些个别的进程占用了大量的CPU，这时候很容易经过top找到该程序；此时若是怀疑程序异常，能够经过perf等思路找出热点调用函数来进一步排查；
　　(b) 当system占用率太高的时候，若是IO操做(包括终端IO)比较多，可能会形成这部分的CPU占用率高，好比在file server、database server等类型的服务器上，不然(好比>20%)极可能有些部分的内核、驱动模块有问题；
　　(c) 当nice占用率太高的时候，一般是有意行为，当进程的发起者知道某些进程占用较高的CPU，会设置其nice值确保不会淹没其余进程对CPU的使用请求；
　　(d) 当iowait占用率太高的时候，一般意味着某些程序的IO操做效率很低，或者IO对应设备的性能很低以致于读写操做须要很长的时间来完成；
　　(e) 当irq/softirq占用率太高的时候，极可能某些外设出现问题，致使产生大量的irq请求，这时候经过检查/proc/interrupts文件来深究问题所在；
　　(f) 当steal占用率太高的时候，黑心厂商虚拟机超售了吧！linux

　　第四行和第五行是物理内存和虚拟内存(交换分区)的信息:
　　total = free + used + buff/cache，如今buffers和cached Mem信息总和到一块儿了，可是buffers和cached
Mem的关系不少地方都没说清楚。其实经过对比数据，这两个值就是/proc/meminfo中的Buffers和Cached字段：Buffers是针对raw disk的块缓存，主要是以raw block的方式缓存文件系统的元数据(好比超级块信息等)，这个值通常比较小(20M左右)；而Cached是针对于某些具体的文件进行读缓存，以增长文件的访问效率而使用的，能够说是用于文件系统中文件缓存使用。
　　而avail Mem是一个新的参数值，用于指示在不进行交换的状况下，能够给新开启的程序多少内存空间，大体和free + buff/cached至关，而这也印证了上面的说法，free + buffers + cached Mem才是真正可用的物理内存。而且，使用交换分区不见得是坏事情，因此交换分区使用率不是什么严重的参数，可是频繁的swap in/out就不是好事情了，这种状况须要注意，一般表示物理内存紧缺的状况。ios

　　最后是每一个程序的资源占用列表，其中CPU的使用率是全部CPU core占用率的总和。一般执行top的时候，自己该程序会大量的读取/proc操做，因此基本该top程序自己也会是名列前茅的。
　　top虽然很是强大，可是一般用于控制台实时监测系统信息，不适合长时间(几天、几个月)监测系统的负载信息，同时对于短命的进程也会遗漏没法给出统计信息。缓存

1.2 vmstat

　　vmstat是除top以外另外一个经常使用的系统检测工具，下面截图是我用-j4编译boost的系统负载。

　　r表示可运行进程数目，数据大体相符；而b表示的是uninterruptible睡眠的进程数目；swpd表示使用到的虚拟内存数量，跟top-Swap-used的数值是一个含义，而如手册所说，一般状况下buffers数目要比cached Mem小的多，buffers通常20M这么个数量级；io域的bi、bo代表每秒钟向磁盘接收和发送的块数目(blocks/s)；system域的in代表每秒钟的系统中断数(包括时钟中断)，cs代表由于进程切换致使上下文切换的数目。
　　说到这里，想到之前不少人纠结编译linux kernel的时候-j参数到底是CPU Core仍是CPU Core+1？经过上面修改-j参数值编译boost和linux kernel的同时开启vmstat监控，发现两种状况下context switch基本没有变化，且也只有显著增长-j值后context switch才会有显著的增长，看来没必要过于纠结这个参数了，虽然具体编译时间长度我尚未测试。资料说若是不是在系统启动或者benchmark的状态，参数context switch>100000程序确定有问题。服务器

1.3 pidstat

　　若是想对某个进程进行全面具体的追踪，没有什么比pidstat更合适的了——栈空间、缺页状况、主被动切换等信息一览无余。这个命令最有用的参数是-t，能够将进程中各个线程的详细信息罗列出来。
　　-r：显示缺页错误和内存使用情况，缺页错误是程序须要访问映射在虚拟内存空间中可是还还没有被加载到物理内存中的一个分页，缺页错误两个主要类型是
　　(a). minflt/s 指的minor faults，当须要访问的物理页面由于某些缘由(好比共享页面、缓存机制等)已经存在于物理内存中了，只是在当前进程的页表中没有引用，MMU只须要设置对应的entry就能够了，这个代价是至关小的
　　(b). majflt/s 指的major faults，MMU须要在当前可用物理内存中申请一块空闲的物理页面(若是没有可用的空闲页面，则须要将别的物理页面切换到交换空间去以释放获得空闲物理页面)，而后从外部加载数据到该物理页面中，并设置好对应的entry，这个代价是至关高的，和前者有几个数据级的差别
　　-s：栈使用情况，包括StkSize为线程保留的栈空间，以及StkRef实际使用的栈空间。使用ulimit -s发现CentOS 6.x上面默认栈空间是10240K，而CentOS 7.x、Ubuntu系列默认栈空间大小为8196K

　　-u：CPU使用率状况，参数同前面相似
　　-w：线程上下文切换的数目，还细分为cswch/s由于等待资源等因素致使的主动切换，以及nvcswch/s线程CPU时间致使的被动切换的统计
　　若是每次都先ps获得程序的pid后再操做pidstat会显得很麻烦，因此这个杀手锏的-C能够指定某个字符串，而后Command中若是包含这个字符串，那么该程序的信息就会被打印统计出来，-l能够显示完整的程序名和参数
➜ ~ pidstat -w -t -C “ailaw” -l
　　这么看来，若是查看单个尤为是多线程的任务时候，pidstat比经常使用的ps更好使！网络

1.4 其余

　　当须要单独监测单个CPU状况的时候，除了htop还可使用mpstat，查看在SMP处理器上各个Core的工做量是否负载均衡，是否有某些热点线程占用Core。
➜ ~ mpstat -P ALL 1
　　若是想直接监测某个进程占用的资源，既可使用top -u taozj的方式过滤掉其余用户无关进程，也能够采用下面的方式进行选择，ps命令能够自定义须要打印的条目信息：多线程

1	while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm \| grep 'ailawd'; sleep 1; done

　　如想理清继承关系，下面一个经常使用的参数能够用于显示进程树结构，显示效果比pstree详细美观的多
➜ ~ ps axjfapp

2、磁盘IO类

　　iotop能够直观的显示各个进程、线程的磁盘读取实时速率；lsof不只能够显示普通文件的打开信息(使用者)，还能够操做/dev/sda1这类设备文件的打开信息，那么好比当分区没法umount的时候，就能够经过lsof找出磁盘该分区的使用状态了，并且添加+fg参数还能够额外显示文件打开flag标记。负载均衡

2.1 iostat

➜ ~ iostat -xz 1
　　其实不管使用iostat -xz 1仍是使用sar -d 1，对于磁盘重要的参数是：
　　avgqu-sz: 发送给设备I/O请求的等待队列平均长度，对于单个磁盘若是值>1代表设备饱和，对于多个磁盘阵列的逻辑磁盘状况除外；
　　await(r_await、w_await): 平均每次设备I/O请求操做的等待时间(ms)，包含请求排列在队列中和被服务的时间之和；
　　svctm: 发送给设备I/O请求的平均服务时间(ms)，若是svctm与await很接近，表示几乎没有I/O等待，磁盘性能很好，不然磁盘队列等待时间较长，磁盘响应较差；
　　%util: 设备的使用率，代表每秒中用于I/O工做时间的占比，单个磁盘当%util>60%的时候性能就会降低(体如今await也会增长)，当接近100%时候就设备饱和了，但对于有多个磁盘阵列的逻辑磁盘状况除外；
　　还有，虽然监测到的磁盘性能比较差，可是不必定会对应用程序的响应形成影响，内核一般使用I/O asynchronously技术，使用读写缓存技术来改善性能，不过这又跟上面的物理内存的限制相制约了。
　　上面的这些参数，对网络文件系统也是受用的。

3、网络类

　　网络性能对于服务器的重要性不言而喻，工具iptraf能够直观的现实网卡的收发速度信息，比较的简洁方便经过sar -n DEV 1也能够获得相似的吞吐量信息，而网卡都标配了最大速率信息，好比百兆网卡千兆网卡，很容易查看设备的利用率。
　　一般，网卡的传输速率并非网络开发中最为关切的，而是针对特定的UDP、TCP链接的丢包率、重传率，以及网络延时等信息。

3.1 netstat

➜ ~ netstat -s
　　显示自从系统启动以来，各个协议的整体数据信息。虽然参数信息比较丰富有用，可是累计值，除非两次运行作差才能得出当前系统的网络状态信息，亦或者使用watch眼睛直观其数值变化趋势。因此netstat一般用来检测端口和链接信息的：

netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)

　　–timers能够取消域名反向查询，加快显示速度；比较经常使用的有

1 2	➜ ~ netstat -antp #列出全部TCP的链接 ➜ ~ netstat -nltp #列出本地全部TCP侦听套接字，不要加-a参数

3.2 sar

　　sar这个工具太强大了，什么CPU、磁盘、页面交换啥都管，这里使用-n主要用来分析网络活动，虽然网络中它还给细分了NFS、IP、ICMP、SOCK等各类层次各类协议的数据信息，咱们只关心TCP和UDP。下面的命令除了显示常规状况下段、数据报的收发状况，还包括
　　TCP
　　➜ ~ sudo sar -n TCP,ETCP 1

　　active/s：本地发起的TCP链接，好比经过connect()，TCP的状态从CLOSED -> SYN-SENT
　　passive/s：由远程发起的TCP链接，好比经过accept()，TCP的状态从LISTEN -> SYN-RCVD
　　retrans/s(tcpRetransSegs)：每秒钟TCP重传数目，一般在网络质量差，或者服务器过载后丢包的状况下，根据TCP的确认重传机制会发生重传操做
　　isegerr/s(tcpInErrs)：每秒钟接收到出错的数据包(好比checksum失败)
　　UDP
　　➜ ~ sudo sar -n UDP 1
　　noport/s(udpNoPorts)：每秒钟接收到的可是却没有应用程序在指定目的端口的数据报个数
　　idgmerr/s(udpInErrors)：除了上面缘由以外的本机接收到但却没法派发的数据报个数
　　固然，这些数据必定程度上能够说明网络可靠性，但也只有同具体的业务需求场景结合起来才具备意义。

3.3 tcpdump

　　tcpdump不得不说是个好东西。你们都知道本地调试的时候喜欢使用wireshark，可是线上服务端出现问题怎么弄呢？附录的参考文献给出了思路：复原环境，使用tcpdump进行抓包，当问题复现(好比日志显示或者某个状态显现)的时候，就能够结束抓包了，并且tcpdump自己带有-C/-W参数，能够限制抓取包存储文件的大小，当达到这个这个限制的时候保存的包数据自动rotate，因此抓包数量整体仍是可控的。此后将数据包拿下线来，用wireshark想怎么看就怎么看，岂不乐哉！tcpdump虽然没有GUI界面，可是抓包的功能丝绝不弱，能够指定网卡、主机、端口、协议等各项过滤参数，抓下来的包完整又带有时间戳，因此线上程序的数据包分析也能够这么简单。
　　下面就是一个小的测试，可见Chrome启动时候自动向Webserver发起创建了三条链接，因为这里限制了dst port参数，因此服务端的应答包被过滤掉了，拿下来用wireshark打开，SYNC、ACK创建链接的过程仍是很明显的！在使用tcpdump的时候，须要尽量的配置抓取的过滤条件，一方面便于接下来的分析，二则tcpdump开启后对网卡和系统的性能会有影响，进而会影响到在线业务的性能。

本文完！

参考

本文标题:Linux服务器的那些性能参数指标

最后更新:2017-01-04, 22:41:16

原始连接:https://taozj.org/201701/linux-performance-basic.html

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文连接及做者。