分析(可能是I / O绑定)进程以减less延迟

我想在一个更大的应用程序中改进特定方法的性能

目标是提高延迟(在特定function中花费的挂钟时间),而不是(必须)系统负载。

要求:

  1. 正如我所预料的那样,由于I / O造成了很多延迟,所以要考虑等待/阻塞所花费的时间(换句话说,看看挂钟时间而不是CPU时间)
  2. 由于该程序比我想优化的片段要多得多。 需要有一种方法来以编程方式启动/停止分析,或筛选输出以仅显示进入和退出我正在优化的function之间的时间。
  3. 对方法级别进行分析是可以接受的(如果可以在指令级别上完成的话,甚至更好,如果只是对系统调用进行configuration,那可能是不够的)
  4. 这是一个爱好项目,所以昂贵的工具不是一个真正的select
  5. 仪表(-finstrument-functions)是可以接受的
  6. 我感兴趣的关键代码很难手工中断(因为它已经相对较快,很难实际地在一个循环中调用),所以需要某种自动化。

目前丢弃的工具:

  • gprof,oprofile,callgrind(要求1)
  • 使用getrusage构build自定义的东西(需求1)
  • poormansprofiler.org(要求2)
  • strace -T,dtrace, http://perf.wiki.kernel.org (要求2和3)
  • VTune,缩放(要求4)
  • 手动调用堆栈抽样(要求6)
  • 谷歌perftools(应该能够测量墙的时间,但这似乎并没有在我的情况下工作,大概是因为SIGALRM的干扰。
  • systemtap(我的内核不打补丁包括utrace)

其他选项,我还没有进一步评估:

  • cprof(这里不是开箱即用的,似乎只有i386)
  • 手动插入跟踪点(例如用lttng)

我很想听听:

  • 其他选项
  • 也许我过早放弃了一些工具?
  • 我还没有评估的选项是否有工作的机会,如果是的话,如何做到最好。

我终于解决了:

  • build立自定义使用函数 – 函数我自己,基于http://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/

这个粗糙的工具产生的痕迹很难解释,我可以很容易地想象一些工具来进一步处理它的输出,使它更有用。 不过,现在这个工作已经完成了,所以我把这个项目放到了后面)。

Solutions Collecting From Web of "分析(可能是I / O绑定)进程以减less延迟"

使用这种方法 。

无论是CPU还是IO绑定代码,它都非常简单而且有效地找出优化的机会。

如果你是对的,最大的机会是在一个特定的功能或模块,那么它会找到它们。 如果他们在其他地方,它会找到他们。

你提到和丢弃的工具,与穷人的剖析器最为相似,但还是不太相似。

编辑:既然你说它是由用户交互触发,并阻止进一步的输入,直到完成,这是我将如何做到这一点。

首先,我假定它不会阻止手动中断信号给调试器,否则你将无法停止无限循环。 其次,我将围绕有关的例行程序进行10,100或1000次循环,所以这个过程足够长,可以手动中断。

现在,假设它正在花费I / O的一小部分时间,比如50%。 那么当你打断它时,你有50%的机会在I / O中捕捉它。 所以,如果你在调用堆栈会告诉你的I / O中捕获它,你还可以详细看到I / O被请求的地方以及为什么。

它会告诉你发生了什么,这几乎肯定是令人惊讶的。 如果你看到它只做了两个(2)样本,你可以找到一种方法来消除,那么你会得到一个相当大的加速。 事实上,如果你消除了这个活动,事先并不知道你能节省多少时间,但平均而言,你可以期望节省分数F =(s + 1)/(n + 2) ,其中n是您采样的总数, s是显示活动的样本数。 ( 继承规则 )例如,如果你拿了4个堆栈样本,看到其中2个堆栈的活动,那么平均而言,它会为你节省F = 3/6 = 1/2 ,相当于加速因子1 /(1-F )或2。

一旦你做完了,你可以再次做,找到其他的东西来解决。 加速因子像复合兴趣一样倍增。

那么当然,你可以去除外部循环,并“获得”所有的加速。

如果您想知道这与分析有什么不同,那么通过仔细检查每个堆栈样本以及可能的相关数据,您可以识别出可以删除的活动,如果您只有测量结果,则可以尝试直观到底是怎么回事。 无论有什么测量,您保存的实际时间量都是实际的量。 重要的是找到问题。 不管探测器的精确度如何,如果找不到 ,就不会赢。 这些网页上有很多人说他们不明白他们的个人资料是在告诉他们,还是似乎在说没有什么可以解决的,他们只是太乐意接受了。 那是玫瑰色的眼镜。

更多的一切。

对于I / O绑定的应用程序,您可以使用--collect-systime=yes选项。

这会收集在系统调用中花费的时间(以毫秒为单位)。 所以,如果你认为你有一个I / O瓶颈,你可以使用这些统计来识别它。

待办事项:再次检查“perf”

  • 叉子()
  • execxxx(进行中的测试)
  • 在父母:
    • (在一个循环中)定期调用:
    • getrusage(RUSAGE_CHILDREN,…)

getrusage()不仅会给你cpu的使用,还会给你主要或次要的页面错误,上下文切换的次数等等。 其余的时间可能花在等待I / O上。 这不会给你详细的性能分析信息,但是对程序行为有很好的总体影响,与在每个进程上运行vmstat相当。