高并发和响应快对应着性能优化的两个核心指标：吞吐和延时
性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。
对于不同的性能问题要选取不同的性能分析工具。下面是常用的LinuxPerformanceTools以及对应分析的性能问题类型。
实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。当然也可以当设置阈值（如当平均负载高于CPU数量的70%时）现实工作中我们会经常混淆平均负载和CPU使用率的概念，其实两者并不完全对等：
CPU上下文切换，就是把前一个任务的CPU上下文（CPU寄存器和PC）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。按照任务类型，CPU上下文切换分为：
Linux进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。一次系统调用过程其实进行了两次CPU上下文切换：
系统调用过程中并不会涉及虚拟内存等进程用户态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。
进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。
线程上下文切换分为两种：
同进程的线程切换消耗资源较少，这也是多线程的优势。
中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态（CPU寄存器，内核堆栈，硬件中断参数等）。
中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生
通过vmstat可以查看系统总体的上下文切换情况
要查看每个进程的详细情况，需要使用pidstat来查看每个进程上下文切换情况
pidstat-w-u1#查看到底哪个进程导致的问题从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。
另外对于中断次数过多，我们可以通过/proc/interrupts文件读取
发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。
CPU使用率可以通过top或ps来查看。分析进程的CPU问题可以通过perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。
perftop/perfrecord/perfreport（-g开启调用关系的采样）
接着用perf来分析具体是php-fpm中哪个函数导致该问题。
发现其中sqrt和add_function占用CPU过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升
此时用top和pidstat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。
出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5.再仔细查看进程运行数据，发现nginx和php-fpm都处于sleep状态，真正处于运行的却是几个stress进程。
下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用psaux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现stress进程的进程号变化了，此时有可能时以下两种原因导致：
可以通过pstree来查找stress的父进程，找出调用关系。
发现是php-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟I/O压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。
此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的CPU，通过修复权限问题来优化解决即可.
僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。
sudodockerrun--privileged--name=app-itdfeisky/app:iowaitpsaux|grep'/app'可以看到此时有多个app进程运行，状态分别时Ss+和D+。其中后面s表示进程是一个会话的领导进程，+号表示前台进程组。
其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。用top查看系统资源发现：1）平均负载在逐渐增加，且1分钟内平均负载达到了CPU个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us和sysCPU使用率都不高，iowait却比较高；4）每个进程CPU使用率也不高，但有两个进程处于D状态，可能在等待IO。
分析目前数据可知：iowait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。
用dstat来分析，因为它可以同时查看CPU和I/O两种资源的使用情况，便于对比分析。
可以看到当wai（iowait）升高时磁盘请求read都会很大，说明iowait的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。
之前top查看的处于D状态的进程号，用pidstat-d-pXXX展示进程的I/O统计数据。发现处于D状态的进程都没有任何读写操作。在用pidstat-d查看所有进程的I/O统计数据，看到app进程在进行磁盘读操作，每秒读取32MB的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到app进程的系统调用。
sudostrace-pXXX#对app进程调用进行跟踪报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。ps命令查找该进程已经处于Z状态，即僵尸进程。
这种情况下toppidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perfrecord-d和perfreport进行分析，查看app进程调用栈。
看到app确实在通过系统调用sys_read()读取数据，并且从new_sync_read和blkdev_direct_IO看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。
通过层层分析后，rootcause是app内部进行了磁盘的直接I/O。然后定位到具体代码位置进行优化即可。
上述优化后iowait显著下降，但是僵尸进程数量仍旧在增加。首先要定位僵尸进程的父进程，通过pstree-apsXXX，打印出该僵尸进程的调用树，发现父进程就是app进程。
查看app代码，看看子进程结束的处理是否正确（是否调用wait()/waitpid(),有没有注册SIGCHILD信号的处理函数等）。
碰到iowait升高时，先用dstatpidstat等工具确认是否存在磁盘I/O问题，再找是哪些进程导致I/O，不能用strace直接分析进程调用时可以通过perf工具分析。
对于僵尸问题，用pstree找到父进程，然后看源码检查子进程结束的处理逻辑即可。
CPU使用率
平均负载理想情况下平均负载等于逻辑CPU个数,表示每个CPU都被充分利用.若大于则说明系统负载较重.
CPU缓存命中率CPU缓存的复用情况,命中率越高性能越好.其中L1/L2常用在单核,L3则用在多核中
平均负载案例
上下文切换案例
进程CPU使用率高案例
系统CPU使用率高案例
不可中断和僵尸进程案例
软中断案例
根据不同的性能指标来找合适的工具:
在生产环境中往往开发者没有权限安装新的工具包,只能最大化利用好系统中已经安装好的工具.因此要了解一些主流工具能够提供哪些指标分析.
先运行几个支持指标较多的工具,如top/vmstat/pidstat,根据它们的输出可以得出是哪种类型的性能问题.定位到进程后再用strace/perf分析调用情况进一步分析.如果是软中断导致用/proc/softirqs
应用程序优化
系统优化
TPS、QPS、系统吞吐量的区别和理解
大多数计算机用的主存都是动态随机访问内存(DRAM)，只有内核才可以直接访问物理内存。Linux内核给每个进程提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样进程就可以很方便的访问内存(虚拟内存)。
虚拟地址空间的内部分为内核空间和用户空间两部分，不同字长的处理器地址空间的范围不同。32位系统内核空间占用1G，用户空间占3G。64位系统内核空间和用户空间都是128T，分别占内存空间的最高和最低处，中间部分为未定义。
并不是所有的虚拟内存都会分配物理内存，只有实际使用的才会。分配后的物理内存通过内存映射管理。为了完成内存映射，内核为每个进程都维护了一个页表，记录虚拟地址和物理地址的映射关系。页表实际存储在CPU的内存管理单元MMU中，处理器可以直接通过硬件找出要访问的内存。
当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存，更新进程页表，再返回用户空间恢复进程的运行。
MMU以页为单位管理内存，页大小4KB。为了解决页表项过多问题Linux提供了多级页表和HugePage的机制。
用户空间内存从低到高是五种不同的内存段：
malloc对应到系统调用上有两种实现方式：
前者的缓存可以减少缺页异常的发生，提高内存访问效率。但是由于内存没有归还系统，在内存工作繁忙时，频繁的内存分配/释放会造成内存碎片。
后者在释放时直接归还系统，所以每次mmap都会发生缺页异常。在内存工作繁忙时，频繁内存分配会导致大量缺页异常，使内核管理负担增加。
上述两种调用并没有真正分配内存，这些内存只有在首次访问时，才通过缺页异常进入内核中，由内核来分配
内存紧张时，系统通过以下方式来回收内存：
回收缓存：LRU算法回收最近最少使用的内存页面；
回收不常访问内存：把不常用的内存通过交换分区写入磁盘
杀死进程：OOM内核保护机制（进程消耗内存越大oom_score越大，占用CPU越多oom_score越小，可以通过/proc手动调整oom_adj）
free来查看整个系统的内存使用情况top/ps来查看某个进程的内存使用情况
buffer是对磁盘数据的缓存，cache是对文件数据的缓存，它们既会用在读请求也会用在写请求中
缓存命中率是指直接通过缓存获取数据的请求次数，占所有请求次数的百分比。命中率越高说明缓存带来的收益越高，应用程序的性能也就越好。
安装bcc包后可以通过cachestat和cachetop来监测缓存的读写命中情况。
安装pcstat后可以查看文件在内存中的缓存大小以及缓存比例
这就解释了为什么读32MB数据那么慢，直接从磁盘读写肯定远远慢于缓存。找出问题后我们再看案例的源代码发现flags中指定了直接IO标志。删除该选项后重跑，验证性能变化。
对应用程序来说，动态内存的分配和回收是核心又复杂的一个逻辑功能模块。管理内存的过程中会发生各种各样的“事故”：
虚拟内存分布从低到高分别是只读段，数据段，堆，内存映射段，栈五部分。其中会导致内存泄漏的是：
内存泄漏的危害比较大，这些忘记释放的内存，不仅应用程序自己不能访问，系统也不能把它们再次分配给其他应用。内存泄漏不断累积甚至会耗尽系统内存.
预先安装systat，docker，bcc
sudodockerrun--name=app-itdfeisky/app:mem-leaksudodockerlogsappvmstat3可以看到free在不断下降，buffer和cache基本保持不变。说明系统的内存一致在升高。但并不能说明存在内存泄漏。此时可以通过memleak工具来跟踪系统或进程的内存分配/释放请求
从memleak输出可以看到，应用在不停地分配内存，并且这些分配的地址并没有被回收。通过调用栈看到是fibonacci函数分配的内存没有释放。定位到源码后查看源码来修复增加内存释放函数即可.
系统内存资源紧张时通过内存回收和OOM杀死进程来解决。其中可回收内存包括：
缓存/缓冲区，属于可回收资源，在文件管理中通常叫做文件页
内存映射获取的文件映射页，也可以被释放掉，下次访问时从文件重新读取
对于程序自动分配的堆内存，也就是我们在内存管理中的匿名页，虽然这些内存不能直接释放，但是Linux提供了Swap机制将不常访问的内存写入到磁盘来释放内存，再次访问时从磁盘读取到内存即可。
Swap本质就是把一块磁盘空间或者一个本地文件当作内存来使用，包括换入和换出两个过程：
Linux如何衡量内存资源是否紧张？
直接内存回收新的大块内存分配请求，但剩余内存不足。此时系统会回收一部分内存；
kswapd0内核线程定期回收内存。为了衡量内存使用情况，定义了pages_min,pages_low,pages_high三个阈值，并根据其来进行内存的回收操作。
很多情况下系统剩余内存较多，但SWAP依旧升高，这是由于处理器的NUMA架构。
在NUMA架构下多个处理器划分到不同的Node，每个Node都拥有自己的本地内存空间。在分析内存的使用时应该针对每个Node单独分析
numactl--hardware#查看处理器在Node的分布情况，以及每个Node的内存使用情况内存三个阈值可以通过/proc/zoneinfo来查看，该文件中还包括活跃和非活跃的匿名页/文件页数。
当某个Node内存不足时，系统可以从其他Node寻找空闲资源，也可以从本地内存中回收内存。通过/proc/sys/vm/zone_raclaim_mode来调整。
在实际回收过程中Linux根据/proc/sys/vm/swapiness选项来调整使用Swap的积极程度，从0-100，数值越大越积极使用Swap，即更倾向于回收匿名页；数值越小越消极使用Swap，即更倾向于回收文件页。
注意：这只是调整Swap积极程度的权重，即使设置为0，当剩余内存+文件页小于页高阈值时，还是会发生Swap。
说明剩余内存和缓冲区的波动变化正是由于内存回收和缓存再次分配的循环往复。有时候Swap用的多，有时候缓冲区波动更多。此时查看swappiness值为60，是一个相对中和的配置，系统会根据实际运行情况来选去合适的回收类型.
系统内存指标
进程内存指标
缺页异常
内存分析工具包含的性能指标:
通常先运行几个覆盖面比较大的性能工具，如free，top，vmstat，pidstat等
常见的优化思路：
1、统计IO使用情况
2、统计CPU使用情况
#统计CPUpidstat-u11003:03:33PMUIDPID%usr%system%guest%CPUCPUCommand03: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.962ansibleUIDPID%usr:进程在用户空间占用cpu的百分比%system:进程在内核空间占用CPU百分比%guest:进程在虚拟机占用CPU百分比%wait:进程等待运行的百分比%CPU:进程占用CPU百分比CPU:处理进程的CPU编号Command:进程名3、统计内存使用情况
4、查看具体进程使用情况
pidstat-TALL-r-p2095511003:12:16PMUIDPIDminflt/smajflt/sVSZRSS%MEMCommand03:12:17PM995209550.000.00631252014080404.37java03:12:16PMUIDPIDminflt-nrmajflt-nrCommand03:12:17PM9952095500java