Open brodock opened 5 years ago
Thank you for the bug report, we'll try to take a look and reproduce it.
@eregon is there a way to capture realtime memory usage of the given ruby process?
Yes, there is GC.stat
and GC.stat(key)
:
$ ruby -e 'pp GC.stat'
{:time=>24,
:count=>3,
:minor_gc_count=>3,
:major_gc_count=>0,
:unknown_count=>0,
:heap_available_slots=>530579456,
:heap_live_slots=>54923264,
:heap_free_slots=>475656192,
# the 4 stats related to heap size:
:used=>54923264,
:committed=>530579456,
:init=>526385152,
:max=>8420065280}
So GC.stat(:used)
is the actual usage, in bytes.
I sometimes just this - as long as you only do it once a second or so it's fine.
`ps -o rss #{Process.pid}`.lines[1].to_i
I sometimes just this - as long as you only do it once a second or so it's fine.
That's the whole process rss so it's a different measurement, but can also be useful, and closer to what e.g. the Activity Monitor would report.
Above we see actual heap usage is ~50MB, committed ~500MB, initial ~500MB and max ~8GB (the defaults on my system, on JVM).
The JVM and Native Image will typically take up to the maximum memory relatively quickly in order to improve performance (GC is typically more efficient on bigger heaps), if one is constrained with memory or want lower memory usage they can set --vm.Xmx
(e.g. --vm.Xmx4g
), that can slow things down though.
I was trying out truffleruby with a small gem to see how it would perform against MRI : https://gitlab.com/gitlab-org/gitlab_kramdown/blob/improve-benchmark/benchmark/benchmark.rb and one thing that caught my attention was the fact that it was allocating memory on the GBs.
The same benchmark when running on MRI would consume about 30-40MB and stay constant at that level.