【问题标题】:Analyzing and profiling multi-threaded application分析和剖析多线程应用程序
【发布时间】:2012-03-19 02:33:24
【问题描述】:

我们有一个多线程应用程序,它跨多个管道阶段处理大量数据包。该应用程序是在 Linux 下的 C 语言中。

整个应用程序运行良好,没有内存泄漏或线程安全问题。但是,为了分析应用程序,我们如何对线程进行剖析和分析呢?

我们特别感兴趣的是:

  1. 每个线程完成的资源使用情况
  2. 线程争用获取锁的频率和时间
  3. 同步导致的开销量
  4. 系统中的任何瓶颈
  5. 我们可以获得的最佳系统吞吐量是多少

什么是最好的技术和工具?

【问题讨论】:

标签: linux multithreading profiling


【解决方案1】:

看看Intel VTune Amplifier XE(以前的……英特尔线程分析器)看看它是否能满足您的需求。 该工具和其他英特尔 Linux 开发工具可通过 free for non-commercial use 获得。

在视频Using the Timeline in Intel VTune Amplifier XE 中演示了多线程应用程序的时间线。演示者使用图形显示来显示 活动以及如何深入挖掘导致序列化的特定锁的源代码行。在 9:20,演示者提到 “使用框架 API,您可以通过编程方式标记代码中的某些事件或阶段。这些标记将出现在时间轴上。”

【讨论】:

    【解决方案2】:

    几年前我曾研究过类似的系统。我是这样做的:

    第 1 步。在单个线程中摆脱不必要的耗时。为此,我使用了this technique。这样做很重要,因为整个消息传递系统受到其各个部分的速度的限制。

    第 2 步。这部分工作很辛苦,但有回报。对于每个线程,打印一个带时间戳的日志,显示每条消息的发送、接收和操作时间。然后将日志合并到一个公共时间线中并研究它。您正在寻找的是 a) 不必要的重新传输,例如由于超时,b) 收到消息和对其采取行动之间的额外延迟。例如,如果一个线程在其输入队列中有多个消息,其中一些消息可以比其他消息更快地处理,就会发生这种情况。先处理这些是有意义的。

    您可能需要在这两者之间交替使用。

    不要指望这很容易。有些程序员太优秀了,不会被这种肮脏的工作所困扰。但是,您可能会惊喜地发现您能以多快的速度完成整个过程。

    【讨论】:

      【解决方案3】:

      1) 不知道。有一些可用于 linux 的分析器。

      2) 如果您正在流水线化,每个阶段都应该做足够的工作以确保 P-C 队列上的争用最小化。您可以通过一些时间来解决这个问题 - 如果一个阶段需要 10 毫秒以上的时间来处理一个数据包,您可以忘记争用/锁定问题。如果需要 100uS,您应该考虑合并几个阶段,以便每个阶段做更多的工作。

      3) 与 (2) 相同,除非某些全局数据或其他问题存在单独的同步问题。

      4) 每秒转储/记录队列计数会很有用。最长的队列将在脖子最窄的舞台之前。

      5) 不知道 - 不知道您当前的系统是如何工作的,它在什么硬件上运行等等。有一些“正常”的优化 - 消除对象池的内存管理器调用,向最重的阶段添加额外的线程CPU 负载,诸如此类的事情,但“我们可以获得的最佳系统吞吐量是多少” - 说得太空灵了。

      【讨论】:

        【解决方案4】:

        您是否可以灵活地在 Darwin (OSX) 下开发并在 Linux 上部署?性能分析工具非常出色且易于使用(Shark and Thread Viewer 对您的目的很有用)。

        当然,有很多 Linux 性能工具。 gprof、Valgrind(带有 Cachegrind、Callgrind、Massif)和Vtune 将满足您的需求。

        据我所知,没有工具可以直接回答您的问题。但是,可以通过交叉引用来自基于检测和采样的解决方案的数据点和指标来找到答案。

        【讨论】: