Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

concurrent-ruby Fixed Thread Pool memory leak #3558

Open
brauliobo opened this issue Apr 26, 2024 · 2 comments
Open

concurrent-ruby Fixed Thread Pool memory leak #3558

brauliobo opened this issue Apr 26, 2024 · 2 comments
Assignees

Comments

@brauliobo
Copy link
Contributor

brauliobo commented Apr 26, 2024

When running an update on a large dataset I'm seeing a big and steady memory leak with TruffleRuby. The code is proprietary but in essence it is based on a FixedThreadPool from concurrent-ruby:

def ds_waning_peach limit: 1_000, offset: nil
  ds = self.limit limit
  page = ds.all
  pool_run do |pool|
    begin 
      page.each{ |r| pool.post{ yield r } }
      sleep 1 while pool.queue_length > pool.max_length * 2
    end while (page = ds.offset(pool.queue_length).all).present?
  end
end

The above code runs on a large Sequel dataset with a PostgreSQL database.

TruffleRuby Native: steady and quite fast memory increase (40gb after 1h of CPU usage)
image

TruffuleRuby JVM: slower but steady memory increase (25gb after 1h of CPU usage)
image

In the screenshot above Ruby 3.1.2 compiled with jemalloc (pid 1006066) is also running with memory usage stabilized at around 1.2gb

So the same code is run with the 3 rubies, also with the same Gemfile.lock.

@andrykonchin
Copy link
Member

Thank you for the report, we'll look into it.

@andrykonchin andrykonchin self-assigned this Apr 30, 2024
@eregon
Copy link
Member

eregon commented May 3, 2024

Could you share a reproducer we can run?
It's very difficult to diagnose this without being able to run it.

Note also that the JVM (and Native Image too BTW) uses up to its Xmx (which defaults to 25% of total physical RAM with G1 GC if no Xmx is passed) if it thinks it's more efficient for the GC/allocations/etc. So one thing you could try is to pass e.g. --vm.Xmx4g to e.g. tell it to use 4GB max.
If that still uses way more memory than the Xmx it might be an issue with native memory allocation or maybe allocations by the JIT compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants