如何使用 gprof 分析守护进程而不正常终止它？
需要分析一个用C++编写的守护进程，gprof说它需要终止进程才能获取gmon.out。我想知道有人有想法用 ctrl-c 获取 gmon.out 吗？我想找出cpu周期的热点
Need to profile a daemon written in C++, gprof says it need to terminate the process to get the gmon.out. I'm wondering anyone has ideas to get the gmon.out with ctrl-c? I want to find out the hot spot for cpu cycle
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这符合调试守护进程进程的正常做法：提供一个开关（例如使用命令行选项），该开关将强制守护进程在前台运行。
我不知道有这样的选择。
尽管对于 gmon，调用
exit() 应该足够了：例如，如果您打算测试处理 100K 消息，您可以在代码中添加一个计数器，该计数器在每个处理的消息上递增。当计数器超过限制时，只需调用exit()。您还可以尝试为某些未使用的信号（例如 SIGUSR1 或 SIGUSR2）添加处理程序，并从那里调用
exit()。我认为我没有个人经验，无法确定 gmon 在这种情况下能否正常工作。我通常的做法是创建一个测试应用程序，使用与守护程序相同的源代码，但使用不同的
main()来模拟精确的场景（通常使用命令线路切换很多场景）我需要调试或测试。为此，我通常创建一个包含整个模块的静态库（除了带有main()的文件），并将测试应用程序与静态库链接。 （这有助于保持 Makefile 整洁。）我更喜欢单独的测试应用程序而不是侵入代码内部，因为特别是在性能测试的情况下，我有时可以绕过或减少对昂贵的 I/O（或数据库访问）的调用，这通常会扭曲分析器的采样并使输出无用。
That fits the normal practice of debugging daemon processes: provision a switch (e.g. with command line option) which would force the daemon to run in foreground.
I'm not aware of such options.
Though in case of gmon, call to
exit()should suffice: if you for example intend to test say processing 100K messages, you can add in code a counter incremented on every processed message. When the counter exceeds the limit, simply callexit().You also can try to add a handler for some unused signal (like SIGUSR1 or SIGUSR2) and call
exit()from there. Thought I do not have personal experience and cannot be sure that gmon would work properly in the case.My usual practice is to create a test application, using same source code as the daemon but different
main()where I simulate precise scenario (often with a command line switch many scenarios) I need to debug or test. For the purpose, I normally create a static library containing the whole module - except the file withmain()- and link the test application with the static library. (That helps keeping Makefiles tidy.)I prefer the separate test application to hacks inside of the code since especially in case of performance testing I can sometimes bypass or reduce calls to expensive I/O (or DB accesses) which often skews the profiler's sampling and renders the output useless.
作为第一个建议，我会说您可以尝试使用其他工具。如果该守护进程的性能在您的测试中不是问题，您可以尝试 valgrind。这是一个很棒的工具，我真的很喜欢它。
As a first suggestion I would say you might try to use another tool. If the performance of that daemon is not an issue in your test you could give a try to valgrind. It is a wonderful tool, I really love it.
如果您想让守护进程尽可能快地运行，可以将 lsstack 与 这种技术。它将向您显示哪些内容需要花费时间才能删除。如果您正在寻找热点，那么您可能找错了地方。通常，有些函数调用并不是绝对需要的，并且这些函数调用不会显示为热点，但它们确实会显示在堆栈快照中。
另一个不错的选择是RotateRight/Zoom。
If you want to make the daemon go as fast as possible, you can use lsstack with this technique. It will show you what's taking time that you can remove. If you're looking for hot spots, you are probably looking for the wrong thing. Typically there are function calls that are not absolutely needed, and those don't show up as hot spots, but they do show up on stackshots.
Another good option is RotateRight/Zoom.