Linux性能优化

　　性能优化性能指标
　　高并发和响应快对应着性能优化的两个核心指标：吞吐和延时
　　应用负载角度：直接影响了产品终端的用户体验系统资源角度：资源使用率、饱和度等
　　性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。选择指标评估应用程序和系统性能为应用程序和系统设置性能目标进行性能基准测试性能分析定位瓶颈性能监控和告警
　　对于不同的性能问题要选取不同的性能分析工具。下面是常用的LinuxPerformanceTools以及对应分析的性能问题类型。
　　到底应该怎么理解平均负载
　　平均负载：单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。它和我们传统意义上理解的CPU使用率并没有直接关系。
　　其中不可中断进程是正处于内核态关键流程中的进程（如常见的等待设备的IO响应）。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。平均负载多少时合理
　　实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。当然也可以当设置阈值（如当平均负载高于CPU数量的70时）
　　现实工作中我们会经常混淆平均负载和CPU使用率的概念，其实两者并不完全对等：CPU密集型进程，大量CPU使用会导致平均负载升高，此时两者一致IO密集型进程，等待IO也会导致平均负载升高，此时CPU使用率并不一定高大量等待CPU的进程调度会导致平均负载升高，此时CPU使用率也会比较高
　　平均负载高时可能是CPU密集型进程导致，也可能是IO繁忙导致。具体分析时可以结合mpstatpidstat工具辅助分析负载来源CPUCPU上下文切换（上）
　　CPU上下文切换，就是把前一个任务的CPU上下文（CPU寄存器和PC）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。
　　按照任务类型，CPU上下文切换分为：进程上下文切换线程上下文切换中断上下文切换进程上下文切换
　　Linux进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。
　　一次系统调用过程其实进行了两次CPU上下文切换：CPU寄存器中用户态的指令位置先保存起来，CPU寄存器更新为内核态指令的位置，跳转到内核态运行内核任务；系统调用结束后，CPU寄存器恢复原来保存的用户态数据，再切换到用户空间继续运行。
　　系统调用过程中并不会涉及虚拟内存等进程用户态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。
　　进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。
　　进程只有在调度到CPU上运行时才需要切换上下文，有以下几种场景：CPU时间片轮流分配，系统资源不足导致进程挂起，进程通过sleep函数主动挂起，高优先级进程抢占时间片，硬件中断时CPU上的进程被挂起转而执行内核中的中断服务。线程上下文切换
　　线程上下文切换分为两种：前后线程同属于一个进程，切换时虚拟内存资源不变，只需要切换线程的私有数据，寄存器等；前后线程属于不同进程，与进程上下文切换相同。
　　同进程的线程切换消耗资源较少，这也是多线程的优势。中断上下文切换
　　中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态（CPU寄存器，内核堆栈，硬件中断参数等）。
　　中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生CPU上下文切换（下）
　　通过vmstat可以查看系统总体的上下文切换情况vmstat5每隔5s输出一组数据procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwast10010338814541251105600186011219600000103388145412511076000245011761199000001033881454125110760008429113511980000010338814541251107600004311132119800000103388145412511076000104671195119800100103388145412511076000242611391099004009518414541251110800074500122841940000010351214541651107600045572315731238320cs（contextswitch）每秒上下文切换次数in（interrupt）每秒中断次数r（runnningorrunnable）就绪队列的长度，正在运行和等待CPU的进程数b（Blocked）处于不可中断睡眠状态的进程数
　　要查看每个进程的详细情况，需要使用pidstat来查看每个进程上下文切换情况pidstatw514时51分16秒UIDPIDcswchsnvcswchsCommand14时51分21秒010。800。00systemd14时51分21秒061。400。00ksoftirqd014时51分21秒0932。670。00rcusched14时51分21秒0110。400。00watchdog014时51分21秒0320。200。00khugepaged14时51分21秒02710。200。00jbd2vda1814时51分21秒013320。200。00argusagent14时51分21秒0526510。020。00AliSecGuard14时51分21秒074397。820。00kworker0：214时51分21秒079060。200。00pidstat14时51分21秒083460。200。00sshd14时51分21秒0206549。820。00AliYunDun14时51分21秒0257660。200。00kworkeru2：114时51分21秒0286031。000。00python3cswch每秒自愿上下文切换次数（进程无法获取所需资源导致的上下文切换）nvcswch每秒非自愿上下文切换次数（时间片轮流等系统强制调度）vmstat11首先获取空闲系统的上下文切换次数sysbenchthreads10maxtime300threadsrun模拟多线程切换问题vmstat11新终端观察上下文切换情况此时发现cs数据明显升高，同时观察其他指标：r列：远超系统CPU个数，说明存在大量CPU竞争us和sy列：sy列占比80，说明CPU主要被内核占用in列：中断次数明显上升，说明中断处理也是潜在问题
　　说明运行等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高pidstatwu1查看到底哪个进程导致的问题
　　从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加t参数查看线程指标。
　　另外对于中断次数过多，我们可以通过procinterrupts文件读取watchdcatprocinterrupts
　　发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。某个应用的CPU使用率达到100，怎么办？
　　Linux作为多任务操作系统，将CPU时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护CPU时间，Linux通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以来的节拍数。时间中断发生一次该值1。
　　CPU使用率，除了空闲时间以外的其他时间占总CPU时间的百分比。可以通过procstat中的数据来计算出CPU使用率。因为procstat时开机以来的节拍数累加值，计算出来的是开机以来的平均CPU使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均CPU使用率。性能分析工具给出的都是间隔一段时间的平均CPU使用率，要注意间隔时间的设置。
　　CPU使用率可以通过top或ps来查看。分析进程的CPU问题可以通过perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。
　　perftopperfrecordperfreport（g开启调用关系的采样）sudodockerrunnamenginxp10000：80itdfeiskynginxsudodockerrunnamephpfpmitdnetworkcontainer：nginxfeiskyphpfpmabc10n100http：XXX。XXX。XXX。XXX：10000测试Nginx服务性能
　　发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个CPU的使用率。发现系统中几个phpfpm进程导致CPU使用率骤升。
　　接着用perf来分析具体是phpfpm中哪个函数导致该问题。perftopgpXXXX对某一个phpfpm进程进行分析
　　发现其中sqrt和addfunction占用CPU过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升系统的CPU使用率很高，为什么找不到高CPU的应用？sudodockerrunnamenginxp10000：80itdfeiskynginx：spsudodockerrunnamephpfpmitdnetworkcontainer：nginxfeiskyphpfpm：spabc100n1000http：XXX。XXX。XXX。XXX：10000并发100个请求测试
　　实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，nginx负载能力依旧很低。
　　此时用top和pidstat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。
　　出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5。再仔细查看进程运行数据，发现nginx和phpfpm都处于sleep状态，真正处于运行的却是几个stress进程。
　　下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用psaux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现stress进程的进程号变化了，此时有可能时以下两种原因导致：进程不停的崩溃重启（如段错误配置错误等），此时进程退出后可能又被监控系统重启；短时进程导致，即其他应用内部通过exec调用的外面命令，这些命令一般只运行很短时间就结束，很难用top这种间隔较长的工具来发现
　　可以通过pstree来查找stress的父进程，找出调用关系。pstreegrepstress
　　发现是phpfpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟IO压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。
　　代码中给每个请求加了verbose1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。
　　此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的CPU，通过修复权限问题来优化解决即可。系统中出现大量不可中断进程和僵尸进程怎么办？进程状态RRunningRunnable，表示进程在CPU的就绪队列中，正在运行或者等待运行；DDiskSleep，不可中断状态睡眠，一般表示进程正在跟硬件交互，并且交互过程中不允许被其他进程中断；ZZombie，僵尸进程，表示进程实际上已经结束，但是父进程还没有回收它的资源；SInterruptibleSleep，可中断睡眠状态，表示进程因为等待某个事件而被系统挂起，当等待事件发生则会被唤醒并进入R状态；IIdle，空闲状态，用在不可中断睡眠的内核线程上。该状态不会导致平均负载升高；TStopTraced，表示进程处于暂停或跟踪状态（SIGSTOPSIGCONT，GDB调试）；XDead，进程已经消亡，不会在topps中看到。
　　对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了IO性能问题。
　　僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。磁盘ODIRECT问题sudodockerrunprivilegednameappitdfeiskyapp：iowaitpsauxgrepapp
　　可以看到此时有多个app进程运行，状态分别时Ss和D。其中后面s表示进程是一个会话的领导进程，号表示前台进程组。
　　其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。
　　用top查看系统资源发现：1）平均负载在逐渐增加，且1分钟内平均负载达到了CPU个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us和sysCPU使用率都不高，iowait却比较高；4）每个进程CPU使用率也不高，但有两个进程处于D状态，可能在等待IO。
　　分析目前数据可知：iowait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。
　　用dstat来分析，因为它可以同时查看CPU和IO两种资源的使用情况，便于对比分析。dstat110间隔1秒输出10组数据
　　可以看到当wai（iowait）升高时磁盘请求read都会很大，说明iowait的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。
　　之前top查看的处于D状态的进程号，用pidstatdpXXX展示进程的IO统计数据。发现处于D状态的进程都没有任何读写操作。
　　在用pidstatd查看所有进程的IO统计数据，看到app进程在进行磁盘读操作，每秒读取32MB的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到app进程的系统调用。sudostracepXXX对app进程调用进行跟踪
　　报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。ps命令查找该进程已经处于Z状态，即僵尸进程。
　　这种情况下toppidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perfrecordd和perfreport进行分析，查看app进程调用栈。
　　看到app确实在通过系统调用sysread（）读取数据，并且从newsyncread和blkdevdirectIO看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。
　　通过层层分析后，rootcause是app内部进行了磁盘的直接IO。然后定位到具体代码位置进行优化即可。僵尸进程
　　上述优化后iowait显著下降，但是僵尸进程数量仍旧在增加。首先要定位僵尸进程的父进程，通过pstreeapsXXX，打印出该僵尸进程的调用树，发现父进程就是app进程。
　　查看app代码，看看子进程结束的处理是否正确（是否调用wait（）waitpid（），有没有注册SIGCHILD信号的处理函数等）。
　　碰到iowait升高时，先用dstatpidstat等工具确认是否存在磁盘IO问题，再找是哪些进程导致IO，不能用strace直接分析进程调用时可以通过perf工具分析。
　　对于僵尸问题，用pstree找到父进程，然后看源码检查子进程结束的处理逻辑即可。CPU性能指标CPU使用率用户CPU使用率，包括用户态（user）和低优先级用户态（nice）。该指标过高说明应用程序比较繁忙。系统CPU使用率，CPU在内核态运行的时间百分比（不含中断）。该指标高说明内核比较繁忙。等待IO的CPU使用率，iowait，该指标高说明系统与硬件设备IO交互时间比较长。软硬中断CPU使用率，该指标高说明系统中发生大量中断。stealCPUguestCPU，表示虚拟机占用的CPU百分比。平均负载理想情况下平均负载等于逻辑CPU个数，表示每个CPU都被充分利用。若大于则说明系统负载较重。进程上下文切换包括无法获取资源的自愿切换和系统强制调度时的非自愿切换。上下文切换本身是保证Linux正常运行的一项核心功能。过多的切换则会将原本运行进程的CPU时间消耗在寄存器，内核占及虚拟内存等数据保存和恢复上CPU缓存命中率CPU缓存的复用情况，命中率越高性能越好。其中L1L2常用在单核，L3则用在多核中性能工具平均负载案例先用uptime查看系统平均负载判断负载在升高后再用mpstat和pidstat分别查看每个CPU和每个进程CPU使用情况。找出导致平均负载较高的进程。上下文切换案例先用vmstat查看系统上下文切换和中断次数再用pidstat观察进程的自愿和非自愿上下文切换情况最后通过pidstat观察线程的上下文切换情况进程CPU使用率高案例先用top查看系统和进程的CPU使用情况，定位到进程再用perftop观察进程调用链，定位到具体函数系统CPU使用率高案例先用top查看系统和进程的CPU使用情况，toppidstat都无法找到CPU使用率高的进程重新审视top输出从CPU使用率不高，但是处于Running状态的进程入手perfrecordreport发现短时进程导致（execsnoop工具）不可中断和僵尸进程案例先用top观察iowait升高，发现大量不可中断和僵尸进程strace无法跟踪进程系统调用perf分析调用链发现根源来自磁盘直接IO软中断案例top观察系统软中断CPU使用率高查看procsoftirqs找到变化速率较快的几种软中断sar命令发现是网络小包问题tcpdump找出网络帧的类型和来源，确定SYNFLOOD攻击导致
　　根据不同的性能指标来找合适的工具：
　　在生产环境中往往开发者没有权限安装新的工具包，只能最大化利用好系统中已经安装好的工具。因此要了解一些主流工具能够提供哪些指标分析。
　　先运行几个支持指标较多的工具，如topvmstatpidstat，根据它们的输出可以得出是哪种类型的性能问题。定位到进程后再用straceperf分析调用情况进一步分析。如果是软中断导致用procsoftirqs
　　CPU优化应用程序优化编译器优化：编译阶段开启优化选项，如gccO2算法优化异步处理：避免程序因为等待某个资源而一直阻塞，提升程序的并发处理能力。（将轮询替换为事件通知）多线程代替多进程：减少上下文切换成本善用缓存：加快程序处理速度系统优化CPU绑定：将进程绑定要1个多个CPU上，提高CPU缓存命中率，减少CPU调度带来的上下文切换CPU独占：CPU亲和性机制来分配进程优先级调整：使用nice适当降低非核心应用的优先级为进程设置资源显示：cgroups设置使用上限，防止由某个应用自身问题耗尽系统资源NUMA优化：CPU尽可能访问本地内存中断负载均衡：irpbalance，将中断处理过程自动负载均衡到各个CPU上TPS、QPS、系统吞吐量的区别和理解QPS（QueriesPerSecond）每秒查询率，一台服务器每秒能够响应的查询次数。TPS（TransactionsPerSecond）每秒事务数，软件测试的结果。用户请求服务器服务器内部处理服务器返回给客户QPS类似TPS，但是对于一个页面的访问形成一个TPS，但是一次页面请求可能包含多次对服务器的请求，可能计入多次QPS系统吞吐量，包括几个重要参数：QPS（TPS）并发数响应时间QPS（TPS）并发数平均相应时间内存Linux内存是怎么工作的内存映射
　　大多数计算机用的主存都是动态随机访问内存（DRAM），只有内核才可以直接访问物理内存。Linux内核给每个进程提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样进程就可以很方便的访问内存（虚拟内存）。
　　虚拟地址空间的内部分为内核空间和用户空间两部分，不同字长的处理器地址空间的范围不同。32位系统内核空间占用1G，用户空间占3G。64位系统内核空间和用户空间都是128T，分别占内存空间的最高和最低处，中间部分为未定义。
　　并不是所有的虚拟内存都会分配物理内存，只有实际使用的才会。分配后的物理内存通过内存映射管理。为了完成内存映射，内核为每个进程都维护了一个页表，记录虚拟地址和物理地址的映射关系。页表实际存储在CPU的内存管理单元MMU中，处理器可以直接通过硬件找出要访问的内存。
　　当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存，更新进程页表，再返回用户空间恢复进程的运行。
　　MMU以页为单位管理内存，页大小4KB。为了解决页表项过多问题Linux提供了多级页表和HugePage的机制。虚拟内存空间分布
　　用户空间内存从低到高是五种不同的内存段：只读段代码和常量等数据段全局变量等堆动态分配的内存，从低地址开始向上增长文件映射动态库、共享内存等，从高地址开始向下增长栈包括局部变量和函数调用的上下文等，栈的大小是固定的。一般8MB内存分配与回收分配
　　malloc对应到系统调用上有两种实现方式：brk（）针对小块内存（128K），通过移动堆顶位置来分配。内存释放后不立即归还内存，而是被缓存起来。mmap（）针对大块内存（128K），直接用内存映射来分配，即在文件映射段找一块空闲内存分配。
　　前者的缓存可以减少缺页异常的发生，提高内存访问效率。但是由于内存没有归还系统，在内存工作繁忙时，频繁的内存分配释放会造成内存碎片。
　　后者在释放时直接归还系统，所以每次mmap都会发生缺页异常。在内存工作繁忙时，频繁内存分配会导致大量缺页异常，使内核管理负担增加。
　　上述两种调用并没有真正分配内存，这些内存只有在首次访问时，才通过缺页异常进入内核中，由内核来分配回收
　　内存紧张时，系统通过以下方式来回收内存：回收缓存：LRU算法回收最近最少使用的内存页面；回收不常访问内存：把不常用的内存通过交换分区写入磁盘杀死进程：OOM内核保护机制（进程消耗内存越大oomscore越大，占用CPU越多oomscore越小，可以通过proc手动调整oomadj）echo16proc（pidofXXX）oomadj如何查看内存使用情况
　　free来查看整个系统的内存使用情况
　　topps来查看某个进程的内存使用情况VIRT进程的虚拟内存大小RES常驻内存的大小，即进程实际使用的物理内存大小，不包括swap和共享内存SHR共享内存大小，与其他进程共享的内存，加载的动态链接库以及程序代码段MEM进程使用物理内存占系统总内存的百分比怎样理解内存中的Buffer和Cache？
　　buffer是对磁盘数据的缓存，cache是对文件数据的缓存，它们既会用在读请求也会用在写请求中如何利用系统缓存优化程序的运行效率缓存命中率
　　缓存命中率是指直接通过缓存获取数据的请求次数，占所有请求次数的百分比。命中率越高说明缓存带来的收益越高，应用程序的性能也就越好。
　　安装bcc包后可以通过cachestat和cachetop来监测缓存的读写命中情况。
　　安装pcstat后可以查看文件在内存中的缓存大小以及缓存比例首先安装GoexportGOPATHgoexportPATHgobin：PATHgogetgolang。orgxsysunixgogegithub。comtobertpcstatpcstatdd缓存加速ddifdevsda1offilebs1Mcount512生产一个512MB的临时文件echo3procsysvmdropcaches清理缓存pcstatfile确定刚才生成文件不在系统缓存中，此时cached和percent都是0cachetop5ddiffileofdevnullbs1M测试文件读取速度此时文件读取性能为30MBs，查看cachetop结果发现并不是所有的读都落在磁盘上，读缓存命中率只有50。ddiffileofdevnullbs1M重复上述读文件测试此时文件读取性能为4GBs，读缓存命中率为100pcstatfile查看文件file的缓存情况，100全部缓存ODIRECT选项绕过系统缓存cachetop5sudodockerrunprivilegednameappitdfeiskyapp：iodirectsudodockerlogsapp确认案例启动成功实验结果表明每读32MB数据都要花0。9s，且cachetop输出中显示1024次缓存全部命中
　　但是凭感觉可知如果缓存命中读速度不应如此慢，读次数时1024，页大小为4K，五秒的时间内读取了10244KB数据，即每秒0。8MB，和结果中32MB相差较大。说明该案例没有充分利用缓存，怀疑系统调用设置了直接IO标志绕过系统缓存。因此接下来观察系统调用。stracep（pgrepapp）strace结果可以看到openat打开磁盘分区devsdb1，传入参数为ORDONLYODIRECT
　　这就解释了为什么读32MB数据那么慢，直接从磁盘读写肯定远远慢于缓存。找出问题后我们再看案例的源代码发现flags中指定了直接IO标志。删除该选项后重跑，验证性能变化。内存泄漏，如何定位和处理？
　　对应用程序来说，动态内存的分配和回收是核心又复杂的一个逻辑功能模块。管理内存的过程中会发生各种各样的事故：没正确回收分配的内存，导致了泄漏访问的是已分配内存边界外的地址，导致程序异常退出内存的分配与回收
　　虚拟内存分布从低到高分别是只读段，数据段，堆，内存映射段，栈五部分。其中会导致内存泄漏的是：堆：由应用程序自己来分配和管理，除非程序退出这些堆内存不会被系统自动释放。内存映射段：包括动态链接库和共享内存，其中共享内存由程序自动分配和管理
　　内存泄漏的危害比较大，这些忘记释放的内存，不仅应用程序自己不能访问，系统也不能把它们再次分配给其他应用。内存泄漏不断累积甚至会耗尽系统内存。如何检测内存泄漏
　　预先安装systat，docker，bccsudodockerrunnameappitdfeiskyapp：memleaksudodockerlogsappvmstat3
　　可以看到free在不断下降，buffer和cache基本保持不变。说明系统的内存一致在升高。但并不能说明存在内存泄漏。此时可以通过memleak工具来跟踪系统或进程的内存分配释放请求usrsharebcctoolsmemleakap（pidofapp）
　　从memleak输出可以看到，应用在不停地分配内存，并且这些分配的地址并没有被回收。通过调用栈看到是fibonacci函数分配的内存没有释放。定位到源码后查看源码来修复增加内存释放函数即可。为什么系统的Swap变高
　　系统内存资源紧张时通过内存回收和OOM杀死进程来解决。其中可回收内存包括：缓存缓冲区，属于可回收资源，在文件管理中通常叫做文件页被应用程序修改过暂时没写入磁盘的数据（脏页），要先写入磁盘然后才能内存释放在应用程序中通过fsync将脏页同步到磁盘交给系统，内核线程pdflush负责这些脏页的刷新内存映射获取的文件映射页，也可以被释放掉，下次访问时从文件重新读取
　　对于程序自动分配的堆内存，也就是我们在内存管理中的匿名页，虽然这些内存不能直接释放，但是Linux提供了Swap机制将不常访问的内存写入到磁盘来释放内存，再次访问时从磁盘读取到内存即可。Swap原理
　　Swap本质就是把一块磁盘空间或者一个本地文件当作内存来使用，包括换入和换出两个过程：换出：将进程暂时不用的内存数据存储到磁盘中，并释放这些内存换入：进程再次访问内存时，将它们从磁盘读到内存中
　　Linux如何衡量内存资源是否紧张？直接内存回收新的大块内存分配请求，但剩余内存不足。此时系统会回收一部分内存；kswapd0内核线程定期回收内存。为了衡量内存使用情况，定义了pagesmin，pageslow，pageshigh三个阈值，并根据其来进行内存的回收操作。剩余内存pagesmin，进程可用内存耗尽了，只有内核才可以分配内存pagesmin剩余内存pageslow，内存压力较大，kswapd0执行内存回收，直到剩余内存pageshighpageslow剩余内存pageshigh，内存有一定压力，但可以满足新内存请求剩余内存pageshigh，说明剩余内存较多，无内存压力pageslowpagesmin54pageshighpagesmin32NUMA与SWAP
　　很多情况下系统剩余内存较多，但SWAP依旧升高，这是由于处理器的NUMA架构。
　　在NUMA架构下多个处理器划分到不同的Node，每个Node都拥有自己的本地内存空间。在分析内存的使用时应该针对每个Node单独分析numactlhardware查看处理器在Node的分布情况，以及每个Node的内存使用情况
　　内存三个阈值可以通过proczoneinfo来查看，该文件中还包括活跃和非活跃的匿名页文件页数。
　　当某个Node内存不足时，系统可以从其他Node寻找空闲资源，也可以从本地内存中回收内存。通过procsysvmzoneraclaimmode来调整。0表示既可以从其他Node寻找空闲资源，也可以从本地回收内存1，2，4表示只回收本地内存，2表示可以会回脏数据回收内存，4表示可以用Swap方式回收内存。swappiness
　　在实际回收过程中Linux根据procsysvmswapiness选项来调整使用Swap的积极程度，从0100，数值越大越积极使用Swap，即更倾向于回收匿名页；数值越小越消极使用Swap，即更倾向于回收文件页。
　　注意：这只是调整Swap积极程度的权重，即使设置为0，当剩余内存文件页小于页高阈值时，还是会发生Swap。Swap升高时如何定位分析free首先通过free查看swap使用情况，若swap0表示未配置Swap先创建并开启swapfallocatel8Gmntswapfilechmod600mntswapfilemkswapmntswapfileswaponmntswapfilefree再次执行free确保Swap配置成功ddifdevsda1ofdevnullbs1Gcount2048模拟大文件读取sarrS1查看内存各个指标变化r内存Sswap根据结果可以看出，memused在不断增长，剩余内存kbmemfress不断减少，缓冲区kbbuffers不断增大，由此可知剩余内存不断分配给了缓冲区一段时间之后，剩余内存很小，而缓冲区占用了大部分内存。此时Swap使用之间增大，缓冲区和剩余内存只在小范围波动停下sar命令cachetop5观察缓存可以看到dd进程读写只有50的命中率，未命中数为4w页，说明正式dd进程导致缓冲区使用升高watchdgrepA15‘Normal’proczoneinfo观察内存指标变化发现升级内存在一个小范围不停的波动，低于页低阈值时会突然增大到一个大于页高阈值的值
　　说明剩余内存和缓冲区的波动变化正是由于内存回收和缓存再次分配的循环往复。有时候Swap用的多，有时候缓冲区波动更多。此时查看swappiness值为60，是一个相对中和的配置，系统会根据实际运行情况来选去合适的回收类型。如何快准狠找到系统内存存在的问题内存性能指标
　　系统内存指标已用内存剩余内存共享内存（tmpfs实现）可用内存：包括剩余内存和可回收内存缓存：磁盘读取文件的页缓存，slab分配器中的可回收部分缓冲区：原始磁盘块的临时存储，缓存将要写入磁盘的数据
　　进程内存指标虚拟内存：5大部分常驻内存：进程实际使用的物理内存，不包括Swap和共享内存共享内存：与其他进程共享的内存，以及动态链接库和程序的代码段Swap内存：通过Swap换出到磁盘的内存
　　缺页异常可以直接从物理内存中分配，次缺页异常需要磁盘IO介入（如Swap），主缺页异常。此时内存访问会慢很多内存性能工具
　　根据不同的性能指标来找合适的工具：
　　内存分析工具包含的性能指标：
　　如何迅速分析内存的性能瓶颈
　　通常先运行几个覆盖面比较大的性能工具，如free，top，vmstat，pidstat等先用free和top查看系统整体内存使用情况再用vmstat和pidstat，查看一段时间的趋势，从而判断内存问题的类型最后进行详细分析，比如内存分配分析，缓存缓冲区分析，具体进程的内存使用分析等
　　常见的优化思路：最好禁止Swap，若必须开启则尽量降低swappiness的值减少内存的动态分配，如可以用内存池，HugePage等尽量使用缓存和缓冲区来访问数据。如用堆栈明确声明内存空间来存储需要缓存的数据，或者用Redis外部缓存组件来优化数据的访问cgroups等方式来限制进程的内存使用情况，确保系统内存不被异常进程耗尽procpidoomadj调整核心应用的oomscore，保证即使内存紧张核心应用也不会被OOM杀死vmstat使用详解
　　vmstat命令是最常见的LinuxUnix监控工具，可以展现给定时间间隔的服务器的状态值，包括服务器的CPU使用率，内存使用，虚拟内存交换情况，IO读写情况。可以看到整个机器的CPU，内存，IO的使用情况，而不是单单看到各个进程的CPU使用率和内存使用率（使用场景不一样）。vmstat2procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwast100137906428224411537528003104003097000001372716282244115375440002448938947109800000137340428224811537544000965105927820980000013741682822481153755600005001920810990000013769482822481153756400080517693882098000001379356282256115375800002025474951920980010013683762822561154369600005894894012088001001371936282256115392400001055461769481141851010013661842822601154229200074566102998371910010013530402822601155617600016924723395781818010000135943228226011549124000125765495927170921000013617442822641154913200058860615079429500100136712028226411549140000257169205809200000134658028226411562644000706416994412088000001359164282264115501080002922494189693097001001353992282264115570440000602389171508400结果说明r表示运行队列（就是说多少个进程真的分配到CPU），我测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。b表示阻塞的进程，这个不多说，进程阻塞，大家懂的。swpd虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。free空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。buffLinuxUnix系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用300多Mcachecache直接用来记忆我们打开的文件，给文件做缓冲，我本机大概占用300多M（这里是LinuxUnix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高程序执行的性能，当程序使用内存时，buffercached会很快地被使用。）si每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。so每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。bi块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据（23T）的机器上看过可以达到140000s，磁盘写入速度差不多140M每秒bo块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。in每秒CPU的中断次数，包括时间中断cs每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目，例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。us用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100，r运行队列达到80（机器在做压力测试，性能表现不佳）。sy系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。id空闲CPU时间，一般来说，idussy100，一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。wt等待IOCPU时间pidstat使用详解
　　pidstat主要用于监控全部或指定进程占用系统资源的情况，如CPU，内存、设备IO、任务切换、线程等。
　　使用方法：pidstatdintervaltimes统计各个进程的IO使用情况pidstatuintervaltimes统计各个进程的CPU统计信息pidstatrintervaltimes统计各个进程的内存使用信息pidstatwintervaltimes统计各个进程的上下文切换pPID指定PID
　　1、统计IO使用情况pidstatd11003：02：02PMUIDPIDkBrdskBwrskBccwrsCommand03：02：03PM08160。00918。810。00jbd2vda1803：02：03PM010070。003。960。00AliYunDun03：02：03PM99773260。001904。95918。81java03：02：03PM99785390。003。960。00java03：02：03PM0160660。0035。640。00cmagent03：02：03PMUIDPIDkBrdskBwrskBccwrsCommand03：02：04PM08160。001924。000。00jbd2vda1803：02：04PM99773260。0011156。001888。00java03：02：04PM99785390。004。000。00javaUIDPIDkBrds：每秒进程从磁盘读取的数据量KB单位readfromdiskeachsecondKBkBwrs：每秒进程向磁盘写的数据量KB单位writetodiskeachsecondKBkBccwrs：每秒进程向磁盘写入，但是被取消的数据量，Thismayoccurwhenthetasktruncatessomedirtypagecache。iodelay：BlockIOdelay，measuredinclockticksCommand：进程名taskname
　　2、统计CPU使用情况统计CPUpidstatu11003：03：33PMUIDPIDusrsystemguestCPUCPUCommand03：03：34PM023213。960。000。003。960ansible03：03：34PM071100。000。990。000。994pidstat03：03：34PM99785390。990。000。000。995java03：03：34PM984155170。990。000。000。995java03：03：34PM0244060。990。000。000。995java03：03：34PM0321583。960。000。003。962ansibleUIDPIDusr：进程在用户空间占用cpu的百分比system：进程在内核空间占用CPU百分比guest：进程在虚拟机占用CPU百分比wait：进程等待运行的百分比CPU：进程占用CPU百分比CPU：处理进程的CPU编号Command：进程名
　　3、统计内存使用情况统计内存pidstatr110Average：UIDPIDminfltsmajfltsVSZRSSMEMCommandAverage：010。200。0019125630640。01systemdAverage：010071。300。00143256227200。07AliYunDunAverage：066420。100。0063019041076800。33javaAverage：997732610。890。0013468904839584826。04javaAverage：07795348。150。0010837612330。00pidstatAverage：99785390。500。00824225620622286。40javaAverage：98795180。200。00630094412429243。85javaAverage：0102803。700。0080737283440。03aliyunserviceAverage：984155170。400。00638646414645724。54javaAverage：016066236。460。002678332710200。22cmagentAverage：995209550。300。00631252014080404。37javaAverage：995209560。200。00609376415050284。67javaAverage：0239360。100。0053024161108040。34javaAverage：0244060。700。001021167223613047。32javaAverage：0268701。400。001470212360840。11promtailUIDPIDMinflts：每秒次缺页错误次数（minorpagefaults），虚拟内存地址映射成物理内存地址产生的pagefault次数Majflts：每秒主缺页错误次数（majorpagefaults），虚拟内存地址映射成物理内存地址时，相应page在swap中VSZvirtualmemoryusage：该进程使用的虚拟内存KB单位RSS：该进程使用的物理内存KB单位MEM：内存使用率Command：该进程的命令taskname
　　4、查看具体进程使用情况pidstatTALLrp2095511003：12：16PMUIDPIDminfltsmajfltsVSZRSSMEMCommand03：12：17PM995209550。000。00631252014080404。37java03：12：16PMUIDPIDminfltnrmajfltnrCommand03：12：17PM9952095500java
　　作者：mikelLa
　　https：www。ctq6。cnlinuxE680A7E883BDE4BC98E58C96
　　排版：老李