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

Add Concurrent.usable_processor_count that is cgroups aware #1038

Merged
merged 3 commits into from
Feb 1, 2024

Conversation

casperisfine
Copy link

Closes: #1035

A running gag since the introduction of containerization is software that starts one process per logical or physical core while running inside a container with a restricted CPU quota and totally blowing up memory usage in containerized environments.

The proper question to ask is how many CPU cores are usable, not how many the machine has. To do that we have to read the cgroup info from /sys. There is two way of doing it depending on the version of cgroups used.

Co-Authored-By: @usiegl00

@casperisfine
Copy link
Author

Arf:

     NoMethodError:
       undefined method `match?' for "linux":String

I'll fix 2.3 compat.

@casperisfine casperisfine force-pushed the cgroup-support branch 2 times, most recently from 2ad87f7 to aecdebb Compare January 29, 2024 16:43
Copy link
Collaborator

@eregon eregon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just need a bit more documentation care.

Closes: ruby-concurrency#1035

A running gag since the introduction of containerization is software
that starts one process per logical or physical core while running
inside a container with a restricted CPU quota and totally blowing
up memory usage in containerized environments.

The proper question to ask is how many CPU cores are usable, not how
many the machine has. To do that we have to read the cgroup info
from `/sys`. There is two way of doing it depending on the version
of cgroups used.

Co-Authored-By: usiegl00 <50933431+usiegl00@users.noreply.github.com>
Copy link
Collaborator

@eregon eregon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

spec/concurrent/utility/processor_count_spec.rb Outdated Show resolved Hide resolved
spec/concurrent/utility/processor_count_spec.rb Outdated Show resolved Hide resolved
spec/concurrent/utility/processor_count_spec.rb Outdated Show resolved Hide resolved
spec/concurrent/utility/processor_count_spec.rb Outdated Show resolved Hide resolved
@eregon eregon merged commit eae2851 into ruby-concurrency:master Feb 1, 2024
@casperisfine
Copy link
Author

Thanks!

@casperisfine casperisfine deleted the cgroup-support branch May 27, 2024 07:00
casperisfine pushed a commit to Shopify/rails that referenced this pull request May 29, 2024
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.

Thanks to ruby-concurrency/concurrent-ruby#1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
casperisfine pushed a commit to Shopify/rails that referenced this pull request May 29, 2024
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.

Thanks to ruby-concurrency/concurrent-ruby#1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
@nertzy
Copy link
Contributor

nertzy commented Jun 5, 2024

Thanks for this! The PR's title has a different method name than the one that landed. I added PR #1049 to fix the CHANGELOG.

xjunior pushed a commit to xjunior/rails that referenced this pull request Jun 9, 2024
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.

Thanks to ruby-concurrency/concurrent-ruby#1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
st0012 added a commit to getsentry/sentry-ruby that referenced this pull request Jul 6, 2024
It's a new API introduced in concurrent-ruby 1.3.1, which works better
in the container environment.

ruby-concurrency/concurrent-ruby#1038

Since there are gems like sorbet-runtime that still use older versions
of concurrent-ruby, we can't directly bump concurrent-ruby's requirement,
but need to check if the method is available before calling it.
jianbo pushed a commit to jianbo/fix-association-initialize-order that referenced this pull request Jul 8, 2024
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.

Thanks to ruby-concurrency/concurrent-ruby#1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
sl0thentr0py pushed a commit to getsentry/sentry-ruby that referenced this pull request Jul 9, 2024
* Use Concurrent.usable_processor_count when it is available

It's a new API introduced in concurrent-ruby 1.3.1, which works better
in the container environment.

ruby-concurrency/concurrent-ruby#1038

Since there are gems like sorbet-runtime that still use older versions
of concurrent-ruby, we can't directly bump concurrent-ruby's requirement,
but need to check if the method is available before calling it.

* Update changelog
y-yagi added a commit to y-yagi/parallel_tests that referenced this pull request Aug 6, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.

Ref: ruby-concurrency/concurrent-ruby#1038
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.

Ref: ruby-concurrency/concurrent-ruby#1038
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.

Ref: ruby-concurrency/concurrent-ruby#1038
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.

Ref: ruby-concurrency/concurrent-ruby#1038
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.
Ref: ruby-concurrency/concurrent-ruby#1038

I keep `Parallel.processor_count` as is to keep supporting setting
processor count via env(`PARALLEL_PROCESSOR_COUNT`).
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.
Ref: ruby-concurrency/concurrent-ruby#1038

I keep `Parallel.processor_count` as is to keep supporting setting
processor count via env(`PARALLEL_PROCESSOR_COUNT`).
y-yagi added a commit to y-yagi/parallel that referenced this pull request Aug 8, 2024
In containerized environments, a number of CPU cores isn't the
same as the available CPUs. In this case, we need to consider cgroups.

`concurrent-ruby` now has the method to get that since v1.3.1. I think it's better
to use this for setting more container environment friendly default value.
Ref: ruby-concurrency/concurrent-ruby#1038

I keep `Parallel.processor_count` as is to keep supporting setting
processor count via env(`PARALLEL_PROCESSOR_COUNT`).
DanielaVelasquez pushed a commit to DanielaVelasquez/rails that referenced this pull request Oct 3, 2024
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.

Thanks to ruby-concurrency/concurrent-ruby#1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
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

Successfully merging this pull request may close these issues.

4 participants