我使用 gem Curb (也尝试使用 httparty)来执行大量 http 请求，并且效果很好。但在我的一项 (rake) 任务中(我执行了 20k 以上的请求)，我遇到了内存问题(Rails“吃掉”了超过 2GB 的 RAM，直到不再有可用内存)。
似乎Rails“不等待”响应并在循环中的另一个线程中继续，问题是，以这种方式将创建很多未被垃圾收集器收集的对象(我认为)这就是内存泄漏的原因。
有一种方法可以让rails等待响应到来吗？ (我尝试使用 sleep 但不是一个稳定的解决方案)。
我有一个像这样的伪代码:
def the_start
while start_date <= end_date do # ~ 140 loop
a_method_that_do_sub_specifics_call
end
end
def a_method_that_do_sub_specifics_call
some_data.each do |r| # ~ 180 loop
do_a_call
#do something with models (update/create entries,...)
end
end
def do_a_call # called ~ 25k times
# with the gem Curb version
req = Curl::Easy.new do |curl|
curl.ssl_verify_peer = false
curl.url = url
curl.headers['Content-type'] = 'application/json'
end
req.perform
# actual version, with httparty gem
req = HTTParty.get("#{url}",
:headers => {'Content-type' => 'application/json'})
end
看来 Rails 不会等待 req.perform 的结果。
编辑:
也尝试使用 Curl::Easy.perform() 和 req.close 仅实例化一次 Curl::Easy 对象(应该调用后隐式调用GC)但没有成功，但内存使用量很大。 (我认为)唯一可行的解决方案是“阻塞”轨道，直到响应到来，但是如何呢？
编辑2
在另一项任务中，我仅调用 a_method_that_do_sub_specifics_call ，没有出现任何问题。
编辑3
经过一些性能修改(放置 find_each(:batch_size => ...)、GC.start,...)，任务工作得更好了..现在第一个大约 100 个循环 (do_a_call) 运行良好，之后内存使用量再次从 100Mb 跃升至 2Gb+。
最佳答案
经过几天的调试，阅读了大量的论坛和帖子，我找到了解决方案:
一个适度的类变量字符串，它会一直增长，直到发生内存泄漏。
我在旅行中获得的一些有用的笔记:
Curb 与 HTTParty
在这两个执行curl 请求的gem 中，性能最好的是Curb。
http://bibwild.wordpress.com/2012/04/30/ruby-http-performance-shootout-redux/
注意类变量
我的问题是调试/信息变量字符串类不断增长，避免使用垃圾收集器从未收集的类变量。
在我的具体案例中是:
@status = "#{@status} Warning - response is empty for #{description}\n"
执行一些手动垃圾收集
在关键点执行一些手动GC.start，以确保释放不再需要的内存。请记住，调用 GC.start 不会立即调用垃圾收集器，它只是建议这样做。
调用ActiveRecords数组
调用大型 ActiveRecords 时使用 .find_each，例如:
Model.find_each(:batch_size => 50) do |row|
每次仅对 50(或小于默认值)行执行查询，比调用 1k 行的单个查询要好。 (我猜默认的batch_size是1000)。
有用的链接:
关于ruby-on-rails-3 - Rails - 循环卷发请求占用内存，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16237159/