Linux性能优化

发布时间：2023-02-20 10:14:08 所属栏目：Linux 来源：互联网

导读：高并发和响应快对应着性能优化的两个核心指标：吞吐和延时。应用负载角度：直接影响了产品终端的用户体验系统资源角度：资源使用率、饱和度等性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出

　　14时51分21秒     0      1332      0.20      0.00 argusagent
　　14时51分21秒     0      5265     10.02      0.00 AliSecGuard
　　14时51分21秒     0      7439      7.82      0.00 kworker/0:2
　　14时51分21秒     0      7906      0.20      0.00 pidstat
　　14时51分21秒     0      8346      0.20      0.00 sshd
　　14时51分21秒     0     20654      9.82      0.00 AliYunDun
　　14时51分21秒     0     25766      0.20      0.00 kworker/u2:1
　　14时51分21秒     0     28603      1.00      0.00 python3
　　cswch 每秒自愿上下文切换次数（进程无法获取所需资源导致的上下文切换）

　　nvcswch 每秒非自愿上下文切换次数（时间片轮流等系统强制调度）

　　vmstat 1 1    #首先获取空闲系统的上下文切换次数
　　sysbench --threads=10 --max-time=300 threads run #模拟多线程切换问题
　　vmstat 1 1    #新终端观察上下文切换情况
　　此时发现cs数据明显升高，同时观察其他指标：
　　r列：远超系统cpu个数，说明存在大量cpu竞争
　　us和sy列：sy列占比80%，说明cpu主要被内核占用
　　in列：中断次数明显上升，说明中断处理也是潜在问题
　　说明运行/等待cpu的进程过多，导致大量的上下文切换，上下文切换导致系统的cpu占用率高：

　　pidstat -w -u 1 #查看到底哪个进程导致的问题
　　从结果中看出是sysbench导致cpu使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。

　　另外对于中断次数过多，我们可以通过/proc/interrupts文件读取：

　　watch -d cat /proc/interrupts
　　发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的cpu来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。

　　某个应用的cpu使用率达到100%，怎么办？
　　Linux作为多任务操作系统，将cpu时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护cpu时间，Linux通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以来的节拍数。时间中断发生一次该值+1.

　　cpu使用率，除了空闲时间以外的其他时间占总cpu时间的百分比。可以通过/proc/stat中的数据来计算出cpu使用率。因为/proc/stat时开机以来的节拍数累加值，计算出来的是开机以来的平均cpu使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均cpu使用率。性能分析工具给出的都是间隔一段时间的平均cpu使用率，要注意间隔时间的设置。

　　cpu使用率可以通过top 或 ps来查看。分析进程的cpu问题可以通过perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

　　perf top / perf record / perf report （-g 开启调用关系的采样）

　　sudo docker run --name Nginx -p 10000:80 -itd feisky/Nginx
　　sudo docker run --name PHPfpm -itd --network container:Nginx feisky/PHP-fpm
　　ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能
　　发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个cpu的使用率。发现系统中几个PHP-fpm进程导致cpu使用率骤升。

　　接着用perf来分析具体是PHP-fpm中哪个函数导致该问题。

　　perf top -g -p XXXX #对某一个PHP-fpm进程进行分析
　　发现其中sqrt和add_function占用cpu过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现Nginx负载能力明显提升

　　系统的cpu使用率很高，为什么找不到高cpu的应用？
　　sudo docker run --name Nginx -p 10000:80 -itd feisky/Nginx:sp
　　sudo docker run --name PHPfpm -itd --network container:Nginx feisky/PHP-fpm:sp
　　ab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试
　　实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，Nginx负载能力依旧很低。

　　此时用top和pidstat发现系统cpu使用率过高，但是并没有发现cpu使用率高的进程。

　　出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5. 再仔细查看进程运行数据，发现Nginx和PHP-fpm都处于sleep状态，真正处于运行的却是几个stress进程。

　　下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用ps aux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现stress进程的进程号变化了，此时有可能时以下两种原因导致：

　　进程不停的崩溃重启（如段错误/配置错误等），此时进程退出后可能又被监控系统重启；

　　短时进程导致，即其他应用内部通过exec调用的外面命令，这些命令一般只运行很短时间就结束，很难用top这种间隔较长的工具来发现

　　可以通过pstree来查找 stress的父进程，找出调用关系。

　　pstree | grep stress
　　发现是PHP-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟I/O压力。之前top显示的结果是cpu使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。

　　此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的cpu，通过修复权限问题来优化解决即可。

　　系统中出现大量不可中断进程和僵尸进程怎么办？
　　进程状态

　　R Running/Runnable，表示进程在cpu的就绪队列中，正在运行或者等待运行；

　　D disk Sleep，不可中断状态睡眠，一般表示进程正在跟硬件交互，并且交互过程中不允许被其他进程中断；

　　Z Zombie，僵尸进程，表示进程实际上已经结束，但是父进程还没有回收它的资源；

　　S Interruptible Sleep，可中断睡眠状态，表示进程因为等待某个事件而被系统挂起，当等待事件发生则会被唤醒并进入R状态；

　　I Idle，空闲状态，用在不可中断睡眠的内核线程上。该状态不会导致平均负载升高；

　　T Stop/Traced，表示进程处于暂停或跟踪状态（SIGSTOP/SIGCONT， GDB调试）；

　　X Dead，进程已经消亡，不会在top/ps中看到。

　　对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了I/O性能问题。

　　僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。

　　磁盘O_DIRECT问题：

　　sudo docker run --privileged --name=app -itd feisky/app:iowait
　　ps aux | grep '/app'
　　可以看到此时有多个app进程运行，状态分别时Ss+和D+。其中后面s表示进程是一个会话的领导进程，+号表示前台进程组。

　　其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。

　　用top查看系统资源发现：1）平均负载在逐渐增加，且1分钟内平均负载达到了cpu个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us和sys cpu使用率都不高，iowait却比较高；4）每个进程cpu使用率也不高，但有两个进程处于D状态，可能在等待IO。

　　分析目前数据可知：iowait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。

（编辑：莱芜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

2/7

首页

尾页