我跟你的观点基本一致，puma 不会轻易做 GC, 是会保持最大并发时需要的内存状态的。跟大家交流收获很大，其他朋友可以继续参与讨论交流。

按你的说法来看，这个 GC 不太对，一天都没跑一次。Ruby 是用 rbenv 标准选项进行的编译。

这是咱们昨天晚饭讨论时候测试的内存占用，现在我再次截图，还是保持原有的内存占用。

puma 配置：https://github.com/80percent/rails-template/blob/master/files/config/puma.rb 其中 workers 调成了 4

补充了一些信息，还需要再有一些观察。

我一直是跑在 Ubuntu 14.04 上的。

刚按你的补充测试了一下，如果是单进程模式，跑 GC.start 是会逐步释放内存。但每一次好像只释放 100m.

如果是多进程模式，释放是只针对当前响应请求的进程。看起来只是处理的线程有释放内存。

如果不明确 GC.start 则没有释放内存的迹象。

结论还是以文章最后的总结为准，不明确 GC.start 会保持最大响应请求并发的内存。

➜  perf_test git:(master) wrk -c 10 -d 30 -t 1 http://perf.80percent.io/
Running 30s test @ http://perf.80percent.io/
  1 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11s    56.29ms   1.49s    91.39%
    Req/Sec    17.09     12.86    50.00     54.70%
  267 requests in 30.04s, 1.48MB read
Requests/sec:      8.89
Transfer/sec:     50.55KB

每次请求 100m 内存，执行下面这个测试 ( 10 并发，30 秒 ), 结果是上面的情况，会一直稳定这个内存占用。

puma 配置

[18270] Puma starting in cluster mode... [18270] * Version 3.11.3 (ruby 2.3.1-p112), codename: Love Song [18270] * Min threads: 4, max threads: 8

@ceclinux-github Rails 5.1.4

@huacnlee 看上去是保持在 puma 顶峰并发时的占用内存不释放，原因暂不清楚。而且就算请求结束了，新请求也有可能由于内存不足而失败。有时候不会复用原有的内存。

@Rei 已推荐团队内尝试使用

技术总结：https://ruby-china.org/topics/35044

谢谢大家的讨论与反馈，回头总结一篇纯技术性的文章。

@victor 知道自己还不知道的东西，往往比精通自己已经知道的东西价值大的多，我们现在所谓学到的东西大都是已经存在的，如果只是搬运有什么价值呢。

本文就是想将自己所见所闻分享出来，就是我认为的价值。

@Rei 因为需要一个宣传标签出去，感觉达人还算比较低调，感谢指正定义。

@railsboy 从公众号拉过来了，我调整下。

没有刻意留意技术上的总结。

啥过了？

没想到这篇文章引起了各路高手的争执，这不是本文的目的。

我站在我的角度想讲一讲我的看法和践行的内容。

Rails 仍然是目前最高效的 web 全栈框架，所以我们团队选择它

我已经接触 IT 领域 10 年以上了，也逐步成了别人眼中的“技术大神”, 用过 php, j2ee, 也写过 python, flask, 甚至 perl 等各种语言和框架，深入前端领域好几年。据我的实战经历来看，Rails 仍然是目前最高效的 web 全栈框架

我们团队目前 7 个全栈工程师，全是 Ruby on Rails 系的，还兼顾前端 React, Vue, 做的非常出色。这足以证明 Rails 的生产力价值。

JavaScript 最终会回到 Rails 的老路上，现在生态很不稳定

JavaScript 是这些年的新宠，NodeJS 从零发展，进步飞速，虽没有技术包袱，但轮子满天飞，框架天天变，拥有的只有无尽的所谓更好的解决方案，君不见：

npm 最终往 bundler 方面靠进

webpack 没过多久就又开始有新的挑战者了，等等等

现在还没有足够完备的 web 全栈框架，都是快速演进中。

Rails 入手门槛高，导致了生态问题，但我们仍在努力建设

web 世界仍在快速发展，但是 Rails 为什么错过了巨大的风口，这值得我们深思。我个人感觉是由于 Rails 框架的高入手成本与门槛，进而导致了较差的生态，然后互相的影响造就了一个不够健康的生态环境。

现在，Rails 5.1 也做好了接纳 JavaScript 的世界进入的准备，相信会有不错的发展。

更关键的，你最终会发现，那些不成熟的框架最终都会像 Rails 看齐，这才是全栈框架演进的形态。

但是，我们社区的早一批程序员没有放弃，我们仍然在努力建设生态，比如在深圳，大疆，百分之八十，oschina 等还有一批公司在享受着 Rails 带来的好处与便利。

不要被单一的语言所束缚，在 Ruby 世界里，你必须会 3 门以上的语言。

视野要开阔，不断学会全局思考问题，方可无敌于天下。

谢谢队长中文化，我也只能贡献点支持啦

先有蛋先有鸡的问题，我们还是需要通过自身的努力让生态变的更好，比如现在的深圳大疆，就是海波当年种下的生态种子。

@Rei 多谢补充原文链接

DHH: 2017 年 Rails 框架还值得学习吗？https://ruby-china.org/topics/34762

看一下 rails-template 关于 spring 的改进：spring 配置

可以在 config/spring.rb 中加入这个配置。

@haiguizac 支持 zac!

不用 直接过来就好了

嗯 有没有主题分享一下

最近台风有点多

@lgn21st 再麻烦置顶几天，重新启动。

@all 由于台风天气的影响，为了大家的安全出行，下午深圳 Ruby 技术活动时间延迟到后续举行。具体时间另行通知。多会通知系统有点 bug, 报名的朋友互相转告一下。

welcome

@Rei 好吧，下次搞起

@lgn21st 请求置顶