没什么鸟用。。。。

快速迭代用 ruby。 然后把沉淀下来的业务用高性能语言来实现。

振奋的是 Shopify 组建了一个团队去开发 YJIT。

关注合并的最新进展 https://bugs.ruby-lang.org/issues/18229

性能提升相当有限，还引入没没必要的复杂度。。。

对于大公司来说还是很可观的

原来的 rails 团队就地解散。语言是码农的工具，码农是老板的工具，就象 obj/instance 是 class 的实例，class 是 Class 的实例一样

这么多年，ruby 的运算速度一直没有困扰到我，困扰到我的是内存。。。

困扰内存的不是 ruby 是 rails
很多人 ruby/rails 傻傻分不清 只能重回幼儿园看图识 ruby

困扰到我的是内存 不仅仅是 ruby 内存 也不仅仅是 rails 内存 gem 内存 而是 内存

也许我的语文能力还没幼儿园毕业，让你理解起来费力了，我得好好反思下自己，多为社区添砖加瓦

如果 ruby 社区不用区分 ruby 内存/rails 内存/gem 内存 仅仅是内存困扰的的话，按 1 楼说的方案用 java 可是极好的，rails 团队原地解散，指望老板加内存来实现给 ruby 添砖加瓦根本不靠谱，老板都是用现成的，直接用现成的 java 的砖瓦，java 的砖瓦海了去了 相对 rails crud 甩 ruby 10 条街不止

说的没错 我是 10 年前就是写 java 的，现在 java 的 spring 生态也很好，绝大多数国内大公司最终业务都跑在 java 上

快速迭代速度和开发效率 ruby on rails 优势更大，ruby 社区的大多数人估计都赞成

我反思了下，确实你说的对，我没必要贬低其他人，要打拳我大可以去微博怼社会话题

最后祝我们为多为 ruby 社区添砖加瓦，做大做强

1 楼说的对，你也说得没错，我来总结一下，公司用 rails 的主要目的就是开头走个过场，rails 领进门，修行在 java，翻译成白话就是 传说中的导流量 导完流量后 原地解散的 Rails 团队再去 ruby 社区添砖加瓦，还能利用起来，最后把 ruby 社区做大做强 一点都不带浪费的。 做大做强 ruby 社区以后还可以打打拳去微博怼社会话题 顺便给微博导流量。多年以后，回顾 ruby 码农的一生，一生都在导流量 如果不是正在导流量，就在正走在去往导流量的路上

白色头像那人真是拉低社区能量，也没增加什么集体知识。向楼上大哥的反应学习👍

有件事情我也很困扰，无论是 unicorn 还是 sidekiq 都需要配 killer, 不然内存一定会爆。

意义对每个人都是不同的，对码畜来说，让老板加内存条解决Rails 内存占用比较有意义，而对土憋老板来说 让码畜加班干活到11点而不付一分钱的加班费比较有意义 而 Linus 觉得写完代码炮轰 cpp 太烂有意义 统一的意义只有在西部世部的机器人写代码中才有。

有主张没办法是逃避问题，转移焦点的典型话术，这种情况一般是参加成功学培训多了，什么只要努力免费加班，就能加薪，只要努力挖煤，就能有一天当上煤老板。只要添转加瓦，Ruby 就有一天能做大做强之类的。

就我的个人观点，ruby 即没有必要做大做强 在可以预见的将来也不可能做大做强。 ruby 需要解决的是特定领域的特定问题，比如像金数据那样解决 form 表单的问题 象 sequel 那样初期解决项目原型快速迭代的问题

Rails3 在只专注后端，google 可以流畅访问的时侯，是可以实现项目原型快速迭代的，但是现在的 rails 版本捆绑着一堆强藕合东西，在众所周知的玻璃墙越架越高，各种花式限流的阻挠之下， 用 rails 实现快速迭代已经不再具有优势，反而低并发，高内存占用成为项目一定规模以后的棘手的难题。

现在技术领域有一个令人不安的趋势，资本提供一个主流解决方案 这个主流方案中的的出现的任何问题都应该回避，任何跟资本导向不利的方向都是被 diss 的，很象 weibo 上看不见，摸不着的各种红杠杠。你在够烂社区说最常用的 slice 都有很严重的坑，旁边马上跳出来一个码农说你态度有问题。 资本不仅控制着码农用什么技术 还在控制着码农用什么版本的技术 现在正在力图精细控制码农的面部表情，象西部世界那样让高级机器人写高级代码，生产另一批低级机器人写码畜们所写的那种 repeat 的代码正在一步步成为现实。 我说的不仅是 ruby 社区 而是所有技术社区都是这种趋势。资本控制下的码农不再去主导技术的发展，而是蜕化成一个跑龙套的，关心态度比关心技术问题本身更重要，更关心正能量，友善的态度，关心拉帮结派，拜山头，认大哥，交投名状 任何不随大流的都先揪出来批斗一番 至于讨论的技术问题是什么 根本不重要。 以前是在技术支持行业特别流行这个观念，你可以不解决客户面临的任何实际技术问题，但你一定要态度好，能讨客户欢心是最重要的，因为最终是客户掏钱买服务，客户花钱买个开心也是挺值的。 现在这个观念蔓延到了开发领域，技术本身不重要，需要解决的问题也不重要，重要的是要随大流，要有看齐意识，虽然大哥不发钱，但一定要紧跟大哥的步伐，要圈在笼子里千万不要到处乱跑，外面的世界太险恶了。

在形成资本控制的技术牢笼以后。老罗说的猴子不吃香焦的故事一遍一遍地重复上演 被圈在笼子里老猴子们已经习惯了不吃香焦 有新猴子胆敢吃香焦，老猴子们围上来不是解释1，2，3吃香蕉具体有那些坏处 而是上来就是一顿暴打。最大的梦想就是做大笼子，笼子要招新猴子，一定要招不吃香蕉的新猴子才可以

很不巧的的，我不是那种热衷听成功学讲座然后来回说车轱辘话回避实际问题的人 我是寻求解决方案的人 我最喜欢最热衷的事就是打破砂锅问到底，不见黄河不死心。回到主题 我想问的是

• rails 的高内存占用的终极解决方案是什么，是不是象码农那样一看 ide 内存不够了，按 reset 重启电脑就行了？
• rails 项目规模级超过 1000w 的后续解决方案是什么 是不是一劈两半，分裂两个 500w 的 rails 项目，让 rails 的天花板始终处于 1000w 以下
• 在人口结构421，玻璃墙越架越高的前提下，ruby 圈人很少 ruby 社区吸引新人的方案是什么，靠大哥说得对，你看我态度好浑身上下每个毛孔都散发着正能量 来吸引新人入圈吗？

还是要顺应大势，号召大家为社区添砖加瓦说实话没什么用，ruby 要再火除非出现一个像 rails 一样火爆的框架。创造和改变历史靠的往往是少量几个英雄人物，大部分普通人的作用只是喊 666。

应该是有 gem 内存泄漏了。 除了选择 puma killer 还可以试试 systemd 本身有内存约束

我用 puma killer 有时候 worker 没起来

说 Rails 慢我也就勉强认了，说 Rails 吃内存的就有点过分了，2 核 4G 跑 4 个 Rails 服务，占用内存不过一半，JVM Spring 能比？gem 内存泄漏的问题，其实只要保证所有 gem 都是最新版就好了，历史上的泄漏都解了，社区都有一个网站专门说这个问题：https://www.rubymem.com

聊到 Large Scale 的时候，还盯着 web server 的话，就特没啥意思。。。

这个问题我解决了。不是什么内存泄露，换 jemalloc 就好了