不是啊 我验证的结果确实是每次调用 GC.start 内存一定能回收降低到 79M 的。
多进程下你调用 GET /gc 回收的只是其中一个进程。
你用 Linux 试试,我刚才又在 macOS 上验证了一下
GET /gc
(GC.start
)不会释放,内存还是 GET /
后的样子,单线程 100M 的场景,最后固定在 473MB
我刚才调整了一下配置,Puma 单线程跑,每次请求 100m 内存
class WelcomeController < ApplicationController
# GET /
def index
foo = '0' * 1024 * 1024 * 100
memory = `ps -o rss= -p #{$$}`.to_i
render plain: "hello, #{memory / 1024}MB\n #{GC.stat} \n"
end
# GET /gc
# 手动调用 GC.start
def gc
GC.start
memory = `ps -o rss= -p #{$$}`.to_i
render plain: "hello, #{memory / 1024}MB\n #{GC.stat} \n"
end
end
Puma starting in single mode...
* Version 3.11.3 (ruby 2.5.0-p0), codename: Love Song
* Min threads: 1, max threads: 1
* Environment: production
* Daemonizing...
并发跑下去,最后稳定在 279M
/gc 里面有个手动的
GC.start
$ siege -c 100 http://localhost:3000/
$ curl http://localhost:3000/
hello, 279M
$ curl http://localhost:3000/
hello, 178MB
$ curl http://localhost:3000/gc
hello, 78MB
$ curl http://localhost:3000/
hello, 178MB
$ curl http://localhost:3000/gc
hello, 78MB
Puma starting in single mode...
* Version 3.11.3 (ruby 2.5.0-p0), codename: Love Song
* Min threads: 5, max threads: 5
* Environment: production
* Daemonizing...
结果:
$ curl http://localhost:3000/
hello, 783MB
$ curl http://localhost:3000/gc
hello, 78MB
$ curl http://localhost:3000/
hello, 178MB
$ curl http://localhost:3000/
hello, 279MB
$ curl http://localhost:3000/
hello, 178MB
$ curl http://localhost:3000/gc
hello, 78MB
以上测试说明,这是能正确回收的
引入一些相关的讨论,Sidekiq 的作者的分析:
https://github.com/puma/puma/issues/1047#issuecomment-257904428
做了个例子,在 Linux 上 Rails 5.2,Ruby 2.5, Puma 以及 production
环境。
并发 (10 并) 用工具跑一段时间观察内存
我来实际试试,确实是之前的应用没有发现这样的情况,一些跑了好几个月的应用,内存最终都是稳定在一个位置的。
已修复,未发布
你一个接口要消耗 100M 内存?做了什么事情,载入大文件么?
GC 的机制,你请求结束以后,内存是不会立刻释放的,要等 GC 触发。如果 GC 触发以后还没回收,那就是可能有内存泄漏。
教你一个调试方法:
$ bundle open devise
在编辑器里面找到 app/controllers/devise/registrations_controller.rb
def create
# 末尾增加 puts 将 resource 打印出来,就能看到错误信息了
puts resource.inspect
end
或者你可以用 rails g devise:views
命令,生成出 Devise 的 views,并修改 devise/registrations/new.html.erb
<%= form_for(resource, as: resource_name, url: registration_path(resource_name)) do |f| %>
<% if resource.errors.any? %>
<ul>
<% resource.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
<% end %>
重新登录一次,评论和客户端的 Session 不一定是同步的,协调可能存在问题
那个默认页面?
你把 root_to 指向一个 API 不就可以了 或者删除 public/index.html
颇有朋友圈风格的标题
... 标题里面有个看不见的字符 <BS>
结果导致编辑的时候,浏览器 Input 组件 Bug 了,看不到 input 输入的内容
一言不合就换语言的态度,哪怕用来 Go 改写结果也一样
先要分析好资源耗费在哪里
你 3 台,撑 1 亿多动态请求/天(约 1000 QPS,或者更高峰值),已经很不错了!
多写写就成为老鸟了
年底有机会获得奔驰宝马福利车,我入职的时候觉得这个离我有点远,更像是公司招聘的一个“噱头”,没想到公司真的奖了我一台宝马; 🚗 🙏
666
Plugin 版本不支持很正常,你用的 Redmine 还是老版本
你需要检查 redmine_checklists 这个插件
不懂 Ruby 可以尝试用 Docker 安装 Redmine,避免各种环境的问题
Fetch current user in models:
https://rails-bestpractices.com/posts/2010/08/23/fetch-current-user-in-models
马上就要用 Active Storage 了,可以先看看新的方式
http://edgeguides.rubyonrails.org/active_storage_overview.html
关联之前关于 Ruby、Rails 流行度的讨论,上图 Rails 今年的下载量说明了一切。
怎么我看的对比数据,说的是目前提升还不是很明显呢
看错了,这个是有的 https://github.com/saberma/china_city
注意,那个 area.json 需要把台湾补上,不然会有问题,网监会找你麻烦
mini_magick 和 rmagick 的区别是,前者依靠 fork 来外部执行 ImageMagick,后者是引入 ImageMagick 实现 C 扩展,在 Ruby 内部调用。
前者执行效率低,后者容易内存泄露
字体之类的搜索 ImageMagick 的相关解决方法,都是一样的
回帖加精