【发布时间】：2010-08-12 07:40:43
【问题描述】：
需要分析一个用 C++ 编写的守护进程，gprof 说它需要终止进程以获取 gmon.out。我想知道有人有想法用 ctrl-c 获取 gmon.out 吗？我想找出cpu周期的热点
【问题讨论】：
【发布时间】：2010-08-12 07:40:43
【问题描述】：
需要分析一个用 C++ 编写的守护进程，gprof 说它需要终止进程以获取 gmon.out。
这符合调试守护进程的正常做法：提供一个开关（例如，使用命令行选项），它将强制守护进程在前台运行。
我想知道有人有想法用 ctrl-c 获取 gmon.out 吗？
我不知道这些选项。
尽管在 gmon 的情况下，call to exit() should suffice：例如，如果您打算测试处理 100K 条消息，您可以在代码中添加一个计数器，在每条处理的消息上递增。当计数器超过限制时，只需调用exit()。
您也可以尝试为一些未使用的信号（如 SIGUSR1 或 SIGUSR2）添加处理程序并从那里调用 exit()。以为我没有亲身经历，不能确定 gmon 在这种情况下是否能正常工作。
我想找出cpu周期的热点
我通常的做法是创建一个测试应用程序，使用与守护程序相同的源代码但不同的main() 我在其中模拟需要调试或测试的精确场景（通常使用命令行切换许多场景）。为此，我通常创建一个包含整个模块的静态库 - 除了带有 main() 的文件 - 并将测试应用程序与静态库链接。 （这有助于保持 Makefile 整洁。）
我更喜欢单独的测试应用程序来破解代码内部，因为尤其是在性能测试的情况下，我有时可以绕过或减少对昂贵 I/O（或 DB 访问）的调用，这通常会扭曲分析器的采样并使输出无用.
【讨论】：
-
感谢您的观点，我也在下面搜索了类似的想法：linuxquestions.org/questions/linux-software-2/… 但我很遗憾，守护进程无法正常退出，因此退出时核心转储，并且没有生成 gmon.out 我'将尝试提取可疑的实现以独立测试它
-
我建议首先优先解决关机期间的崩溃问题。该问题将阻止许多运行时分析工具正常工作。应该很容易卖给管理层。
作为第一个建议，我会说您可以尝试使用其他工具。如果该守护进程的性能在您的测试中不是问题，您可以尝试valgrind。这是一个很棒的工具，我真的很喜欢它。
【讨论】：
-
感谢您的建议，但是 valgrind 在压力测试时会很快变慢
如果你想让守护进程尽可能快地运行，你可以使用 lsstack 和this technique。它将向您显示您可以删除哪些需要时间。如果您正在寻找热点，您可能正在寻找错误的东西。通常有一些函数调用不是绝对需要的，它们不会显示为热点，但它们会显示在堆栈快照中。
另一个不错的选择是RotateRight/Zoom。
【讨论】：