当前位置: 首页 > 科技观察

最详尽的Linux服务器性能参数索引

时间:2023-03-20 15:20:19 科技观察

一台基于Linux操作系统的服务器在运行时,也会代表各种参数信息。一般来说,运维人员和系统管理员会对这些数据极为敏感,但是这些参数对于开发人员来说也是非常重要的,尤其是当你的程序运行不正常时,这些线索往往会帮助快速定位和跟踪问题。这里只是提供一些简单的工具来检查系统的相关参数。当然,很多工具也是通过对/proc和/sys下的数据进行分析处理来工作的,而那些更细致、更专业的性能监控和调优可能需要更专业的工具(perf、systemtap等)和技术才能完成。毕竟系统性能监控本身就是一个大问题。1.CPU和内存类别1.1top~top第一行后面的三个值分别是1、5、15之前系统的平均负载,也可以看出系统负载在上升、稳定、下降.当这个值超过CPU的可执行单元数时,说明CPU的性能已经饱和,成为瓶颈。第二行统计了系统的任务状态信息。运行自然不用多说,包括那些运行在CPU上,会被调度运行的;sleeping通常是等待事件(如IO操作)完成的任务,细分可以包括可中断和不可中断类型;stopped是一些被挂起的任务,一般是在前台任务上发送SIGSTOP或操作Ctrl-Z来挂起它;zombie僵尸任务,虽然进程终止资源会自动回收,但是包含退出任务的任务描述符需要被父进程访问后才能被释放。它显示为已失效状态。不管是因为父进程提前退出,还是没有被wait调用,当出现这样的进程时,要特别注意是不是程序设计有误。第三行的CPU使用率按照类型有以下几种:(us)user:CPU处于用户态的nice值低(高优先级)(nice<=0)的时间。一般情况下,只要服务器不是很空闲,大部分的CPU时间应该都在这里执行。(sy)system:CPU在内核态所占用的时间,操作系统通过系统调用(systemcall)从用户态降到内核态,去执行特定的服务;通常这个值会比较小,但是当服务器进行密集IO时,这个值会比较大(ni)nice:CPU在highnicevalue(lowpriority)users状态下以低优先级(nice)运行所花费的时间>0).默认情况下,这里不会统计新启动的进程nice=0,除非通过renice或setpriority()手动修改了程序的nice值(id)idle:CPU处于空闲状态(执行kernelidlehandler)(wa)iowait:等待IO完成的时间(hi)irq:系统处理硬件中断所消耗的时间(si)softirq:系统处理软中断所消耗的时间,记住软中断是分为softirqs和tasklets(其实是前者的特例),workqueues,这里不知道算什么时间,毕竟workqueues的执行不再是interruptcontext(st)steal:it只有在虚拟机的情况下才有意义,因为虚拟机下的CPU也是物理CPU共享的,所以这段时间表示虚拟机等待hypervisor调度CPU,也代表hypervisor调度CPU到其他CPU这段时间执行,这段时间的CPU资源被“偷走”了。这个值在我的KVMVPS机器上不是0,而是大约0.1。可以用来判断VPS超售的情况吗?CPU占用率高往往是有什么意义的,这也会影响到服务器当CPU占用率过高时,给出相应的排查思路:(a)当用户占用率过高时,通常是某些个别进程占用较多中央处理器。这时候通过top很容易找到程序;如果怀疑程序异常,可以使用perf等思路寻找热调用函数做进一步排查;(b)当系统占用率过高时,如果IO操作较多(包括终端IO),可能会导致这部分CPU占用率高,比如在文件服务器、数据库服务器等类型的服务器上,否则(例如>20%),可能是某些内核和驱动模块有问题;(c)当nice占用率过高时,通常是有意为之的行为,当进程的发起者知道某些进程占用了很高的CPU时,会设置它的nice值,以保证不会压垮CPU使用请求其他过程;(d)当iowait占用率过高时,通常表示某些程序的IO操作效率很低,或者IO对应设备的性能太低导致读写操作需要很长时间才能完成;(e)当irq/softirq占用率过高时,很可能是某些外部假设出现了问题,导致大量的irq请求。这时候查看/proc/interrupts文件,找出问题所在;(f)当盗用率过高时,无良厂商的虚拟机超卖!第四行和第五行是物理内存和虚拟内存(交换分区)的信息:total=free+used+buff/cache。现在buffer和cachedMem的信息都加在一起了,但是很多地方buffer和cachedMem的关系并不清楚。其实通过数据对比,这两个值就是/proc/meminfo中的Buffers和Cached字段:Buffers是原始磁盘的块缓存,主要缓存文件系统的元数据(如superblock信息等).)在原始块的形式下,这个值一般比较小(20M左右);Cached用于读取和缓存某些特定的文件,以提高文件访问效率。可以说是用于文件系统中的文件缓存。而availMem是一个新的参数值,用来表示在不swapping的情况下,可以给新打开的程序多少内存空间,大致相当于free+buff/cached,这也印证了上面的说法,free+buffers+cachedMem是真正可用的物理内存。而且,使用swap分区不一定是坏事,所以swap分区的使用率不是一个很重要的参数,但是频繁的swapin/out也不是什么好事。这种情况需要注意,通常表示物理内存不足。最后是每个程序的资源使用列表,其中CPU使用是所有CPU内核使用的总和。通常在执行top时,程序本身会读取大量的/proc操作,所以基本上top程序本身也会名列前茅。top虽然功能很强大,但通常用于在控制台实时监控系统信息。不适用于系统负载信息的长期(天、月)监控。同时,它会错过短暂的进程,无法给出统计信息。1.2vmstatvmstat是top之外的另一个常用的系统检测工具。下面截图是我用-j4编译的boost的系统负载。r表示可运行进程数,数据大致一致;b表示不可中断的休眠进程数;swpd表示使用的虚拟内存量,与top-Swap-used的值意义相同,如手册中所说,通常情况下,buffer数量远小于cachedMem,buffers一般在20M量级;io域中的bi和bo表示每秒接收和发送到磁盘的块数(blocks/s);在系统域中,表示每秒块时钟系统中断(包括时钟中断)的次数,cs表示进程切换引起的上下文切换次数。说到这里,我想到很多人在编译linux内核的时候纠结,-j参数到底是CPUCore还是CPUCore+1?修改上面的-j参数值编译boost和linux内核,同时开启vmstat监控,发现有两种情况上下文切换基本不变,只有-j后上下文切换才会明显增加价值显着增加。好像没必要太纠结这个参数,虽然我没有测试具体的编译时间。根据资料,如果不是在系统启动或者benchmark的状态,肯定是参数contextswitch>100000的程序有问题。1.3pidstat如果你想全面而具体地跟踪一个进程,没有什么比pidstat更合适——你可以将堆栈空间、页面错误、主动和被动切换等信息尽收眼底。这个命令最有用的参数是-t,它可以列出进程中每个线程的详细信息。-r:显示页面错误和内存使用情况。页面错误是程序需要访问的页面映射在虚拟内存空间但尚未加载到物理内存。页面错误的两种主要类型是(a)。minflt/s指的是小故障。当需要访问的物理页由于某些原因(如共享页、缓存机制等)已经存在于物理内存中,但在当前进程的页表中没有被引用时,MMU只需要设置对应的entry就可以了,这个开销挺小的(b)。majflt/s指majorfaults,MMU需要在当前可用的物理内存中申请一个freephysicalpage(如果没有可用的freepage,需要将其他物理page切换到swapspace释放freephysicalpages),然后从外部加载数据到物理页,并设置相应的entry,这个开销比较大,前者有几个数据层级区别-s:堆栈使用情况,包括StkSize为线程预留的堆栈空间,以及StkRef实际使用的堆栈空间。使用ulimit-s发现CentOS6.x默认栈空间大小为10240K,而CentOS7.x和Ubuntu系列默认栈空间大小为8196K,也细分为cswch/s等因素导致的主动切换如等待资源,统计nvcswch/s线程CPU时间造成的被动切换。所以杀手级特性-C可以指定某个字符串,如果命令中包含这个字符串,就会打印并统计程序的信息,-l可以显示完整的程序名和参数~pidstat-w-t-C"ailaw"-l从这点来看,如果单看单线程,尤其是多线程任务,pidstat比常用的ps要好!1.4其他当需要单独监控单个CPU时,除了htop之外,还可以使用mpstat查看SMP处理器上各个Core的工作负载是否负载均衡,是否有一些热点线程占用了Core。~mpstat-PALL1如果想直接监控某个进程占用的资源,可以使用top-utaozj过滤掉其他不相关的用户进程,也可以使用下面的方法进行选择。ps命令可以自定义需要打印的入口信息:while:;dops-eouser,pid,ni,pri,pcpu,psr,comm|grep'ilawd';睡眠1;done如果想理清继承关系,可以使用以下常用参数来展示进程树结构和显示效果比pstree更详细漂亮~psaxjf2.磁盘IO类iotop可以直观的显示实时磁盘读取速度每个进程和线程;lsof不仅可以显示普通文件的打开信息(user),还可以操作/dev/sda1这类设备文件的打开信息,比如分区不能umount时,可以使用lsof查看使用情况磁盘分区的状态,加上+fg参数可以额外显示文件打开标志。2.1iostat~iostat-xz1其实无论你使用iostat-xz1还是sar-d1,磁盘的重要参数是:avgqu-sz:发送到设备I/O请求的等待队列的平均长度,对于单个磁盘,如果该值>1,则表示设备已饱和,但多个磁盘阵列的逻辑磁盘除外;await(r_await,w_await):每次设备I/O请求操作的平均等待时间(ms),包括请求排队和服务时的总和;svctm:发送到设备的I/O请求的平均服务时间(毫秒)。如果svctm非常接近await,说明几乎没有I/O等待,磁盘性能很好。否则,磁盘队列等待时间长,磁盘响应差;%util:设备的使用率,表示每秒I/O工作时间的比例。当%util>单个磁盘的60%时,性能会下降(体现为await也会增加),当接近100%时,设备饱和,逻辑磁盘多磁盘阵列除外;另外,虽然被监控的磁盘性能比较差,但并不一定会影响应用程序的响应。内核通常使用I/O异步技术,使用读写缓存技术来提高性能,但这受限于上述物理内存的限制。上述参数对于网络文件系统也很有用。3、网络性能对服务器的重要性不言而喻。iptraf这个工具可以直观的显示网卡的收发速度信息,比较简单方便。通过sar-nDEV1也可以得到类似的吞吐量信息,网卡是标配最大速率信息的,比如100M网卡和千兆网卡,方便查看网卡的利用率设备。通常,网络开发中最关心的不是网卡的传输速率,而是针对特定UDP和TCP连接的丢包率、重传率、网络延迟等。3.1netstat~netstat-s显示系统启动以来各协议的总体数据信息。虽然参数信息比较丰富有用,但是累计值只能从当前系统的网络状态信息中获取,除非运行两次,否则可以用手表直观地看到数值变化趋势。所以通常使用netstat检测端口和连接信息:netstat–all(a)–numeric(n)–tcp(t)–udp(u)–timers(o)–listening(l)–program(p)–timers可以取消域名反向查询,加快显示速度;比较常用的有~netstat-antp#列出所有TCP连接netstat-nltp#列出所有本地TCP监听套接字,不要加-a参数3.2sarsar这个工具太强大了,不关心CPU,磁盘,和页面交换。这里使用-n主要是用来分析网络活动,虽然它也细分了网络中的NFS、IP、ICMP、SOCK等各种协议层。对于数据信息,我们只关心TCP和UDP。下面的命令除了显示正常情况下的报文段和数据报的发送和接收,还有TCP~sudosar-nTCP,ETCP1active/s:本地发起的TCP连接,比如通过connect(),TCP的状态由CLOSED变为->SYN-SENTpassive/s:remote发起的TCP连接,比如通过accept(),TCP的状态从LISTEN变化->SYN-RCVDretrans/s(tcpRetransSegs):每秒TCP重传次数,通常在之后丢失网络质量差或服务器过载的情况下,会根据TCP确认重传机制进行重传操作。idgmerr/s(udpInErrors):本地机器收到但由于上述以外原因无法发送的数据报数。当然,这些数据一定程度上能够说明网络的可靠性,但只有结合具体的业务需求场景才有意义。3.3tcpdumptcpdump不得不说是个好东西。我们都知道我们喜欢使用wireshark进行本地调试,但是线上服务器出现问题怎么办呢?附录中的参考给出了思路:恢复环境,使用tcpdump抓包,当问题再次出现时(比如日志显示或者某个状态出现时),就可以结束抓包了,tcpdump本身有-C/-W参数,可以限制抓包存储文件的大小。当达到此限制时,保存的数据包数据将自动轮换。因此,抓包的总体数量还是可控的。之后,将数据包离线,然后使用wireshark随意查看。岂不妙哉!tcpdump虽然没有GUI界面,但是抓包的功能一点都不弱。可以指定网卡、主机、端口、协议等过滤参数,抓包完整,有时间戳,在线程序的数据包分析也可以这么简单。下面是一个小测试。可以看到,Chrome在启动的时候,自动发起了三个到Webserver的连接。由于这里限制dst端口参数,过滤掉服务器的响应包,用wireshark打开。SYNC和ACK建立连接的过程还是很明显的!在使用tcpdump的时候,需要尽可能的配置抓包的过滤条件。一方面方便接下来的分析,另一方面tcpdump开启后会影响网卡和系统的性能,进而影响线上业务的性能。本文结束!