所以我在本地运行进程 ID 为 11697 的 Rails 4 应用程序(API)。我有以下设置，但我通过发出的 bash 命令得到以下响应:
*** run `sudo sysctl kernel.msgmnb=1048576` to prevent losing events (currently: 16384 bytes)
*** attached to process 11697
*** timed out waiting for eval response
*** detached from process 11697
好像没等到600秒就超时了。 I've seen this PR on github, so it seems like it should work .
此处的目标是获取 Rails 应用程序对象的多个堆快照并比较这 2 个差异以尝试检测内存泄漏。
config/environment.rb
# Load the Rails application.
require File.expand_path('../application', __FILE__)
require 'rbtrace'
# Initialize the Rails application.
Rails.application.initialize!
bash 命令提示符
bundle exec rbtrace -p 11697 -e 'Thread.new{require "objspace"; ObjectSpace.trace_object_allocations_start; GC.start(); ObjectSpace.dump_all(output: File.open("heap.json", "w"))}.join' --timeout=600
最佳答案
看起来另一个 PR (42) 是 actually merged在 6 月 14 日解决这个问题，自 February 13th 以来他们还没有发布 rbtrace
所以代码合并到master，但是还没有通过rubygems.org发布。
您可以将 rbtrace gem 的 master 分支添加为您的 gemfile 中的依赖项，如下例所示。您可能拥有为 eval 启用超时选项的 PR 代码，但 master 分支可能尚未完全准备好用于生产。使用风险自负!
gem 'rbtrace', git: 'https://github.com/tmm1/rbtrace', branch: 'master'
关于ruby-on-rails - 在本地将 rbtrace 与 Rails 4 一起使用时，如何防止等待 eval 响应超时？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31015027/