【linux性能优化】CPU性能优化思路 |
您所在的位置：网站首页 › linux内存优化思路 › 【linux性能优化】CPU性能优化思路 |
【linux性能优化】CPU性能优化思路
|
一、CPU性能指标
1.1 CPU使用率
用户态CPU使用率(user)低优先级用户态CPU使用率(nice)系统CPU使用率等待IO的CPU使用率(iowait)软中断和硬中断的CPU使用率
1.2 平均负载
理想情况下，平均负载等于逻辑CPU个数，说明CPU刚好全部被利用，如果大于逻辑CPU个数，说明平均负载比较重 1.3 进程上下文切换自愿上下文切换和非自愿上下文切换 过多的上下文切换，会将原本进行进程的CPU时间，消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行时间，成为性能瓶颈 1.4 CPU缓存命中率CPU缓存速度介于CPU和内存之间，缓存的是热点的内存数据 这些缓存按照大小分为L1、L2、L3等三级缓存，L1、L2常用在单核上，L3则用在多核中，大小依次增大，性能依次降低(当然还是速度还是远优于内存) 而他们的命中率，则是衡量CPU缓存复用情况，命中率越高，性能越好
性能指标和性能工具的联系 2.1 从CPU的性能指标维度当要查看某个性能指标时，要清楚知道可以使用哪些性能工具 性能指标工具说明平均负载top提供相对全面的指标系统整体CPU使用率vmstat、mpstat、top、/proc/stattop、vmstat、mpstat只可以动态查看，/proc/stat是其他性能工具的数据来源进程CPU使用率top、pidstat、ps、htop、atoptop和ps可以按CPU使用率给进程排序，而pidstat只显示了CPU的进程，htop和atop以不同颜色显示更直观系统上下文切换vmstat除了上下文切换次数，还提供运行状态和不可中断状态进程的数量进程上下文切换pidstat注意加上-w选项软中断top、/proc/softirqs、mpstattop提供软中断CPU使用率，而/proc/softirqs和mpstat提供了各种软中断在每个CPU上运行的次数硬中断vmstat、/proc/interruptsvmstat提供总的中断次数，而/proc/interrupts提供了各种中断在每个CPU上运行的累积次数网络dstat、tcpdumpdstat提供总的网络接收和发送情况，而tcpdump则是动态抓取正在进行的网络通讯I/Odstatdstat提供了I/O的整体情况CPU个数/proc/cpuinfo、IscpuIscpu更直观事件剖析perf、execsnoopperf用来分析CPU缓存以及内核调用链，execsnoop用来监控短时进程 2.2 从工具的维度从工具出发，如果安装了某个工具，要知道这个工具能提供哪些指标 性能工具CPU性能指标top平均负载、运行队列、整体CPU使用率以及每个进程的状态和CPU使用率htoptop增强版，以不同颜色区分不同类型的进程，更直观atopCPU、内存、磁盘和网络等各种资源的全面监控vmstat系统整体的CPU使用率、上下文切换次数、中断次数、处于运行和不可中断状态的进程数量mpstat每个CPU的使用率和软中断次数pidstat进程和线程的CPU使用率、中断上下文切换次数/proc/softirqs软中断类型和在每个CPU的累积中断次数/proc/interrupts硬中断类型和在每个CPU的累积中断次数ps每个进程的状态和CPU使用率pstree进程的父子关系dstat系统整体的CPU使用率sar系统整体的CPU使用率，包括可配置的历史数据strace进程的系统调用perfCPU性能事件剖析，如调用链分析、CPU缓存、CPU调度等execsnoop监控短时进程 三、优化思路 3.1 优化前三连问 如何判断优化有效多个问题优先处理解决方案如何选择 3.2 问题一：如何判断优化有效怎么判断优化是否有效？特别是优化后到底能提升多少性能呢？ 数据时间点测试优化前的性能指标 测试优化后的性能指标 性能量化指标CPU使用率 应用程序吞吐量 客户端请求的延迟等 原则不局限于单一维度的指标 栗子web应用为例 应用程序维度：吞吐量和请求延迟来评估应用性能 系统资源维度：CPU使用率评估系统用情况 维度选取原因 应用程序和系统资源两者是相辅相成 应用程序能提供的能力是性能优化的最终目的和结果，系统优化总是为应用程序服务 系统资源的使用情况是影响应用程序性能的根源，需要用系统资源的指标观察和分析瓶颈的来源 注意点在进行性能测试时，需要特别注意： 避免性能测试工具干扰应用程序的性能 通常web 应用，性能测试工具跟目标应用程序要在不同的机器上运行 避免外部环境的变化影响性能指标的评估 要求优化前、后的应用程序都运行在相同配置的机器上，并且它们的外部依赖也要完全一致 3.3 问题二：多个问题优先处理系统性能总是牵一发而动全身，所以性能问题通常并不是独立存在的。那当多个性能问题同时发生的时候，应该先去优化哪一个呢？ 二八原则在性能测试领域，流传很广的一个说法是"二八原则"，也就是80%的问题是由20%代码导致的。只要找出这20%的位置，就可以优化80%的性能，所以也可以说并不是所有的性能问题都值得优化 问题梳理在优化前把所有性能问题分析一遍，找出最重要的、能最大提升性能的问题，从它开始，这样的好处是，不仅性能提升的收益最大，而且很可能其他问题都不用优化，就已经满足了性能要求 挨个分析，分别找出性能问题的瓶颈，分析完所有问题后，再按照因果等关系，排除掉有因果关联的性能问题，最后，再对剩下的性能问题进行优化 通常剩下的问题很有可能不止一个，那么就要分别做性能测试，比较不同的优化效果后，选择最能提升性能的那个问题修复 简化技巧推荐两个可以简化这个过程的方法： 优先优化系统资源使用的问题如果发现是系统资源达到了瓶颈，比如 CPU 使用率达到100%，那么首先优化的一定是系统资源使用问题 完成系统资源瓶颈的优化后，我们才要考虑其他问题 优先优化变化幅度最大的问题针对不同类型的指标，首先去优化那些由瓶颈导致的，性能指标变化幅度最大的问题 比如产生瓶颈后，用户CPU使用率升高了10%，而系统CPU使用率却升高了 50%，这个时候就应该首先优化系统CPU的使用 3.4 问题三：解决方案如何选择提升性能方法不唯一，要选哪种，是不是一定选提升最大的那一种？ 一般情况下，我们当然想选能最大提升性能的方法，这其实也是性能优化的目标 注意：现实情况要考虑的因素往往并没那么简单，性能优化并非没有成本 性能优化通常会带来复杂度的提升，降低程序的可维护性，甚至还很有可能在优化一个指标时，引发其他指标的异常，也就是说，很可能你优化了一个指标，另一个指标的性能却变差了 四、CPU优化清楚了以上三个问题后，接下来从应用程序和系统角度，来看看如何降低CPU使用率，提高CPU并行处理能力 4.1 应用程序优化编译器优化 比如gcc编译器，提供了优化选项-O2，开启后会自动对应用程序代码进行优化 算法优化 使用复杂度低的算法，可以明显加快处理速度 异步处理 可以避免程序因等待某个资源而一直阻塞，从而提升程序并发处理能力 比如：事件通知替换掉轮询，可以避免轮询耗费的CPU问题 多线程处理 多线程代替多进程，可以降低上下文切换成本 善用缓存 经常访问的数据或者计算过程中的步骤，放到内存中，下次用时直接取，加快处理速度 4.2 系统优化从系统的角度来说，优化CPU的运行 充分利用CPU缓存的本地性，减速缓存访问控制进程的CPU使用情况，减少进程间的相互影响具体的优化手段： CPU绑定 把进程绑定到一个或多个CPU上，可以提高CPU缓存的命中率，减少跨CPU调度带来的上下文切换问题 CPU独占 跟绑定类似，进一步将CPU分组，根据CPU亲和性机制为其分配进程，这些CPU由指定进程独占，其他进程不能去使用它 优先级调整 使用nice调整进程的优先级，适当的调低非核心应用的优先级，增高核心应用的优先级，可以确保核心应用得到优先处理 为进程设置资源限制 使用Linux cgroups 来设置CPU使用上限，可以防止因某个应用自身的问题，耗尽系统资源 NUMA(Non-Uniform Memory Access)优化 支持 NUMA 的处理器会被划分为多个node，每个node都有自己的本地内存空间，就是让CPU尽可能只访问本地内存 中断负载均衡 开启 irqbalance 服务或者配置 smp_affinity，可以把中断处理过程负载均衡到多个CPU 五、切忌过早优化过早优化是万恶之源 性能优化最好是逐步完善，动态进行，不追求一步到位，而要首先保证能满足当前的性能需求，当发现性能不满足要求或者出现性能瓶颈时，再根据性能评估的结果，选择最重要的性能问题进行优化 引起问题 优化会带来复杂性的提升，降低可维护性需求不是一成不变，针对当前情况进行的优化，很可能并不适应快速变化的新需求在新需求出现时，这些复杂的优化，反而可能阻碍新功能的开发 性价比CPU性能优化到极致的做法性价比不高，因为 CPU 并不是唯一的性能因素，还有其他的性能问题，比如内存、网络、I/O 甚至是架构设计的问题 如果不做全方位的分析和测试，只是单纯地把某个指标提升到极致，并不一定能带来整体的收益 |
【本文地址】
今日新闻 |
推荐新闻 |