先移掉，再试试是否加快了。

puma 启动时 100% cpu 的问题，检查一下 bootsnap , 这个会有影响。

用的编辑器配置的问题，导致了换行符的错误。

Linux 下换行符是 \n

window 下是 \r\n 都可以正确识别

可以去蛋人网看看： https://eggman.tv/

用 mobx 作 store 层，自动同步更新。看这里的 gif 示例： https://github.com/80percent/react-native-template-mobx

否则就只能自己写事件处理一下。

谢谢，已修正

谢谢反馈，已修正

公司业务还在快速发展中，继续招募人才中。

既然用的 jquery, 就换为 jquery-ujs 就好了。

好的，请微信联系我

嗯

经验不限的。

哈，大家都是技术宅，不愿意上头像。今年新 VI 已经上线 :)

ps: 继续在招聘中，有兴趣的朋友抓紧联系我。

也可以的

好咧

@lgn21st 请求组织置顶几天

好东西，收！

😂

我跟你的观点基本一致，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

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