Linux系统性能优化思路和优化方法及Linux性能调优经验总结.docx

Linux系统性能优化思路和优化方法及Linux性能调优经验总结一、影响LinUX性能的各种因素1、系统硬件资源（1）CPU如何判断多核CPU与超线程消耗CPU的业务：动态Web服务、mail服务（2）内存物理内存与swap的取舍选择64位LinUX操作系统消耗内存的业务：内存数据库（redis/hbase/mongodb）（3）磁盘IORAID技术（RAID0/1/5/01/10）SSD磁盘消耗磁盘的业务：数据库服务器（4）网络带宽网卡/交换机的选择操作系统双网卡绑定消耗带宽的业务：hadoop平台、视频业务平台2、操作系统相关资源（1）系统安装优化磁盘分区、RAlD设置、SWaP设置（2）内核参数优化ulimit-n（最大打开文件数）ulimit-u（最大用户数）（3）文件系统优化ext2：LinUX下标准文件系统，无日志记录（inode）功能。ext3：在ext2基础上增加了日志记录功能（inode）,仅支持32000个子目录。ex4：ext3的后续版本，LinUX2.6.28内核开始支持。无限子目录支持，快速fsckoxfs：高性能文件系统，LinUX3.10内核开始默认支持。建议：读操作频繁，同时小文件众多的应用：首选ext4文件系统，接下来依次是xfs>ext3写操作频繁的应用，首选是Xfs,接下来依次是ext4和ext3对性能要求开高、数据安全要求开高的业务，ext3是比较好的选择。3、程序问题此类问题需要开发人员查看代码，介入处理。但作为运维人员需要给出程序问题的有力证据。二、LinUX性能优化工具1、CPU性能评估工具（1）VmStat（系统默认自带）利用VmStat命令可以对操作系统的内存信息、进程状态、CPU活励等进行监视。常用方式：Vmstat23表示每3秒更新一次输出信息，统计5次后停止输出。下面是vmstat命令在某个系统的输出结果：rootnodelvraslat23procsmemoryswapiosystem-cpu_rbSWPdfreebuffcachesiSObiboinCSussyidwast000162240830467032001321100723019800000162240830467032001010102001100000001622408304670320011100918019900对上面每项的输出解释如下:procsr列表示运行和等待cpu时间片的进程数，这个值如果长期大于系统CPU的个数，说明CPU不足，需要增加CPU。b列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。memorySWPd列表示切换到内存交换区的内存数量（以k为单位）。如果SWPd的值不为0,或者比较大，只要si、SO的值长期为0,这种情况下一般不用担心，不会影响系统性能。free列表示当前空闲的物理内存数量（以k为单位）buff列表示bufferscache的内存数量，一般对块设备的读写才需要缓冲。CaChe列表示PageCaChed的内存数量，一般作为文件系统CaChed,频繁访问的文件都会被Caehed,如果CaChe值较大，说明CaChed的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。swapSi列表示由磁盘调入内存，也就是内存进入内存交换区的数量。SO列表示由内存调入磁盘，也就是内存交换区进入内存的数量。一般情况下，si、SO的值都为0,如果si、SO的值长期不为0,则表示系统内存不足。需要增加系统内存。IO项显示磁盘读写状况Bi列表示从块设备读入数据的总量（即读磁盘）（每秒kb）。B。列表示写入到块设备的数据总量（即写磁盘）（每秒kb）。这里我们设置的bi+bo参考值为1000,如果超过1000,而且Wa值较大，则表示系统磁盘IO有问题，应该考虑提高磁盘的读写性能。SyStem显示采集间隔内发生的中断数in列表示在某一时间间隔中观测到的每秒设备中断数。CS列表示每秒产生的上下文切换次数。上面这2个值越大，会看到由内核消耗的CPU时间会越多。CPU项显示了CPU的使用状态，此列是我们关注的重点。US列显示了用户进程消耗的CPU时间百分比。US的值比较高时，说明用户进程消耗的印U时间多，但是如果长期大于50%,就需要考虑优化程序或算法。Sy列显示了内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源很多。根据经验，us+sy的参考值为80%,如果us+sy大于80%说明可能存在CPU资源不足。id列显示了CPU处在空闲状态的时间百分比。Wa列显示了10等待所占用的CPU时间百分比。Wa值越高，说明IO等待越严重，根据经验，Wa的参考值为20%,如果Wa超过20%,说明IO等待严重,引起IO等待的原因可能是磁盘大量随机读写造成的，也可能是磁盘或者磁盘控制器的带宽瓶颈造成的（主要是块操作）。综上所述，在对CPU的评估中，需要重点注意的是procs项r列的值和CPU项中us、Sy和id列的值。（2） iostat（需要安装SySStat工具包）iostat是I/OStatiStiCS（输入/输出统计）的缩写，主要的功能是对系统的磁盘I/O操作进行监视。常用方式：iostat-c35其中，-C表示显示CPU的使用情况，-d：显示磁盘的使用情况。（3） uptime命令uptime是监控系统性能最常用的一个命令，主要用来统计系统当前的运行状况，输出的信息依次为：系统现在的时间、系统从上次开机到现在运行了多长时间、系统目前有多少登陆用户、系统在一分钟内、五分钟内、十五分钟内的平均负载。2、内存性能评估（1） free命令free命令是监控Iinux内存使用状况最常用的指令常见用法：free-m看下面的一个输出：root*ebserverfree-mtotalusedfreesharedbufferscachedMera:8111718592502436299-/+buffers/cache:6437468Swap:818908189“free-m”表示以M为单位查看内存使用情况，在这个输出中，我们重点关注的应该是free列与CaChed列的输出值，由输出可知，此系统共8G内存，系统空闲内存还有925M,其中，BufferCache占用了243M,PageCache占用了6299M,由此可知系统缓存了很多的文件和目录，而对于应用程序来说，可以使用的内存还有7468M,当然这个7468M包含了BUffelCaChe和PageCaChe的值。在SW叩项可以看出，交换分区还未使用。所以从应用的角度来说，此系统内存资源还非常充足。一般有这样一个经验公式：应用程序可用内存/系统物理内存70%时，表示系统内存资源非常充足，不影响系统性能，应用程序可用内存/系统物理内存<20%时，表示系统内存资源紧缺，需要增加系统内存，20%<应用程序可用内存/系统物理内存70%时，表示系统内存资源基本能满足应用需求，暂时不影响系统性能。（2） sar/pidstat此两个命令主要用于监控全部或指定进程占用系统资源的情况，如CPU,内存、设备IOo三个公用参数：-U（获取CPU状态）、（获取内存状态）、-d（获取磁盘）常用组合：sar-u3获取cpu3秒内的状态pidstat-r-pl3获取内存3秒内的状态看看以上两个命令的差别？请看下面的一个输出：rootwebserversar-r231.inux2.6.9-42.ELsap(webserver)11/30/2008_i686_(8CPU)09:57:33PMkbmcmfreckbmemused%mef11usodkbbufferskbcachedkbconit%commit09:57:35PM897988740855689.192494286496532786三4.7109:57:37PM898564740798089.1824942864965327842764.7009:57:39PM899196740734889.1724944064965207821324.69Average:898583740796189.1824943264965287843214.70其中：Kbmemfree表示空闲物理内存大小,kbmemused表示已使用的物理内存空间大小，memused表示已使用内存占总内存大小的百分比，kbbuffers和kbcached分别表示BufferCache和PageCache的大小，kbcommit和commit分别表示应用程序当前使用的内存大小和使用百分比。可以看出sar的输出其实与free的输出完全对应，不过sar更加人性化，不但给出了内存使用量，还给出了内存使用的百分比以及统计的平均值。从commit项可知，此系统目前内存资源充足。3、磁盘性能评估(1) )iostat-d组合iostat-d23通过“iostat-d”命令组合也可以查看系统磁盘的使用状况，请看如下输出：rootrebserver#iostat-d23i686_(8CPU)Linux2.6.9-42.ELsmp(webserver)12/01/2008Device:tpsBlk_read/sBIk_WrtnZSBlhreadBIkJrrInsda1.872.58114.126479462286537372Device:tpsBlk_read/sBlkJrtn/sBlk.readBlk_wrtnsda0.000.000.0000Device:tpsBlk_read/sBIhWrtn/sBlkreadBIkJTlnsda1.000.0012.00024对上面每项的输出解释如下：Blk-reads表示每秒读取的数据块数。Blk_wrtn/s表示每秒写入的数据块数。Blk.read表示读取的所有块数。Blk_wrtn表示写入的所有块数。(2) pidstat-d-p318873(3) sar-d23通过“sar-d”组合，可以对系统的磁盘IO做一个基本的统计，请看下面的一个输出：rootftrebserversar-d23Linux2.6.9-42.ELsmp(WebSerVer)11/30/2008i686(8CPU)11:09:33PMDEVtpsrd_sec/swr_scc/savgrq-szavgqu-szavaitsvct>%util11:09:35PMdev8-00.000.000.000.000.000.000.000.0011:09:35PMDEVtpsrd_sec/swr_sec/savgrq-szavgqu-szavaitsvctm%util11:09:37PMdev8-01.000.0012.0012.000.000.000.000.0011:09:37PMDEVtpsrd_sec/swr_sec/savgrq-szavgqu-szawaitsvctm%uti111:09:39PMdev8-01.990.0047.7624.000.000.500.250.05Average:DEVtpsrd_sec/swr_sec/savgrq-szavgqu-szawaitsvctm¼utilAverage:dcv8-011.000.0019.9720.000.000.330.170.02对上面每项的输出解释如下：DEV表示磁盘设备名称。tps表示每秒到物理磁盘的传送数，也就是每秒的I/O流量。一个传送就是一个I/O请求，多个逻辑请求可以被合并为一个物理I/O请求。rd_sec/S表示每秒从设备读取的扇区数（1扇区=512字节）。wr_sec/s表示每秒写入设备的扇区数目。avgrq-sz表不平均每次设备I/O操作的数据大小（以扇区为单位）。avgqu-sz表示平均I/O队列长度。await表示平均每次设备I/O操作的等待时间（以亳秒为单位）。svctm表示平均每次设备I/O操作的服务时间（以毫秒为单位）。util表示一秒中有百分之几的时间用于I/O操作。1.inux中I/O请求系统与现实生活中超市购物排队系统有很多类似的地方，通过对超市购物排队系统的理解，可以很快掌握IinUX中I/O运行机制。比如：avgrq-sz类似于超市排队中每人所买东西的多少。avgqu-sz类似于超市排队中单位时间内平均排队的人数。await类似于超市排队中每人的等待时间。svctm类似于超市排队中收银员的收款速度。util类似于超市收银台前有人排队的时间比例。对于磁盘IO性能，一般有如下评判标准：正常情况下svctm应该是小于await值的，而svctm的大小和磁盘性能有关,CPU、内存的负荷也会对SVCtm值造成影响，过多的请求也会间接的导致SVCtm值的增加。await值的大小一般取决于svctm的值和I/O队列长度以及I/O请求模式，如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于SVCtm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢，此时可以通过更换更快的硬盘来解决问题。UtiI项的值也是衡量磁盘I/O的一个重要指标，如果Util接近100%,表示磁盘产生的I/O请求太多，I/O系统已经满负荷的在工作，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。4、网络性能评估（1）ping命令请看下面的一个输出：rootwebserverping10.10.1.254PING10.10.1.254(10.10.1.254)56(84)bytesofdata.64bytesfrom10.10.1,254:icmpseq=0ttl=64time=0.235ms64bytesfrom10.10.1.254:icpseq=l111=64time=0.164ms64bytesfrom10.10.1.254:icmpseq=2tt1=64time=0.210ms64bytesfrom10.10.1.254:icmp_seq=3ttl=64time=0.178ms64bytesfrom10.10.1.254:icmpseq=4111=64time=0.525ms64bytesfrom10.10.1.254:icmpseq=5ttl=64time=0.571ms64bytesfrom10.10.1.254:icmpscq=6111=64time=0.220ms10.10.1.254pingstatistics7packetstransmitted,7received,0%packetloss,time6000msrttmin/avg/max/mdev-0.164/0.300/0.571/0.159ms,pipe2在这个输出中，time值显示了两台主机之间的网络延时情况，如果此值很大,则表示网络的延时很大，单位为毫秒。在这个输出的最后，是对上面输出信息的一个总结，PaCketk)SS表示网络的丢包率，此值越小，表示网络的质量越高。(2) netstat命令netstat-i(查看路由情况)netstat-r(查看网络接口状态)(3) mtr/traceroute命令跟踪网络路由状态，推荐使用mtr,动态跟踪网络路由，用于排除网络问题非常方便三、次统性能分析标准影响性能因素评判标准好环槽桂CPUuser¾+sysX<70%user%+sys¾=85%user%÷sys%>三90%内存SwtpIn(si)-0SwapOut(so)=0PrCPUwith10pacsUorSwapInASwtpOut磁盘iowait%<20%iowait%=3SXiowait»>=50%其中：%user：表示CPU处在用户模式下的时间百分比。%sys：表示CPU处在系统模式下的时间百分比。%iowait：表示CPU等待输入输出完成时间的百分比。swapin：即si,表示虚拟内存的页导入，即从SWAPDISK交换到RAM。全方位Linux性能调优经验总结PartlLinux性能优化1性能优化性能指标高并发和响应快对应着性能优化的两个核心指标：吞吐和延时应用负载角度：直接影响了产品终端的用户体验系统资源角度：资源使用率、饱和度等性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。选择指标评估应用程序和系统性能为应用程序和系统设置性能目标进行性能基准测试性能分析定位瓶颈性能监控和告整对于不同的总能问题要选取不同的性能分析工具。下面是常用的LinuxPerformanceTools以及对应分析的性能问题类型。到底应该怎么理解“平均负载”平均负载:单位时间内，系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数。它和我们传统意义上理解的CPU使用率并没有直接关系。其中不可中断进程是正处于内核态关键流程中的进程（如常见的等待设备的I/O响应）。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。平均负载多少时合理实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。当然也可以当设置阈值（如当平均负载高于CPU数量的70%时）现实工作中我们会经常混淆平均负载和CPU使用率的概念，其实两者并不完全对等：CPU密集型进程，大量CPU使用会导致平均负载升高，此时两者一致I/O密集型进程，等待I/O也会导致平均负载升高，此时CPU使用率并不一定高大量等待CPU的进程调度会导致平均负载升高，此时CPU使用率也会比较高平均负载高时可能是CPU密集型进程导致，也可能是I/O繁忙导致。具体分析时可以结合mpstat/pidstat工具辅助分析负载来源2CPUCPU上下文切换（上）CPU上下文切换，就是把前一个任务的CPU上下文（CPU寄存器和PO保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。按照任务类型，CPU上下文切换分为：进程上下文切换线程上下文切换中断上下文切换进程上下文切换1.inux进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。一次系统调用过程其实进行了两次CPU上下文切换：CPU寄存器中用户态的指令位置先保存起来，CPU寄存器更新为内核态指令的位置，跳转到内核态运行内核任务；系统调用结束后，CPU寄存器恢复原来保存的用户态数据，再切换到用户空间继续运行。系统调用过程中并不会涉及虚拟内存等进程用户态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。进程只有在调度到CPU上运行时才需要切换上下文，有以下几种场景：CPU时间片轮流分配，系统资源不足导致进程挂起，进程通过SIeeP函数主动挂起，高优先级进程抢占时间片，硬件中断时CPU上的进程被挂起转而执行内核中的中断服务。线程上下文切换线程上下文切换分为两种：前后线程同属于一个进程，切换时虚拟内存资源不变，只需要切换线程的私有数据，寄存器等；前后线程属于不同进程，与进程上下文切换相同。同进程的线程切换消耗资源较少，这也是多线程的优势。中断上下文切换中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态(CPU寄存器，内核堆栈，硬件中断参数等)。中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生Docker+K8s+Jenkins主流技术全解视频资料CPU上下文切换(下)通过Vmstat可以查看系统总体的上下文切换情况VmStat5#每隔5s输出一组数据procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwast10010338814541251105600186011219600000103388145412511076000245011761199000001033881454125110760008429113511980000010338814541251107600004311132119800000103388145412511076000104671195119800100103388145412511076000242611391099004009518414541251110800074500122841940000010351214541651107600045572315731238320cs(contextswitch)每秒上下文切换次数in(interrupt)每秒中断次数r(TunnningorrunnabIe)就绪队列的长度，正在运行和等待CPU的进程数b(Blocked)处于不可中断睡眠状态的进程数要查看每个进程的详细情况，需要使用pidstat来查看每个进程上下文切换情况pidstat-w514时51分16秒UIDPIDcswch/snvcswch/sCommand14时51分21秒Ol0.800.00SyStemd14时51分21秒061.400.0OkSoftirqd/014时51分21秒0932.670.00rcu_sched14时51分21秒OuO.400.00WatChdOg/014时51分21秒0320.200.（X）khugepaged14时51分21秒02710.200.00jbd2/vdal-814时51分21秒013320.200.00argusagent14时51分21秒0526510.020.00AliSecGuard14时51分21秒074397.820.0OkWOrker/0: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#首先获取空闲系统的上下文切换次数sysbenchthreads=10-max-time=300threadsnin#模拟多线程切换问题VmStat11#新终端观察上下文切换情况此时发现CS数据明显升高，同时观察其他指标：r列：远超系统CPU个数，说明存在大量CPU竞争US和Sy列：Sy列占比80%,说明CPU主要被内核占用in歹U：中断次数明显上升，说明中断处理也是潜在问题说明运行/等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高pidstat-w-u1#查看到底哪个进程导致的问题从结果中看出是sysbench导致CPU使用率过高，但是PidStat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。另外对于中断次数过多，我们可以通过procinterrupts文件读取watch-dcat/proc/interrupts发现次数变化速度最快的是重调度中断（RES）,该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。某个应用的CPU使用率达到100%,怎么办？1.inUX作为多任务操作系统，将CPU时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护CPU时间，LinUX通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以来的节拍数。时间中断发生一次该值+1。CPU使用率，除了空闲时间以外的其他时间占总CPU时间的百分比。可以通过procstat中的数据来计算出CPU使用率。因为procstat时开机以来的节拍数累加值，计算出来的是开机以来的平均CPU使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均CPU使用率。性能分析工具给出的都是间隔一段时间的平均CPU使用率，要注意间隔时间的设置。CPU使用率可以通过top或PS来查看。分析进程的CPU问题可以通过perf,它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。perftop/perfrecord/perfreport（-g开启调用关系的采样）sudodockerrunnamenginx-p10000:80-itdfeisky/nginxsudodockerrun-namephpfpm-itd-networkcontainer:nginxfeisky/php-fpmab-cl-nlOOhttp:/XXX.XXX.XXX.XXXXOOOO/#测试Nginx服务性能发现此时每秒可承受请求给长少,此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个CPU的使用率。发现系统中几个php-fpm进程导致CPU使用率骤升。接着用perf来分析具体是php-fpm中明E个函数导致该问题。PerftOP-g-pXXXX#对某一个php-fpm进程进行分析发现宾中sqrt和add_function占用CPU过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升系统的CPU使用率很高，为什么找不到高CPU的应用？sudodockerrunnamenginx-p10000:80-itdfeisky/nginx:spsudodockerrun-namephpfpm-itdnetworkcontainer:nginxfeisky/php-fpm:spab-cl00-nl000http:XXX.XXX.XXX.XXX:10000/#并发100个请求测试实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，nginx负载能力依旧很低。此时用t。P和PidStat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于RUnning状态的进行过多，超过了我们的并发请求次数5.再仔细查看进程运行数据，发现nginx和php-fpm都处于sleep状态，真正处于运行的却是几个stress进程。下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用psaux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现StreSS进程的进程号变化了，此时有可能时以下两种原因导致：进程不停的崩溃重启（如段错误/配置错误等），此时进程退出后可能又被监控系统重启；短时进程导致，即其他应用内部通过exec调用的外面命令，这些命令一般只运行很短时间就结束，很难用top这种间隔较长的工具来发现可以通过PStree来查找StreSS的父进程，找出调用关系。Pstreelgrepstress发现是php-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个StreSS命令来模拟1/0压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=l的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bugo此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的CPU,通过修复权限问题来优化解决即可.系统中出现大量不可中断进程和僵尸进程怎么办？进程状态RRunningZRunnable,表示进程在CPU的就绪队列中，正在运行或者等待运行；DDiskSleep,不可中断状态睡眠，一般表示进程正在跟硬件交互，并且交互过程中不允许被其他进程中断；ZZombie,僵尸进程，表示进程实际上已经结束,但是父进程还没有回收它的资源；SlnterruptibleSleep,可中断睡眠状态，表示进程因为等待某个事件而被系统挂起，当等待事件发生则会被唤醒并进入R状态;IIdle,空闲状态，用在不可中断睡眠的内核线程上。该状态不会导致平均负载升高；TStoP"raced,表示进程处于暂停或跟踪状态(SIGSToP/SIGCONT,GDB调试)；XDead,进程已经消亡，不会在top/ps中看到。对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了I/O性能问题。僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。磁盘0.DIRECT问题sudodockerrun-privilegedname=app-itdfeisky/app:iowaitpsauxgrep7app,可以看到此时有多个app进程运行，状态分别时Ss+和D+。其中后面S表示进程是一个会话的领导进程，十号表示前台进程组。其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。用top查看系统资源发现：1)平均负载在逐渐增加，且1分钟内平均负载达到了CPU个数，说明系统可能已经有了性能瓶颈；2)僵尸进程比较多且在不停增加；3)US和SySCPU使用率都不高，iowait却比较高；4)每个进程CPU使用率也不高，但有两个进程处于D状态，可能在等待10。分析目前数据可知：i。Wait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。用dstat来分析，因为它可以同时查看CPU和I/O两种资源的使用情况，便于对比分析。dstatllO#间隔1秒输出10组数据可以看到当Wai(iowait)升高时磁盘请求read都会很大，说明iowait的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。之前top查看的处于D状态的进程号，用pidstat-d-pXXX展示进程的1/0统计数据。发现处于D状态的进程都没有任何读写操作。在用pidstat-d查看所有进程的1/0统计数据，看到app进程在进行磁盘读操作，每秒读取32MB的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到app进程的系统调用。SUdOStraCe-pXXX#对app进程调用进行跟踪报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。PS命令查找该进程已经处于Z状态，即僵尸进程。这种情况下toppidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perfrecord-d和perfreport进行分析，查看app进程调用栈。看到app确实在通过系统调用sys_read()读取数据，并且从new_sync_read和blkdev_directO看出进程时进行直戛读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。通过层层分析后，rootcause是app内部进行了磁盘的直接I/O。然后定位到具体代码位置进行优化即可。僵尸进程上述优化后i。Wait显著下降，但是僵尸进程数量仍旧在增加。首先要定位僵尸进程的父进程，通过pstree-apsXXX,打印出该僵尸进程的调用树，发现父进程就是即P进程。查看叩P代码，看看子进程结束的处理是否正确(是否调用Wait()waitpid(),有没有注册sigchild信号的处理函数等)。碰到iowait升高时，先用dstatpidstat等工具确认是否存在磁盘I/O问题，再找是哪些进程导致I/O,不能用strace直接分析进程调用时可以通过perf工具分析。对于僵尸问题，用PStree找到父进程，然后看源码检查子进程结束的处理逻辑即可。CPU性能指标CPU使用率用户CPU使用率,包括用户态(USer)和低优先级用户态(nice)该指标过高说明应用程序比较繁忙。系统CPU使用率,CPU在内核态运行的时间百分比(不含中断).该指标高说明内核比较繁忙。等待I/O的CPU使用率,iowait,该指标高说明系统与硬件设备I/O交互时间比较长。软/硬中断CPU使用率;该指标高说明系统中发生大量中断。StealCPU/guestCPU,表示虚拟机占用的CPU百分比。平均负载理想情况下平均负载等于逻辑CPU个数,表示每个CPU都被充分利用.若大于则说明系统负载较重。进程上下文切换包括无法获取资源的自愿切换和系统强制调度时的非自愿切换.上下文切换本身是保证Linux正常运行的一项核心功能.过多的切换则会将原本运行进程的CPU时间消耗在寄存器,内核占及虚拟内存