【问题标题】:Ruby on rails memory managementRuby on rails 内存管理
【发布时间】:2015-07-08 15:04:50
【问题描述】:

我正在实现一个 ruby​​ on rails 服务器(Ruby 2.2.1 和 rails 4.1.10),我面临一些内存问题,其中服务器进程(puma)可能需要 500MB 甚至更多。主要是当我将大文件上传到服务器时,我得到了这种价值。我正在使用载波。

我的问题与 ruby​​ 管理系统和垃圾收集有关。看到我的服务器专用于嵌入式系统,我真的需要限制或控制内存,我的进程正在从系统中获取。

有没有办法查看哪些对象(及其大小)仍然存在并且不应该存在? 如果内存碎片化,ruby中的内存系统不会将空闲内存取回系统吗? 请帮我弄清楚当我的内存大于 150MB 空闲时发生了什么。

斯蒂夫

【问题讨论】:

    标签: ruby-on-rails ruby memory-management memory-leaks carrierwave


    【解决方案1】:

    在阅读了很多关于这个问题的帖子之后,似乎真正的原因来自 Ruby GC,它消耗了大量的服务器内存并导致从 2.1.x 版本开始大量的服务器交换。

    为了解决这些性能问题,我只是将RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR 设置为1.25 附近的值。您可以使用该设置来为您的环境找到最佳价值。

    仅供参考,我的应用在 Heroku Cedar 14 上使用 Ruby 2.1.5 运行,它的运行就像一个魅力。

    希望对你有帮助:)

    【讨论】:

      【解决方案2】:

      我想我的问题与 GC 的启动方式无关,因为如果我要求手动垃圾收集 gc.start,我不会找回我的记忆。也许我在某处发生了内存泄漏,但我想找到一种方法来跟踪它。

      【讨论】:

        【解决方案3】:

        事实上,在您的情况下,carrierewave gem 本身似乎是您问题的根源。 这个 gem 似乎使用整个文件而不是块来播放它......因此,当您上传大文件时,您可以轻松地达到服务器的内存限制。

        这篇文章似乎证实了我的意思: https://github.com/carrierwaveuploader/carrierwave/issues/413

        在您的情况下,我可以建议考虑在 S3 上使用直接上传来避免您的服务器直接在亚马逊服务器上在后台处理上传。

        我对carrierwave不是很熟悉,但是这个gem应该可以解决问题: https://github.com/dwilkie/carrierwave_direct

        我不知道它是否对您来说是一个有效的解决方案,但就您的问题而言,它似乎是您最好的选择。

        希望它有所帮助:)!

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2010-09-11
          • 2011-04-14
          • 2010-09-14
          • 2017-09-26
          • 2011-06-26
          • 2013-11-30
          相关资源
          最近更新 更多