跟踪正在运行的 ruby​​ 进程

发布于 2024-08-07 10:17:56 字数 204 浏览 3 评论 0原文

我正在运行一个 ruby​​ 代码,它有大量的 http(web 和 api)请求,以及一些相当密集的数据处理。正如您所料,它非常慢,我想找出主要瓶颈在哪里。我不认为我需要一个完整的分析器(还),但想要某种方式在运行时跟踪进程(无需在整个文件中写入 put 语句)

我想这将是非常常见的事情,任何想要拥有的东西关于如何实现这一点的想法,也许是一个可以做到这一点的 gem/插件?

I am running a ruby code that has a significant number of http (web and api) requests, as well as some pretty intensive data processing. As you might expect it is pretty slow, and i want to find out where the main bottle necks are. I do not think i need a full blown profiler (yet), but want some way of tracing the process as it runs (without writing puts statement all over the file)

I imagine that this would be pretty common thing to want to have, any thoughts on how this can be accomplished, perhaps a gem/plugin that does this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

寄人书 2024-08-14 10:17:56

您可以尝试劫持,它为您提供了一个现有的irb会话红宝石工艺。在上下文中,您可以对可疑请求进行基准测试,例如:

require 'benchmark'
puts Benchmark.measure { the_slow_Http_Request }

Joe Damato 的 ltrace hack 看起来也很不错,但我自己还没有尝试过。

You could try Hijack, it gives you an irb session to an existing ruby process. While in context you could benchmark the suspected requests something like:

require 'benchmark'
puts Benchmark.measure { the_slow_Http_Request }

Joe Damato's ltrace hack also seems very nice but I haven't tried it myself.

开始看清了 2024-08-14 10:17:56

基准一下吧!

我发现,对基准测试的一些适当调用通常可以很快缩小问题范围 - 分析器很好,但简单的自行解决方案通常效果很好。

对我来说,使用这种方法的一个主要好处是发现批量数据库插入有多大的差异。

事实上,我在一些程序中保留了基准,只是为了不断检查性能是否保持在可接受的范围内

Benchmark it!

I've found that a few well placed calls to benchmark usually narrow down the problems pretty quickly - profilers are fine but a simple roll-your-own solution often works well.

One major bonus using this approach for me was finding just how big a difference there is in batching up database inserts.

In fact I've left the benchmarks in place in a few programs just to constantly check that performance keeps within acceptable areas

友欢 2024-08-14 10:17:56

您可以在调试器下运行它并在速度缓慢时手动暂停它吗?如果你这样做几次,你就会发现最大的瓶颈是什么。

例如,如果它正在等待 Web 或 api 请求,则该请求将位于堆栈的顶部。然后查看堆栈下一层的代码行,这是一个函数调用。由于该函数调用,I/O 请求正在完成。然后看下一行——同样的事情。

如果执行 I/O(例如计算),情况也是如此。
调用堆栈上的每一行代码都对所使用的时间片负有全部责任。

因此,如果您多次暂停它,则调用堆栈上出现多次暂停的任何代码行都会告诉您这是一个瓶颈,如果有任何方法可以删除它或减少执行它的频率。

这里有更完整的解释。

Can you run it under a debugger and pause it manually while it is being slow? If you do that several times, you will find out what the biggest bottlenecks are.

For example, if it is in the process of waiting for a web or api request, that will be at the top of the stack. Then look at the line of code one level down the stack, which is a function call. The I/O request is being done because of that function call. Then look at the next line - same thing.

The same is true if it is not doing I/O, like if it is computing.
Every line of code on the call stack bears full responsibility for that slice of time being used.

So, if you pause it several times, any line of code that appears on the call stack on more than one pause, is telling you it is a bottleneck, if there is any way you could remove it or execute it less often.

Here's a more complete explanation.

标点 2024-08-14 10:17:56

https://rbspy.github.io 非常令人印象深刻且简单易用。只需将您的 pid 发送给它,您就可以获得分析和漂亮的火焰图。

https://rbspy.github.io is pretty impressive and stupid easy to use. just send it your pid and you can get profiling and a nice flame graph.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文