Performance Tuning for Red Hat Satellite 6.7

Solution Verified - Updated -

Environment

Satellite 6.7

Issue

This document aims to provide the guidelines for tuning Red Hat Satellite 6.7 for performance and scalability. Although a lot of care has been taken to make the content applicable to cover a wide set of use cases, in case of any use case that has not been covered, please feel free to reach out to Red Hat for support for the undocumented use case.

Red Hat Satellite is a complete system management product that enables system administrators to manage the full life cycle of Red Hat product deployments. It can manage these deployments across physical, virtual and private clouds. Red Hat Satellite delivers system provisioning, configuration management, software management, subscription management, and does so while maintaining high scalability and security.

Also see master 6.x performance tuning for all other versions

Notice if you fail to download the attached PDF: If downloading of the attachment fails, try to right click on the link and select "Save Link as .." option.

Attachments

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

6 Comments

Log in to comment
IK Red Hat Community Member 69 points
21 April 2020 11:47 AM

The tuning guide of the Satellite 6 has been moved to GitHub. Anyone who wants to contribute, please follow the normal PR process.

GitHub Repository

JC Active Contributor 191 points
3 June 2020 6:51 PM

Link to pdf does not open in pdf viewer. Does not download a pdf. Unreadable and unusable.

Bryan Kearney's picture Red Hat Expert 845 points
4 June 2020 5:46 PM

@Jim, I sent you an email with the pdf. Let me know if you did not get it.

BC Active Contributor 185 points
29 September 2020 9:11 PM

So this doc doesn't live with all the others of its type? Why's that?

Bryan Smith's picture Expert 834 points
29 December 2020 6:29 PM

DumbQ ... if we change some of the maximum open files by apache, qpid, etc..., do we not also need to do the same for Limits? E.g.,

    #
    # /etc/security/limits.d/60-satellite.conf

    #<domain>      <type>  <item>         <value>

    # Apache limits
    apache  soft  nofile  640000
    apache  hard  nofile  640000

    # qpidd / qdrouterd limitis
    qpidd       soft  nofile  150100
    qpidd       hard  nofile  150100
    qdrouterd   soft  nofile  65536
    qdrouterd   hard  nofile  65536
Pavel Moravec's picture Red Hat Guru 5148 points
25 January 2021 12:05 PM

There is no such need.

It is sufficient to change that in systemd unit config file. systemd will apply the limits properly to the spawned processes, while completely ignoring /etc/security/limits.* content.