本文是通过学习倪朋飞老师的《Linux性能优化实战》 :CPU 性能优化的几个思路?
前面我们学习了常见的 CPU 性能指标,梳理了核心的 CPU 性能观测工具,最后还总结了快速分析 CPU 性能问题的思路。虽然 CPU 的性能指标很多,相应的性能分析工具也很多,但理解了各种指标的含义后,就会发现它们其实都有一定的关联。
顺着这些关系往下理解,就会发现,掌握这些常用的瓶颈分析套路,其实并不难。
在找到 CPU 的性能瓶颈后,下一步要做的就是优化了,也就是找出充分利用 CPU 的方 法,以便完成更多的工作。
在我们历经千辛万苦,通过各种性能分析方法,终于找到引发性能问题的瓶颈后,是不是立刻就要开始优化了呢?别急,动手之前,我们可以先看看下面这三个问题。
如果可以轻松回答这三个问题,那么二话不说就可以开始优化。
比如,在前面的不可中断进程案例中,通过性能分析,我们发现是因为一个进程的直接 I/O ,导致了 iowait 高达 90%。那是不是用“直接 I/O 换成缓存 I/O”的方法,就可以立即优化了呢?
按照上面讲的,可以先自己思考下那三点。如果不能确定,我们一起来看看。
好的,这三个问题很容易就能回答,所以立即优化没有任何问题。
但是,很多现实情况,并不像上面的例子那么简单。性能评估可能有多重指标,性能问题可能会多个同时发生,而且,优化某一个指标的性能,可能又导致其他指标性能的下降。
那么,面对这种复杂的情况,该怎么办呢?
接下来,我们就来深入分析这三个问题。
首先,来看第一个问题,怎么评估性能优化的效果。
我们解决性能问题的目的,自然是想得到一个性能提升的效果。为了评估这个效果,我们需要对系统的性能指标进行量化,并且要分别测试出优化前、后的性能指标,用前后指标的变化来对比呈现效果。我把这个方法叫做性能评估“三步走”。
先看第一步,性能的量化指标有很多,比如 CPU 使用率、应用程序的吞吐量、客户端请求的延迟等,都可以评估性能。那我们应该选择什么指标来评估呢?
我们不要局限在单一维度的指标上,至少要从应用程序和系统资源这两个维度, 分别选择不同的指标。比如,以 Web 应用为例:
之所以从这两个不同维度选择指标,主要是因为应用程序和系统资源这两者间相辅相成的关系。
至于接下来的两个步骤,主要是为了对比优化前后的性能,更直观地呈现效果。如果你的第一步,是从两个不同维度选择了多个指标,那么在性能测试时,你就需要获得这些指标的具体数值。
还是以刚刚的 Web 应用为例,对应上面提到的几个指标,我们可以选择 ab 等工具,测试 Web 应用的并发请求数和响应延迟。而测试的同时,还可以用 vmstat、pidstat 等性能工具,观察系统和进程的 CPU 使用率。这样,我们就同时获得了应用程序和系统资源这两个维度的指标数值。
不过,在进行性能测试时,有两个特别重要的地方需要注意下。
系统性能总是牵一发而动全身,所以性能问题通常也不是独立存在的。那当多个性能问题同时发生的时候,应该先去优化哪一个呢?
性能测试的领域,流传很广的一个说法是“二八原则”,也就是说 80% 的问题都是由 20% 的代码导致的。只要找出这 20% 的位置,你就可以优化 80% 的性能。所以,并不是所有的性能问题都值得优化。
所以我们在,动手优化之前先动脑,先把所有这些性能问题给分析一遍,找出最重要的、可以最大程度提升性能的问题,从它开始优化。这样的好处是,不仅性能提升的收益最大,而且很可能其他问题都不用优化,就已经满足了性能要求。
那关键就在于,怎么判断出哪个性能问题最重要。这其实还是我们性能分析要解决的核心问题,只不过这里要分析的对象,从原来的一个问题,变成了多个问题,思路其实还是一样的。
所以,依然可以用前面讲过的方法挨个分析,分别找出它们的瓶颈。分析完所有问题后,再按照因果等关系,排除掉有因果关联的性能问题。最后,再对剩下的性能问题进行优化。
如果剩下的问题还是好几个,就得分别进行性能测试了。比较不同的优化效果后,选择能明显提升性能的那个问题进行修复。这个过程通常会花费较多的时间,这里,推荐两个可以简化这个过程的方法。
当多种方法都可用时,应该选择哪一种呢?是不是最大提升性能的方法,一定最好呢?一般情况下,我们当然想选能最大提升性能的方法,这其实也是性能优化的目标。
但要注意,现实情况要考虑的因素却没那么简单。最直观来说,性能优化并非没有成本。 性能优化通常会带来复杂度的提升,降低程序的可维护性,还可能在优化一个指标时,引发其他指标的异常。也就是说,很可能你优化了一个指标,另一个指标的性能却变差了。
一个很典型的例子是网络中的 DPDK(Data Plane Development Kit)。 DPDK 是一种优化网络处理速度的方法,它通过绕开内核网络协议栈的方法,提升网络的处理能力。不过它有一个很典型的要求,就是要独占一个 CPU 以及一定数量的内存大页,并且总是以 100% 的 CPU 使用率运行。所以,如果 CPU 核数很少,就有点得不偿失了。
所以,在考虑选哪个性能优化方法时,要综合多方面的因素。切记,不要想着“一步登天”,试图一次性解决所有问题;也不要只会“拿来主义”,把其他应用的优化方法原封不动拿来用,却不经过任何思考和分析。
清楚了性能优化最基本的三个问题后,我们接下来从应用程序和系统的角度,分别来看看如何才能降低 CPU 使用率,提高 CPU 的并行处理能力。
首先,从应用程序的角度来说,降低 CPU 使用率的最好方法当然是,排除所有不必要的工 作,只保留最核心的逻辑。比如减少循环的层次、减少递归、减少动态内存分配等等。
除此之外,应用程序的性能优化也包括很多种方法,这里列出了最常见的几种,可以记下来。
从系统的角度来说,优化 CPU 的运行,一方面要充分利用 CPU 缓存的本地性,加速缓存访问;另一方面,就是要控制进程的 CPU 使用情况,减少进程间的相互影响。
具体来说,系统层面的 CPU 优化方法也有不少,这里同样列举了最常见的一些方法,方便我们记忆和使用。
掌握上面这些优化方法后,估计,很多人即使没发现性能瓶颈,也会忍不住把各种各样的优化方法带到实际的开发中。
不过,我们一定要记住高德纳的这句名言, “过早优化是万恶之源”,我也非常赞同这一点,过早优化不可取。
因为,一方面,优化会带来复杂性的提升,降低可维护性;另一方面,需求不是一成不变的。针对当前情况进行的优化,很可能并不适应快速变化的新需求。这样,在新需求出现时,这些复杂的优化,反而可能阻碍新功能的开发。
所以,性能优化最好是逐步完善,动态进行,不追求一步到位,而要首先保证能满足当前的性能要求。当发现性能不满足要求或者出现性能瓶颈时,再根据性能评估的结果,选择最重要的性能问题进行优化。
今天,我们梳理了常见的 CPU 性能优化思路和优化方法。发现性能问题后,不要急于动手优化,而要先找出最重要的、可以获得最大性能提升的问题,然后再从应用程序和系统两个方面入手优化。
这样不仅可以获得最大的性能提升,而且很可能不需要优化其他问题,就已经满足了性能要求。
但是记住,一定要忍住“把 CPU 性能优化到极致”的冲动,因为 CPU 并不是唯一的性能因素。还有更多的性能问题,比如内存、网络、I/O 甚至是架构设计的问题。
如果不做全方位的分析和测试,只是单纯地把某个指标提升到极致,并不一定能带来整体的收益。
某某自来水业务系统,是一套适合各种规模自来水公司的网络版自来水多种类业务管理软件。根据各大自来水公司存在的问题和需求自主...
某某自来水业务系统,是一套适合各种规模自来水公司的网络版自来水多种类业务管理软件。根据各大自来水公司存在的问题和需求自主...
某某自来水业务系统,是一套适合各种规模自来水公司的网络版自来水多种类业务管理软件。根据各大自来水公司存在的问题和需求自主...
某某自来水业务系统,是一套适合各种规模自来水公司的网络版自来水多种类业务管理软件。根据各大自来水公司存在的问题和需求自主...