linux性能优化分析性能问题的一般步骤

Posted 2021-07-30 sysu_lluozh

如果收到监控系统的告警，发现系统资源或者应用程序出现性能瓶颈，又该如何进一步分析它的根源呢？

接下来分别从系统资源瓶颈和应用程序瓶颈这两个角度，看看性能分析的一般步骤

一、系统资源瓶颈

首先来看系统资源的瓶颈，这也是最为常见的性能问题

1.1 系统资源的瓶颈的衡量

系统资源的瓶颈可以通过USE法，即使用率、饱和度以及错误数这三类指标来衡量

1.2 系统的资源的分类

系统的资源，可以分为硬件资源和软件资源两类：

• 硬件资源

CPU、内存、磁盘和文件系统以及网络等，都是最常见的硬件资源

• 软件资源

文件描述符数、连接跟踪数、套接字缓冲区大小等，则是典型的软件资源

这样，在收到监控系统告警时可以对照这些资源列表，再根据指标的不同来进行定位

1.3 瓶颈分析思路

前面CPU 性能、内存性能、磁盘和文件系统I/O性能以及网络性能四大模块的核心，正是学会去分析这些资源瓶颈导致的性能问题。所以，当碰到系统资源的性能瓶颈时，前面模块的所有思路、方法以及工具都完全可以照用

接下来，从CPU 性能、内存性能、磁盘和文件系统I/O性能以及网络性能等四个方面，回顾一下它们的分析步骤

二、CPU性能分析

第一种最常见的系统资源是 CPU

关于 CPU 的性能分析方法，在【linux性能优化】分析系统CPU瓶颈中，整理了如何迅速分析CPU性能瓶颈的思路

利用top、vmstat、pidstat、strace以及perf等几个最常见的工具，获取CPU性能指标后再结合进程与CPU的工作原理，迅速定位出CPU性能瓶颈的来源

实际上，top、pidstat、vmstat这类工具所汇报的CPU性能指标，都源自/proc文件系统(比如/proc/loadavg、/proc/stat、/proc/softirqs等)
这些指标都需要通过监控系统监控起来，虽然并非所有指标都需要报警，但这些指标却可以加快性能问题的定位分析

比如说，当收到系统的用户CPU使用率过高告警时，从监控系统中直接查询到导致CPU使用率过高的进程，然后再登录到进程所在的Linux服务器中分析该进程的行为
可以使用strace查看进程的系统调用汇总，也可以使用perf等工具找出进程的热点函数，甚至还可以使用动态追踪的方法来观察进程的当前执行过程，直到确定瓶颈的根源

三、内存性能分析

说完了CPU的性能分析，再来看看第二种系统资源，即内存

关于内存性能的分析方法，在【linux性能优化】如何定位系统内存的问题中，整理了如何快速分析的思路

下面这张图，就是一个迅速定位内存瓶颈的流程
可以通过free和vmstat输出的性能指标，确认内存瓶颈，然后再根据内存问题的类型，进一步分析内存的使用、分配、泄漏以及缓存等，最后找出问题的来源

同CPU性能一样，很多内存的性能指标也来源于/proc文件系统(比如/proc/meminfo、/proc/slabinfo等)
这些都应该通过监控系统监控起来，这样当收到内存告警时就可以从监控系统中直接得到上图中的各项性能指标，从而加快性能问题的定位过程

比如当收到内存不足的告警时：

1. 首先可以从监控系统中找出占用内存最多的几个进程
2. 然后再根据这些进程的内存占用历史观察是否存在内存泄漏问题
3. 确定出最可疑的进程后，再登录到进程所在的Linux服务器中分析该进程的内存空间或者内存分配
4. 最后弄清楚进程为什么会占用大量内存

三、磁盘和文件系统I/O性能分析

接下来，再来看第三种系统资源，即磁盘和文件系统的I/O

关于磁盘和文件系统的I/O性能分析方法，在【linux性能优化】如何分析系统I/O瓶颈中整理了快速分析的思路

来看下面这张图，当你使用iostat发现磁盘I/O存在性能瓶颈(比如I/O使用率过高、响应时间过长或者等待队列长度突然增大等)后，可以再通过pidstat、vmstat等确认I/O的来源。接着再根据来源的不同，进一步分析文件系统和磁盘的使用率、缓存以及进程的I/O等，从而揪出I/O问题的真凶

同CPU和内存性能类似，很多磁盘和文件系统的性能指标也来源于/proc和/sys文件系统(比如 /proc/diskstats、/sys/block/sda/stat等)
自然，它们也应该通过监控系统监控起来。这样，当收到I/O性能告警时，就可以从监控系统中直接得到上图中的各项性能指标，从而加快性能定位的过程

比如当发现某块磁盘的I/O使用率为100%时：

1. 首先可以从监控系统中找出I/O最多的进程
2. 然后再登录到进程所在的Linux服务器中，借助strace、lsof、perf等工具分析该进程的I/O行为
3. 最后再结合应用程序的原理，找出大量I/O的原因

四、网络性能分析

最后的网络性能，其实包含两类资源，即网络接口和内核资源

在【linux性能优化】网络性能优化的思路中，提及网络性能的分析要从Linux网络协议栈的原理来切入。下面这张图就是Linux网络协议栈的基本原理，包括应用层、套机字接口、传输层、网络层以及链路层等

而要分析网络的性能，自然也是要从这几个协议层入手，通过使用率、饱和度以及错误数这几类性能指标，观察是否存在性能问题。比如 ：

• 在链路层，可以从网络接口的吞吐量、丢包、错误以及软中断和网络功能卸载等角度分析
• 在网络层，可以从路由、分片、叠加网络等角度进行分析
• 在传输层，可以从TCP、UDP的协议原理出发，从连接数、吞吐量、延迟、重传等角度进行分析
• 在应用层，可以从应用层协议(如HTTP和DNS)、请求数(QPS)、套接字缓存等角度进行分析

同前面几种资源类似，网络的性能指标也都来源于内核，包括/proc文件系统(如/proc/net)、网络接口以及conntrack等内核模块

这些指标同样需要被监控系统监控，当收到网络告警时，就可以从监控系统中查询这些协议层的各项性能指标，从而更快定位出性能问题

比如，当收到网络不通的告警时：

1. 首先从监控系统中，查找各个协议层的丢包指标，确认丢包所在的协议层
2. 然后从监控系统的数据中，确认网络带宽、缓冲区、连接跟踪数等软硬件是否存在性能瓶颈
3. 最后再登录到发生问题的Linux服务器中，借助netstat、tcpdump、bcc等工具分析网络的收发数据，并且结合内核中的网络选项以及TCP等网络协议的原理，找出问题的来源

五、应用程序瓶颈

除了以上这些来自网络资源的瓶颈外，还有很多瓶颈，其实直接来自应用程序
比如，最典型的应用程序性能问题，就是吞吐量(并发请求数)下降、错误率升高以及响应时间增大

不过，应用程序性能问题虽然各种各样，但就其本质来源实际上只有三种，也就是资源瓶颈、依赖服务瓶颈以及应用自身的瓶颈

• 资源瓶颈

第一种资源瓶颈，其实还是指刚才提到的CPU、内存、磁盘和文件系统I/O、网络以及内核资源等各类软硬件资源出现了瓶颈，从而导致应用程序的运行受限
对于这种情况，可以用前面系统资源瓶颈模块提到的各种方法来分析

• 依赖服务的瓶颈

第二种依赖服务的瓶颈，也就是诸如数据库、分布式缓存、中间件等应用程序，直接或者间接调用的服务出现了性能问题，从而导致应用程序的响应变慢，或者错误率升高
这说白了就是跨应用的性能问题，使用全链路跟踪系统可以快速定位这类问题的根源

• 应用程序自身的性能问题

第三种应用程序自身的性能问题，包括了多线程处理不当、死锁、业务算法的复杂度过高等等
对于这类问题，在应用程序指标监控以及日志监控中，观察关键环节的耗时和内部执行过程中的错误，可以缩小问题的范围

不过，由于这是应用程序内部的状态，外部通常不能直接获取详细的性能数据，所以就需要应用程序在设计和开发时就提供出这些指标，以便监控系统可以了解应用程序的内部运行状态

如果这些手段过后还是无法找出瓶颈，可以用系统资源模块提到的各类进程分析工具来进行分析定位。比如：

• 可以使用strace观察系统调用
• 可以使用perf和火焰图分析热点函数
• 可以使用动态追踪技术来分析进程的执行状态

当然，系统资源和应用程序本来就是相互影响、相辅相成的一个整体
实际上，很多资源瓶颈也是应用程序自身运行导致的。比如：

• 进程的内存泄漏会导致系统内存不足
• 进程过多的I/O请求会拖慢整个系统的I/O请求等

所以，很多情况下资源瓶颈和应用自身瓶颈，其实都是同一个问题导致的，并不需要重复分析

六、小结

从系统资源瓶颈和应用程序瓶颈这两个角度，梳理了性能问题分析的一般步骤

从系统资源瓶颈的角度来说，USE法是最为有效的方法，即从使用率、饱和度以及错误数这
三个方面来分析CPU、内存、磁盘和文件系统I/O、网络以及内核资源限制等各类软硬件资源。关于这些资源的分析方法，一起回顾了前面几大模块的分析套路

从应用程序瓶颈的角度来说，可以把性能问题的来源分为资源瓶颈、依赖服务瓶颈以及应用自身瓶颈这三类

1. 资源瓶颈跟系统资源瓶颈本质是一样的
2. 依赖服务瓶颈可以使用全链路跟踪系统进行定位
3. 应用自身的问题可以通过系统调用、热点函数或者应用自身的指标监控以及日志监控等进行分析定位

值得注意的是，虽然把瓶颈分为了系统和应用两个角度，但在实际运行时这两者往往是相辅相成、相互影响的
系统是应用的运行环境，系统的瓶颈会导致应用的性能下降，而应用的不合理设计也会引发系统资源的瓶颈。做性能分析就是要结合应用程序和操作系统的原理，揪出引发问题的真凶