truffleruby icon indicating copy to clipboard operation
truffleruby copied to clipboard

sidekiq test run failure

Open gogainda opened this issue 4 years ago • 8 comments

Tests are passing, but run test stage is failing

# Running:

/home/runner/work/sidekiq/sidekiq/vendor/bundle/truffleruby/21.1.0-dev-3b05154d/gems/rack-2.2.3/lib/rack/media_type.rb:18: warning: `&' interpreted as argument prefix
/home/runner/work/_temp/5ecf03dc-4058-4ee7-9ba1-cd5bb6a9ccd7.sh: line 1:  3639 Killed                  bundle exec rake
Error: Process completed with exit code 137.

from https://github.com/gogainda/sidekiq/runs/1965922052?check_suite_focus=true

gogainda avatar Feb 24 '21 09:02 gogainda

exit code 137 typically means out of memory. We should investigate what takes so much memory.

eregon avatar Feb 24 '21 09:02 eregon

on my local machine I dont have such issue, but probably GH Actions are more restrictive in terms of available RAM

gogainda avatar Feb 24 '21 10:02 gogainda

In case it's useful, I was previously trying configuring memory here to see how it affects sidekiq performance: https://github.com/oracle/truffleruby/issues/1584#issuecomment-624934453

bjfish avatar Feb 24 '21 15:02 bjfish

@bjfish https://github.com/gogainda/sidekiq/commit/860ab19a6ee2b73b84f374e632c3b2d274540617 am I using it correctly?

gogainda avatar Feb 24 '21 18:02 gogainda

@gogainda yes, that looks good to me.

bjfish avatar Feb 24 '21 18:02 bjfish

https://github.com/gogainda/sidekiq/runs/1972543062 same issue

gogainda avatar Feb 24 '21 18:02 gogainda

@gogainda I also see the error Process.fork is not supported by this Ruby in the linked runs you provided. This should also be resolved. This fork error may be from minitest, in that case, the environment variable MT_CPU=1 could be set to disable the call to fork.

bjfish avatar Feb 24 '21 18:02 bjfish

GitHub runners have 8GB of RAM IIRC, so --vm.Xmx16G --vm.Xmn4G doesn't seem good there, the default memory settings should be adapted to the actual RAM available. We should reproduce locally with something like --vm.Xmx8G (or lower if needed) and see if we can reproduce the failure and find out what's using so much memory.

eregon avatar Feb 25 '21 11:02 eregon