Linux性能优化大全.docx

《Linux性能优化大全.docx》由会员分享，可在线阅读，更多相关《Linux性能优化大全.docx（43页珍藏版）》请在第一文库网上搜索。

1、1inux性能优化大全性能优化性能指标高并发和响应快对应着性能优化的两个核心指标：吞吐和延时国B耀落油(0Ha1,J3)App1ications1ibrariesSystemCa11opu3瑞)1inuxKerne1Device应用负载角度：直接影响了产品终端的用户体验系统资源角度：资源使用率、饱和度等性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。 选择指标评估应用程序和系统性能 为应用程序和系统设置性能目标 进行性能基准测试 性能分析定位瓶颈 性能监控和告警对于不同的性能问题要选取不同的性能分析

2、工具。下面是常用的1inUXPerformanceToo1s以及对应分析的性能问题类型。到底应该怎么理解“平均负载”平均负载：单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。它和我们传统意义上理解的CPU使用率并没有直接关系。其中不可中断进程是正处于内核态关键流程中的进程（如常见的等待设备的I/O响应）。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。平均负载多少时合理实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。当然也可以当设置阈值（如当平均负载高于CPU数量的70%时）现实工作中

3、我们会经常混淆平均负载和CPU使用率的概念，其实两者并不完全对等： CPU密集型进程，大量CPU使用会导致平均负载升高，此时两者一致 I/O密集型进程，等待I/O也会导致平均负载升高，此时CPU使用率并不一定高 大量等待CPU的进程调度会导致平均负载升高，此时CPU使用率也会比较高平均负载高时可能是CPU密集型进程导致，也可能是I/O繁忙导致。具体分析时可以结合mpstat/pidstat工具辅助分析负载来源。CPUCPU上下文切换（上）CPU上下文切换，就是把前一个任务的CPU上下文（CPU寄存器和PC）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位

4、置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。按照任务类型，CPU上下文切换分为： 进程上下文切换 线程上下文切换中断上下文切换进程上下文切换1inux进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。一次系统调用过程其实进行了两次CPU上下文切换： CPU寄存器中用户态的指令位置先保存起来，CPU寄存器更新为内核态指令的位置，跳转到内核态运行内核任务； 系统调用结束后，CPU寄存器恢复原来保存的用户态数据，再切换到用户空间继续运行。系统调用过程中并不会涉及虚拟内存等进程用户

5、态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。进程只有在调度到CPU上运行时才需要切换上下文，有以下几种场景：CPU时间片轮流分配，系统资源不足导致进程挂起，进程通过SIeeP函数主动挂起，高优先级进程抢占时间片，硬件中断时CPU上的进程被挂起转而执行内核中的中断服务。线程上下文切换线程上下文切换分为两种： 前后线程同属于一个进程，切

6、换时虚拟内存资源不变，只需要切换线程的私有数据，寄存器等； 前后线程属于不同进程，与进程上下文切换相同。同进程的线程切换消耗资源较少，这也是多线程的优势。中断上下文切换中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态（CPu寄存器，内核堆栈，硬件中断参数等）。中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生CPiJ上下文切换（下）通过vmstat可以查看系统总体的上下文切换情况vmstat5#每隔5s输出一组数据PrOCSmemoryswap10-systemcpurbswpdfreebuffcachesisobiboincsu

7、ssyidwast1OO103388M5412511056OO186012196OOOOO103388145412511076245011761199OOOO103388145412511076429113598OOOO103388145412511076431113298OOOO1033881454125110761046711951198OO1OO10338814541251107642611391O99O9518414541251110874500122894OOOOO103512145416511076455723157312383CS(contextswitch)每秒上下文切换次数i

8、n(interrupt)每秒中断次数正在运行和等待CPU的(runnningorrunnab1e)就绪队列的长度,进程数b(B1ocked)处于不可中断睡眠状态的进程数要查看每个进程的详细情况，需要使用Pidstat来查看每个进程上下文切换情PIDcswchsnvcswch/spidstat-W514时51分16秒UIDCommandM时51分21秒0.800.00systemd14时51分21秒061.400.00ksoftirqd/014时51分21秒0932.670.00rcu_sched14时51分21秒0110.400.00watchdog/014时51分21秒0320.200.00

9、khugepaged14时51分21秒02710.200.00jbd2vda1-814时51分21秒013320.200.00argusagent14时51分21秒0526510.020.00A1iSecGuardU时51分21秒074397.820.00kworker/0：214时51分21秒079060.200.00pidstat14时51分21秒083460.200.00SShdI4时51分21秒0206549.820.00A1iYunDunM时51分21秒0257660.200.00kworkeru2:114时51分21秒python30286031.000.00CSWCh每秒自愿上下

10、文切换次数（进程无法获取所需资源导致的上下文切换）nvcswch每秒非自愿上下文切换次数（时间片轮流等系统强制调度）vmstat11#新终端观察上下文切换情况此时发现CS数据明显升高，同时观察其他指标：r列：远超系统CPU个数，说明存在大量CPU竞争US和Sy列：Sy列占比80%,说明CPU主要被内核占用in列：中断次数明显上升，说明中断处理也是潜在问题说明运行/等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高pidstat-W-U1#查看到底哪个进程导致的问题从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分

11、析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。另外对于中断次数过多，我们可以通过procinte门upts文件读取watch-dcatprociinterrupts发现次数变化速度最快的是重调度中断(RES),该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。某个应用的CPU使用率达到100%,怎么办？1inUX作为多任务操作系统，将CPU时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护CPU时间，1inUX通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以

12、来的节拍数。时间中断发生一次该值+1.CPU使用率，除了空闲时间以外的其他时间占总CPU时间的百分比。可以通过procstat中的数据来计算出CPU使用率。因为procStat时开机以来的节拍数累加值，计算出来的是开机以来的平均CPU使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均CPU使用率。性能分析工具给出的都是间隔一段时间的平均CPU使用率，要注意间隔时间的设置。CPU使用率可以通过top或PS来查看。分析进程的CPU问题可以通过perf,它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。perftop/perf

13、record/perfreport（-g开启调用关系的采样）sudodockerrun-namenginx-p10000：80-itdfeisky/nginxsudodockerrun-namephpfpm-itd-networkcontainer：nginxfeisky/php-fpmab-c10-n100http：/XXX.XXX.XXX.XXX：10000/#测试NginX服务性能发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000o在另外一个终端运行top查看每个CPU的使用率。发现系统中几个php-fpm进程导致CPU使用率骤升。接着用perf来分析具体是php-

14、fpm中哪个函数导致该问题。perftop-g-pXXXX#对某一个PhP-fpm进程进行分析发现其中sqrt和add_function占用CPU过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升系统的CPU使用率很高，为什么找不到高CPU的应用？sudodockerrun-namenginx-p10000：80-itdfeisky/nginx：spsudodockerrun-namephpfpm-Itd-networkcontainer：nginxfeisky/php-fpm：spab-c100-n10

15、00http：/XXX.XXX.XXX.XXX：10000/#并发100个请求测试实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，nginx负载能力依旧很低。此时用top和PidStat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5.再仔细查看进程运行数据，发现nginx和php-fpm都处于SIeeP状态，真正处于运行的却是几个StreSS进程。下一步就利用PidStat分析这几个StreSS进程，发现没有任何输出。用PSaUX交