站长工具seo综合查询怎么关闭,湖南关于新冠最新通知,sns网站社区需求分析文档,app平台搭建步骤10.0 概述
本章包含了一个例子#xff1a;如何用Linux性能工具在受CPU限制的应用程序中寻找并修复性能问题。 阅读本章后#xff0c;你将能够#xff1a;
在受CPU限制的应用程序中明确所有的CPU被哪些源代码行使用。用1trace和oprofile弄清楚应用程序调用各种内部与外部函…10.0 概述
本章包含了一个例子如何用Linux性能工具在受CPU限制的应用程序中寻找并修复性能问题。 阅读本章后你将能够
在受CPU限制的应用程序中明确所有的CPU被哪些源代码行使用。用1trace和oprofile弄清楚应用程序调用各种内部与外部函数的频率。在应用程序源代码内寻找模式在线搜索应用程序的行为表现与可能的解决方案。以本章为模板跟踪与CPU相关的性能问题。
10.1受CPU限制的应用程序
本章的调查对象是一个受CPU限制的应用程序。其重点在于能够对受CPU限制的应用程序进行优化因为这是最常见的性能问题之一。 通常这也是高度调优的应用程序的最后战线。 当消除了磁盘和网络瓶颈后一个应用程序就变成了受CPU限制的。此外与改进CPU相比购买更快的磁盘或更多的内存要容易得多因此如果程序是受CPU限制的那么比起仅仅买一个新系统来说能够追踪并修复CPU性能问题就是一项重要技能了。
10.2 确定问题
性能追踪的第一步是确定要调查的问题。本例中我选择调查使用GIMP时出现的性能问题GIMP是一个开源的图像处理程序。它能对一个图像的各个方面进行分割但它也有一组强大的过滤器能够用多种方式对图像进变形和修改。这些过滤器根据一些复杂的算法来改变图像的外观。通常情况下过滤器的工作需要很长时间才能完成并且非常耗费CPU资源。特别是其中的一个过滤器Von Gogh(梵高LIC),它接收一个图像为输入将其修改为看上去像梵高风格的画作。这个过滤器所花费的时间特别长。过滤器运行时使用了几乎100%的CPU资源且完成时间长达几分钟。完成时长涉及的因素包括图像大小、机器CPU的速度以及传递给过滤器的参数值。本章中我们用Linux性能工具调查为什么这个过滤器这么慢同时还要弄清楚是否有方法能提高它的速度。
10.3 找到基线/设置目标
任何性能追踪的第一步就是要确定问题当前的状况。对GIMP过滤器而言我们需要确定它在特定图像上运行要花多少时间这就是基准时间。一旦掌握了这个基准时间接下来就可以尝试优化看看是否减少了它的执行时间。有时候计量某个工作耗费的时间是很难的不像拿个秒表那么简单因为当我们相当耗费CPU资源的作业正在运行的时候操作系统可能会调度其他任务。在这种情况下如果除了计算密集型作业之外还有其他作业也在运行那么墙钟时间也许会大大超过该进程实际使用的CPU时间。就这点来说我们是幸运的当运行过滤器时通过观察top,可以看到lic进程占用了绝大部分的CPU使用量如清单10.1所示。 由此我们可以推断在运行过滤器时GIMP实际上派生出一个独立进程来运行。因此当过滤器运行时我们就可以利用ps来追踪该进程消耗了多少CPU时间以及它是什么时候结束的。知道了使用top的过滤器的PID之后可以运行清单10.2中的循环要求ps周期性地观察该过滤器使用了多少CPU时间。
如果在没有秒表的情况下对一个应用程序计你可以把time和cat当作简易的秒表来用。只需在想要开始计时的时候键入time cat,然后在结束时按下Ctrl-D组合键即可。time将会显示已经过的时间。在参照图像(从我的地下室获取的图片)上运行lic过滤器并用刚才描述的ps方法对该过滤器计时我们可以从清单10.2中看出来处理整个图像花费了2分46秒。这个时间就是我们的基准时间。既然知道了该过滤器直接运行耗费的时间我们就可以设置本次性能追踪的目标了。如何为性能调查设置合理的目标并非总是清晰明了的。一个合理的目标值取决于多个因素包括根据特定问题和用户需求已经完成的调优。通常最好的方法是以有相同情况且性能更快的应用程序为基础来设置目标。可惜的是我们不知道还有哪个GIMP过滤器是完成类似工作的因此我们必须做出猜测。对一段相对未调优的代码来说一般5%10%的性能优化是一个合理的目标所以我们设定了10%的速度提升即运行时间为2分30秒。 既然目标已经挑好了我们就需要一种方法来保证我们的调优带给过滤器结果的变化是可以接受的。此时我们将在参照图像上运行初始过滤器并把其结果记录在另一个文件中。这样我们可以将优化后的过滤器输出与初始过滤器输出进行比较看看优化是否改变了输出。
10.4 为性能追踪配置应用程序
我们调查的下一步是为性能追踪设置应用程序用符号重新编译该程序。符号能让性能工具(比如oprofile)调查哪些函数和源代码行消耗了CPU时间。 回到GIMP,我们从其网站下载最新的GIMP源代码压缩包然后重新编译它。对GIMP和许多开源软件来说重新编译的第一步就是运行configure命令产生将用于构建应用程序的生成文件。configure命令向生成文件传递出现在CFLAGS环境变量中的所有标志。在这种情况下由于我们希望用符号构建GIMP,因此设置的CFLAGS变量含有-g3。这就使得符号包含在生成的二进制文件中。清单10.3显示了这个命令覆盖了CFLAGS环境变量的当前值并将其设置为-g3。 之后我们生成并安装包含所有符号的GIMP版本当运行这个版本时性能工具将会告诉我们时间都消耗在了哪里。
10.5安装和配置性能工具
如果性能工具还没有安装那么追踪的下一步就是安装它们。尽管看上去这是件容易的事儿但它常常涉及跟踪定制包的分发甚至是从头开始对工具进行重新编译。本例中我们在Fedora Core 2上使用oprofile,因此我们既要跟踪oprofile内核模块(在Fedora 下它只包含在对称多处理(SMP)内核中),也要跟踪oprofile软件包。同样可能让人觉得有意思的还有用ltrace性能工具查看被调用的库函数及其被调用的频率。幸运的是Itrace 包含在Fedora Core 2中所以我们不需要跟踪它。
10.6运行应用程序和性能工具
接下来我们运行应用程序并用性能工具进行测量。由于lic过滤器直接由GIMP调用因此我们使用的工具必须能够附加到已运行进程且能对其进行监控。 对oprofile来说我们启动oprofile,运行过滤器然后在过滤器完成工作后停止oprofile。因为lic过滤器在运行时占用了将近90%的CPU,所以oprofile收集的系统整体样本将主要与lic过滤器相关。当lic开始运行时我们在另一个窗口启动oprofile。当lic 结束时我们停止oprofile。oprofile的启动和停止如清单10.4所示。 运行ltrace必定存在一点差异。在过滤器启动后ltrace可以附加到运行中的进程上。与oprofile不同ltrace附加到进程后会降低整个进程的速度。这会导致每个库的调用时间增加一些误差但是它却提供了每个调用的次数信息。ltrace如清单10.5所示。 要获得库调用的全部数量可以让ltrace持续运行直到完成。但是这需要很多的时间所以在这种情况下经过一段较长时间后就按下组合键。这个方法不见得总是有效原因在于应用程序可能会经历不同的执行阶段如果停止时间过早可能就无法得到应用程序调用函数的完整信息。不过这个短小的样本至少是我们分析的起点。
10.7分析结果
既然我们已经利用oprofile收集到了过滤器运行的时间信息现在就必须对结果进行分析寻找改变其执行和提高其性能的方法。 首先我们用oprofile查看整个系统是如何消耗时间的结果如清单10.6所示。 如清单10.6所示75%的CPU时间消耗在了lic进程或与GIMP相关的库上。极有可能这些库是被lic进程调用的结合ltrace给我们的信息与oprofile给出的信息我们可以确认这个事实。清单10.7显示了过滤器运行一小部分的情况下进行的库调用。 接下来我们要调查oprofile提供的关于每个库内部CPU时间消耗的信息看看库中的热点函数是否与过滤器调用的那些一致。对于最占用CPU时间的前三个库我们要求opreport提供库内每一个函数时间消耗的详细信息。libgimp、libgimp-color库和lic进程的结果显示在清单10.8中。 通过比较清单10.8中的ltrace输出和清单10.9中的oprofile输出可以得知lic过滤器反复调用的库函数消耗了全部时间。 接下来我们调查lic过滤器的源代码确定它是如何构成的它的热点函数究竟起了怎样的作用以及过滤器是如何调用GIMP库函数的。生成大多数样本的lic函数是getpixel,如清单10.9中的opannotate输出所示。opannotate在源代码的左侧以列的形式依序显示了样本数量和所占样本总量百分比。这使你能查看源代码精确定位哪些代码行是热点。 关于get_pixel函数还有一些有趣的事儿需要注意。首先它调用gimp_bilinear_rgb函数该函数是GIMP库中的一个热点函数。其次它调用了peek函数4次。如果get_pixel 调用执行多次那么peek函数执行的次数就是它的4倍。用opannotate查看peek函数(如清单10.10所示),可以看到它调用了gimp_pixel_rgn_get_pixel和gimp_rgba_set_uchar,它们分别是libgimp和libgimp-color的高级函数。 尽管不是很清楚究竟过滤器是干什么的或者库调用的作用是什么还是有几个让人想去了解的要点。首先peek的功能听起来像是从图像获取像素以便过滤器对它们进行处理。我们马上就可以验证这个预感。其次过滤器中的大部分时间似乎并不是用于在图像数据上运行数学算法。并没有将所有CPU时间都用于根据像素数值进行计算该过滤器好像花费了大部分时间来检索待处理的像素。如果真是这样那么这一点也许能修复。
10.8转战网络
既然我们已经发现了大部分时间里用的是哪些GIMP函数现在我们就必须弄清楚这些函数是什么并尽可能优化它们的使用。首先我们在Web上搜索pixel_rgn_get_pixel,并尝试明确它是做什么的。开始出错几次后清单10.11给出的链接和信息证实了我们对pixel_rgn_get_pixel功能的猜测。 同时清单10.12中的信息表明避免使用pixel_rgn_get_calls是个好主意。 此外通过Web搜索找到函数的源代码很方便地知道了gimp_rgb_set_uchar函数的信息。如清单10.13所示该调用就是把呈现单一颜色的红色、绿色、蓝色值都放入GimpRGB结构中。 从Web收集的信息证实了我们的猜测函数pixel_rgn_get_pixel是从图像抽取数据的一种方法而函数gimp_rgb_set_uchar则仅仅获取从pixel_rgn_get_pixel返回的颜色数据并将它们送入GimpRGB数据结构中。我们不但看到了如何使用这些函数而且其他页面也暗示如果我们想要过滤器的性能达到巅峰那么这些函数可能不是最好的选择。其中一个网页(http://www.home.unix-ag,org/simon/gimp/guadec2002/gimp-plugin/html/efficientaccess.html)建议通过使用GIMP图像缓存有可能提高性能。另一个网站(http://gimp-plug-ins.sourceforge.net/doc/Writing/html/sect-tiles.html)则建议有可能通过重写过滤器使其更高效地访问图像数据来提高性能。
10.9增加图像缓存
网站解释GIMP以一种稍显怪诞的方式管理图像。与使用大的数组保存图像不同GIMP将图像分解为一组分片这些分片的宽度都是64×64。当过滤器想要访问图像中的一个特定像素时GIMP就加载相应的分片然后找到并返回该像素的值。每个检索特定像素的调用都可能会很慢。如果对每一个像素都重复这个过程那么GIMP重载用于检索像素值的分片就会显著降低性能。幸运的是GIMP提供了一种方法来缓存旧的分片值每一次使用的是这个缓存值而不是重载分片。这将会提高性能。GIMP提供的缓存量可以用gimp_tile_cache_ntiles调用来控制。该调用当前在lic内部使用并将缓存设置为图像分片数量的两倍。 即便这个缓存看上去够用了GIMP可能还会需要更大的缓存。测试方式很简单将缓存量增加到一个非常大的值然后看看性能是否有所提升。因此本例中我们把缓存量增加到通常使用量的10倍。缓存值加大后重新运行过滤器检索时间为2分40秒。虽然所用时间减少了6秒但是还是没有达到目标时间2分30秒。这表示我们必须从其他方面来提升性能。
10.10遇到(分片引发的)制约
除了使用分片缓存之外网页提出了一种更好的方法来提高get_pixel的性能。通过直接访问像素信息(不调用gimp_pixel_rgn_get_pixel),可以显著提高像素访问的性能。 GIMP为过滤器编程者提供了一种直接访问图像分片的方法。之后过滤器就可以像访问一个数组一样访问图像数据而不用请求对GIMP库的调用。但是这里有个问题。当直接访问像素信息时它只针对当前分片。因此GIMP将遍历图像中的全部分片以便你最终得到图像中的所有像素可是你却无法同时访问它们。只能查看单个分片的像素而这与lic访问数据的方式不相符。当lic过滤器在特定位置产生一个新的像素时它是基于其周围像素的值来计算这个新值。所以如果是在一个分片的边缘产生了新像素lic 过滤器就需要其周围所有像素的数据。但是这些像素可能是在图像的上一个分片上也可能是在下一个分片上。由于该像素信息不可用图像过滤器将不会使用这个优化的访问方法。
10.11解决问题
由于我们已经判定读取像素值很占时间这里还有另一种方法可以解决这个问题。我们必须开始审视过滤器是如何运行的。在它生成新图像时它会重复请求同一个像素。这是因为新像素的值是根据其周围像素的值得来的因此在对图像运行过滤器的过程中每个像素会被其8个邻居像素访问。这就意味着图像中的每个像素都将被其每一个邻居像素读取其结果就是它将被至少读取9次。 调用GIMP库的开销是很大的所以我们只想对每个像素进行一次这样的操作而不是9 次。对图像访问可能的优化是过滤器启动时将整个图像读入一个本地数组在过滤器运行期间就访问这个本地数组而不是在每次想要访问数据时调用GIMP库函数。这个方法可以显著降低查找像素数据的开销。每次访问数据时不再进行几个函数调用取而代之的是只访问本地数组。过滤器初始化时用malloc分配该数组并用像素数据进行填充。具体操作如清单10.14所示。 同时函数peck也重新编写为只访问这个本地数组而不再调用GIMP库函数。具体操作如清单10.15所示。 那么有效果吗?当我们用新方法运行过滤器时运行时间减少了56秒!刚好在目标时间范围2分30秒内性能有明显提升。 虽然令人印象深刻但是这个性能结果不是平白得来的。我们做的是性能工程中的一个经典取舍用内存的增加换取了性能的提高。举个例子如果过滤器使用的是一个1280×1024的图像所需内存量将增加5MB。对于非常大的图像缓存该数据可能是不实际的。但是对于大小合理的图像相较于过滤器两倍多速度的提高5MB内存使用量的增加似乎是个不错的牺牲。
10.12 验证正确性
我们已经用一个优化明显降低了过滤器的运行时间现在重要的是验证过滤器优化后和优化前产生的图像输出是相同的。加载了原来的参考图像后将它与新生成的图像比较这里使用了GIMP来获取两个图像之间的差异。如果参考图像和优化后图像是相同的那么所有的像素都应该为零(黑色)。但是差异图像并非是完全黑色的。从视觉上看它像是黑色的可仔细检查后(使用GIMP颜色选择器)发现有些像素是非零的。这就意味着参考图像与优化后图像存在差异。 通常这会引起关注因为这可能表明该优化改变了过滤器的行为。但是仔细检查过滤器源代码后显示有几个地方的随机噪声在过滤器运行前就使得图像产生了轻微抖动。过滤器的任意两次运行都会有所不同因此很可能不应为此责备优化。由于两个图像之间的差异在视觉上如此微小因此我们可以假设优化没有引入任何问题。
10.13 后续步骤
我们超额完成了lic过滤器性能增加10%的目标因此就这点来说我们已经完成了优化过程。但是如果想要继续优化性能就必须对使用新优化的过滤器进行重新分析。每一个性能优化应用后重新分析应用程序不依赖于之前的分析对应用程序的继续优化来说是非常重要的。每次优化后应用程序的运行时行为可能发生显著变化。如果不在每次优化后进行分析你就有可能承担继续追逐已不存在的性能问题的风险。
10.14本章小结
本章中我们确定了为什么一个应用程序(GIMP过滤器lic)是受CPU限制的。我们计算出了该应用程序的基准运行时间设置了一个优化目标保存了一个参考图像以验证我们的优化没有改变应用程序的行为。我们使用了Linux CPU性能工具(oprofile和ltrace)调查究竟为什么该应用程序是受CPU限制的。然后依靠Web理解了该应用程序是如何工作的并了解了对其不同的优化方法。我们尝试了几种不同的优化但是最后还是选择了经典的性能权衡增加内存使用量来降低CPU使用量。 我们达到了优化目标之后还验证了优化并未改变应用程序的输出。 本章侧重于优化单个应用程序的运行时间下一章的性能追踪则集中于减少与X Window交互时的延迟。降低延迟可能会非常棘手因为单一事件通常会引发一组非显著性的其他事件。最困难的部分是找出被调用的事件有哪些它们耗时多长。
