Performance Tuning for Red Hat Satellite 6.7

Solution Verified - Updated -


Satellite 6.7


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.


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.


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

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

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

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

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

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.