ruby-on-rails - 为什么 GC stat minor_gc_count 递减?

标签 ruby-on-rails heroku garbage-collection

我们有一个 heroku 应用程序。当我早上检查 GC.stat 时,GC.stat[:minor_gc_count] 是 51。当天晚些时候它是 50。
根据我的理解,这应该是垃圾收集器做小扫的次数,所以第二天早上起来是有道理的,但为什么会减少呢?

>heroku run rails c --remote production
Running rails c on ⬢ ... up, run.2287 (Standard-1X)
Loading production environment (Rails 5.2.2.1)
irb(main):001:0> GC.stat
=> {:count=>63, :heap_allocated_pages=>1753, :heap_sorted_length=>1753, :heap_allocatable_pages=>0, :heap_available_slots=>714528, :heap_live_slots=>713742, :heap_free_slots=>786, :heap_final_slots=>0, :heap_marked_slots=>471239, :heap_eden_pages=>1753, :heap_tomb_pages=>0, :total_allocated_pages=>1753, :total_freed_pages=>0, :total_allocated_objects=>2802530, :total_freed_objects=>2088788, :malloc_increase_bytes=>65256, :malloc_increase_bytes_limit=>32225676, :minor_gc_count=>51, :major_gc_count=>12, :remembered_wb_unprotected_objects=>4626, :remembered_wb_unprotected_objects_limit=>8538, :old_objects=>458044, :old_objects_limit=>838856, :oldmalloc_increase_bytes=>65712, :oldmalloc_increase_bytes_limit=>19737900}
irb(main):002:0> exit
**Airbrake: closed
>heroku run rails c --remote production
Running rails c on ⬢... up, run.7226 (Standard-1X)
Loading production environment (Rails 5.2.2.1)
irb(main):001:0> GC.stat
=> {:count=>62, :heap_allocated_pages=>1618, :heap_sorted_length=>1913, :heap_allocatable_pages=>295, :heap_available_slots=>659511, :heap_live_slots=>659395, :heap_free_slots=>116, :heap_final_slots=>0, :heap_marked_slots=>467961, :heap_eden_pages=>1618, :heap_tomb_pages=>0, :total_allocated_pages=>1618, :total_freed_pages=>0, :total_allocated_objects=>2726093, :total_freed_objects=>2066698, :malloc_increase_bytes=>5662240, :malloc_increase_bytes_limit=>24780563, :minor_gc_count=>50, :major_gc_count=>12, :remembered_wb_unprotected_objects=>4632, :remembered_wb_unprotected_objects_limit=>9262, :old_objects=>456572, :old_objects_limit=>913146, :oldmalloc_increase_bytes=>7549584, :oldmalloc_increase_bytes_limit=>19737900}

最佳答案

问题可能出在测试本身。当您运行时 GC.stat它将返回有关您的 的信息当前正在运行的进程 .这很好。问题是每次运行

heroku run rails c --remote production

在您的控制台中,它不会连接到您当前在 Heroku 上运行的应用程序的进程。它将 启动新进程 对于控制台,您将返回 GC.stat对于这个新创建的进程,而不是应用程序响应 Web 请求的进程。这就是为什么它如此之低,甚至可能会减少的原因。

你实际上可以自己测试它。当您连接到 Heroku 上的 rails 控制台时,运行以下 ruby​​ 代码:
Process.pid

它将返回当前进程的 ID。然后从 Heroku 断开连接并重新连接并运行 Process.pid再次。您将看到它将返回不同的进程 ID,因为当您从控制台断开连接并为新连接创建新进程时,它停止了前一个进程。

您也可以尝试运行 GC.stat在这些连接中,您会看到,它们可能会有所不同,并且这些连接之间的计数可以上下波动,这是因为这些进程不相互依赖。

关于ruby-on-rails - 为什么 GC stat minor_gc_count 递减?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59198840/

相关文章:

sql - 为什么这个查询运行缓慢?

ruby-on-rails - Heroku - 在浏览器中显示当前提交的哈希值

java - Java 垃圾收集器如何处理自引用?

ruby-on-rails - ActiveRecord 模型测试的性能

ruby-on-rails - rails 4 : devise and omniauthable error

heroku - 如何在 heroku 上查看部署后脚本的输出?

私有(private)字段的Java垃圾回收

python - 如何在 Python 中检查容器类型对象的循环引用

ruby-on-rails - I18N 键,用于在模块中分组的 rails 模型

ruby-on-rails - Rails 范围适用于 SQLite 和 MySQL,但不适用于 Heroku (PostgreSQL)