Feature request: add flag to opt in/out of Process.warmup about sidekiq HOT 7 CLOSED

I've read a bit about it since I find this a very interesting optimization and at least in webservers compaction can lead to bugs.

• puma/puma#3304
• Shopify/pitchfork#87

I'm uncertain if sidekiq would encounter similar troubles since it doesn't fork by itself. Enterprise is different I think (optionally).

from sidekiq.

You can disable warmup by calling cli.run(warmup: false) in bin/sidekiq. I don't see a need to make it any easier but you're welcome to make the case if you feel otherwise.

from sidekiq.

You can disable warmup by calling cli.run(warmup: false) in bin/sidekiq.

Sorry, when you say calling that in bin/sidekiq how do you suggest users do that? Are you suggesting I edit the sidekiq "binary" to change this and/or fork sidekiq? I would assume most people would launch sidekiq like the docs show by calling the executable and optionally passing it a config file: https://github.com/sidekiq/sidekiq/wiki/Advanced-Options#the-sidekiq-configuration-file

from sidekiq.

Copy bin/sidekiq to bin/sidekiqcold in your app, add the flag and run your testing. You’re just hacking this together to debug.

from sidekiq.

You’re just hacking this together to debug.

I am suggesting this as a long-term opt-out which I think people would like to be able to do (at least, I would like to be able to do--particularly deploying in this state) but I can work around this...

It just seems slightly aggressive to turn it on by default and not have an opt-out other than doing something very strange/hacky. That's just my $0.02.

from sidekiq.

I don't think of it as aggressive at all. Ruby documented its purpose and I don't recall hearing any drawbacks or danger in doing so. I added that warmup flag to be cautious but I don't think it's a good idea for anyone to opt-out long-term. It's a valuable point in time for the Ruby runtime to perform optimizations.

from sidekiq.

Our investigation is still underway, but we started seeing an issue in production where turning this off seems to have solved our problem.

We started seeing an issue where LaunchDarkly API calls would return FLAG_NOT_FOUND errors. It's still not clear to us if turning this off actually fixes the issue, or just changes timings enough to sidestep some race condition.

I agree that no opt-out makes sense if this is a stable change for most people. So just leaving a comment here as a single counter-example.

Also, just in case anyone else runs into this and needs to maintain a custom copy of bin/sidekiq, here's a spec that will fail when a release comes out with bin/sidekiq changes:

require 'rails_helper'

describe 'sidekq binary' do
  it 'should match the last validated file hash' do
    # last verified md5 hash of the sidekiq bin file
    expected_hash_value = "63e6c20e28e96a92442bf795998d4093"

    # get the sidekiq gem path using bundler
    bin_path = "#{Bundler.rubygems.find_name('sidekiq').first.full_gem_path}/bin/sidekiq"
    current_hash_value = Digest::MD5.file(bin_path).hexdigest

    # If this test fails, it means the last known MD5 hash value for the sidekiq bin file has changed.
    # This likely means the sidekiq bin file in our bin/ directory is out of date.
    # To fix this, you'll need to go assess the changes to the sidekiq version of the bin file
    # and make the appropriate updates to our bin file. After that, update the
    # expected_hash_value above to match the new file.
    expect(current_hash_value).to eq(expected_hash_value)
  end
end

from sidekiq.