-
Notifications
You must be signed in to change notification settings - Fork 95
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
update puma threads tunings #3248
Conversation
The PR preview for e388b42 is available at theforeman-foreman-documentation-preview-pr-3248.surge.sh The following output files are affected by this PR: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
three more small suggestion, then I'd merge.
@maximiliankolb Hello, if all looks good to you can I squash all the commits into one? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Imaanpreet diff LGTM. Merging is currently blocked by GitHub. Please rebase to "master" and resolve the merge conflicts.
triage: @Imaanpreet friendly reminder: please rebase to "master" and resolve the merge conflict. diff LGTM |
Sorry for delayed changes @maximiliankolb, I have missed your reminder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small fix, then we're good to go.
Apply suggestions from code review looks good. thank you guys! Co-authored-by: Aneta Šteflová Petrová <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@Imaanpreet You are requesting cherry picks into a few selected versions only, skipping quite a few in between. Is there a reason for that? I'd also appreciate it if you provided some more details about this update by filling out the template in the PR description. |
Hello Team, I am not sure why I can't get the updates (via emails) and I end up delaying the response :( |
@Imaanpreet Please ping an engineer to do a technical review. |
Hello @maximiliankolb ! Basically Imaan is the engineer here who measured this stuff. I approve this PR. |
(cherry picked from commit 1675c0a)
(cherry picked from commit 1675c0a)
Thanks for the additional ack, @jhutar! To explain: We've been evaluating our review process and part of that is standardizing who we ask to review doc PRs. For example, one suggestion that has been floated around recently is to ask a developer and a QA engineer to review each doc PR, to get multiple perspectives. Thanks for working with us on this PR. |
@Imaanpreet Thank you for working on this! I hit a conflict on 3.11 so I didn't cherry-pick there. If you think the update should be included on 3.11 and below, can you please create a separate PR? If you don't think it's necessary, I'm fine with that too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have a strong opinion that users shouldn't touch these values if we can avoid it. The values are automatically determined and if that's incorrect then we should fix it. For example, theforeman/puppet-foreman#1197.
My preference would be to drop this whole chapter or make it more like Puma's official documentation (https://msp-greg.github.io/puma/#thread-pool) with specific recommendations for our application.
@@ -1,21 +1,13 @@ | |||
[id="Puma_Threads_{context}"] | |||
= Puma threads | |||
|
|||
Number of Puma threads (per Puma worker) is configured by using two values: `threads_min` and `threads_max`. | |||
To configure the number of Puma threads (per Puma worker), use these values: `threads_min` and `threads_max`. | |||
|
|||
Value of `threads_min` determines how many threads each worker spawns at a worker start. | |||
Then, as concurrent requests are coming and more threads is needed, worker will be spawning more and more workers up to `threads_max` limit. | |||
|
|||
We recommend setting `threads_min` to same value as `threads_max` as having fewer Puma threads lead to higher memory usage on your {ProjectServer}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since https://projects.theforeman.org/issues/33214 (Foreman 3.1) this is the default behavior if you don't specify the min value.
Can we drop this line?
Setting the minimum Puma threads to `16` results in about 12% less memory usage as compared to `threads_min=0`. | ||
For example, we have compared these two setups on a virtual machine with 8 CPUs and 40 GiB RAM using concurrent registrations test. | ||
They both used `--foreman-foreman-service-puma-threads-max=16` and `--foreman-foreman-service-puma-workers=2`. | ||
Setting the minimum Puma threads to `16` by using `--foreman-foreman-service-puma-threads-min=16` results in about 12% less memory usage as compared to `0`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is the default behavior, should we drop this line altogether and avoid users touching --foreman-foreman-service-puma-threads-min
?
What changes are you introducing?
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Checklists
Please cherry-pick my commits into: