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

100% CPU Usage On Puma Workers at "idle" in Development. #361

Open
joshuapinter opened this issue Jul 6, 2021 · 9 comments
Open

100% CPU Usage On Puma Workers at "idle" in Development. #361

joshuapinter opened this issue Jul 6, 2021 · 9 comments

Comments

@joshuapinter
Copy link

Hey There,

Enabling skylight in development causes a strange situation where Puma workers remain at about 100% CPU utilization even after the request has been complete.

Without skylight enabled in development and 5 seconds after the web request is complete:

# config.skylight.environments += [ "development" ]

Screenshot 2021-07-06 at 10 46 05

With skylight enabled in development and 5 seconds after the web request is complete:

config.skylight.environments += [ "development" ]

Screenshot 2021-07-06 at 10 48 21

And it stays like this in perpetuity.

The only thing that is being changed is that one line.

We checked in production/staging and are not seeing this CPU issue.

Happy to help diagnose but not sure what the next steps may be. For now, we have to disable it in development as it makes our development machines unusable.

Thanks.

Versions

ruby 2.7.2p137
Rails 5.2.6
skylight 5.1.1
puma 5.3.2
@wagenet
Copy link
Contributor

wagenet commented Jul 6, 2021

@joshuapinter This is definitely surprising. We use puma ourselves and don't experience this issue so it seems likely to be something related to a specific configuration. Would you might sharing your Puma config?

@joshuapinter
Copy link
Author

Thanks for the quick response. Here's the puma config we're using:

puma.rb

bind "tcp://0.0.0.0:3000" 
workers 8
threads 0, 1
preload_app!

@wagenet
Copy link
Contributor

wagenet commented Jul 6, 2021

@joshuapinter thanks for sharing. Unfortunately, my colleague most equipped to investigate this is currently taking some PTO. I'll try to investigate some before he's back, but please bear with us if it takes a little bit for us to resolve this. Thanks.

@joshuapinter
Copy link
Author

joshuapinter commented Jul 6, 2021

No worries, @wagenet. There's no rush, as the most important environments are production and staging. Keep me posted on anything I can do to help diagnose. Thanks.

@zvkemp
Copy link
Contributor

zvkemp commented Jul 14, 2021

Hi @joshuapinter, thanks for your patience! There is some additional information that might be helpful:

  • It looks like you're on a Mac, is that accurate?
  • Which processor architecture do you have? The output of uname -a may be helpful
  • Using Activity Monitor, Could you sample the ruby process when it's under high CPU? A second or two should be enough to see what stack frames are active. You can email the result to us at support@skylight.io.

@joshuapinter
Copy link
Author

Hi @joshuapinter, thanks for your patience! There is some additional information that might be helpful:

Hi @zvkemp, thanks for the response.

  • It looks like you're on a Mac, is that accurate?

Correct.

  • Which processor architecture do you have? The output of uname -a may be helpful
Darwin 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
  • Using Activity Monitor, Could you sample the ruby process when it's under high CPU? A second or two should be enough to see what stack frames are active. You can email the result to us at support@skylight.io.

Sent!

Thanks.

@zvkemp
Copy link
Contributor

zvkemp commented Jul 15, 2021

Thanks for the sample. Skylight's task thread doesn't appear to be doing anything abnormal; as far as I can tell the only active thread (i.e., not waiting on a condition variable or IO) is Puma's reactor, so the question remains why the addition of Skylight would cause this. Can you try running Puma in single mode rather than cluster mode and let us know if the problem occurs there as well?

@joshuapinter
Copy link
Author

Hey @zvkemp. I checked when running Puma in single mode (with workers commented out) and the issue was not present.

@jnimety
Copy link

jnimety commented Aug 19, 2021

Hello! I don't know if our issue is related but we're experiencing Puma workers randomly remaining at 100% in our production environment. There is this thread_pool issue that was fixed in Puma 5.4.0 puma/puma#2656 but it didn't fix the issue for us.

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

4 participants