Description of problem: Since satellite 6.9 imports new component puma, and in the performance guide https://access.redhat.com/sites/default/files/attachments/performance_tuning_for_red_hat_satellite_6.9_0.pdf, it just shows some comparative data between different count of CPUs. So what's the suggested workers number for different CPU numbers? Can we tune it in the predefined profile? I'm wondering if we can write an insights rule for it. However, if it will be done in the predefined profiles soon, maybe we don't need to add it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Note: this should also include removing Passenger tuning parameters from the tuning profiles
*** Bug 1965852 has been marked as a duplicate of this bug. ***
Hello, the tuning guide of sat 6.10 has recommendations as how to tune puma accordingly predefined tuning profiles. You can find all the details here - [https://github.com/RedHatSatellite/satellite-performance-tuning/blob/devel/docs/satellite-configuration-tuning.rst#puma-tunings|http://example.com] Please feel free to open an issue on github if you have any suggestions/recommendations/questions. Thank you.
The docs are an improvement. The current scenarios/text is too much focussed on registration peformance. It shall also take into account memory aware situations. In my case the default tuning was using too much memory usage that there is OOM-killed processes leading risking data corruption. Stability/Reliablity is therefor also a key element that shall be taken into consideration and not only pure/raw performace Why is the focus so much on registrations? What about regular puppet and yum checkins? To understand the differences and trades off better having also the absolute values seen in the test scenarios in a short table for quick references what i as an user can expect - Memory usage - CPU usage - Number of registrations/yum/puppet tasks Example that is not clear to me the impact on memory is the scenario https://github.com/RedHatSatellite/satellite-performance-tuning/blob/devel/docs/satellite-configuration-tuning.rst#setting-threads-min-max--workers where there is a difference between workers and threads, what is the impact on memory here? Also is the table with the memory really correct https://github.com/RedHatSatellite/satellite-performance-tuning/blob/devel/docs/satellite-configuration-tuning.rst#recommendations ? I do not have 10000 hosts, but i still need 64GB/16cpu to make sure there is also enough memory/cpu for Puppet (peak usage 8-12CPUs and 15-20GB of memory) to not run into timeouts. Peter
The original BZ was targeted at having predefined Puma configuration tuning values in the tuning profile. Due to how the installer works, the best we can currently do is what presently exists -- default auto-calculated values and the updated tuning guide for how to use installer arguments to further tune. From that perspective, I would consider this BZ ready to be verified with Satellite 6.11. Additional comments in the BZ provide feedback for performance test cases to consider and further add to the tuning guide. Some of these are in the works already and the others we can take under advisement. I would not like to continue to tie this BZ to that request as requesting additional performance tuning scenarios should be a stand-alone, dedicated request per requested scenario so that we may tackle them one by one. From this point on, any specific tuning issues I would ask are opened as specific follow up BZs to make them easier to undertake and provide changes for by us.
Given we have Satellite installer auto-tuning configuration now and docs on how to change defaults in the tuning guide: https://docs.theforeman.org/nightly/Performance_Tuning_Guide/index-foreman-el.html#Puma_Workers_and_Threads_Auto_Tuning_performance-tuning (note the tuning guide was migrated to upstream now). We are now also reviewing memory consumption in bug 2025811, so there might be future updates to the tuning guide recommendations.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:5498