Help Wanted: Align recommendations on file descriptor limits across all docs #4108
Labels
Area/Documentation Improvements
Improvements to documentation
Difficulty/2:Medium
Help Wanted
Community help wanted
Needs Documentation
Tech/RST
Tech/Sphinx
Up for Grabs
Context
File descriptors are an integer representing an abstract indicator used to access files or other input/output resources, such as pipes, network sockets, and devices.
Each process on a Unix-like operating system has a table of file descriptors, which it uses to keep track of the files it is interacting with.
The Mattermost server, being an application that heavily interacts with files, particularly for logging, temporary files, and user-uploaded content, requires a sizable number of file descriptors to operate efficiently.
Why is this important?
Limiting file descriptors helps with:
Keeping these limits appropriately set ensures that Mattermost can handle multiple users, concurrent connections, and throughput without running into resource constraints. Soft limits can be temporarily exceeded (up to the hard limit) if required.
How are they managed for Mattermost?
Mattermost System Admins can apply limits on the number of file descriptors allowed for the Mattermost server in 2 different ways:
mattermost.service
systemd unit file./etc/security/limits.conf
file.Docs Request
Update the Mattermost Product Documentation to help a system admin decide where to limit file descriptions (both
mattermost.server
andlimits.conf
), and detail the steps needed to limit file descriptors via with the following best practice recommendations for both soft and hard limits:where:
nofile
limits refer to the maximum number of open file descriptors a process can have at any given time. A highernofile
limit ensures the server can handle a large number of concurrent connections and file operations without running out of file descriptors.nproc
limits refer to the maximum number of processes (or threads) that a user can create. Ensuring a reasonablenproc
limit helps maintain system stability by preventing process exhaustion, which could otherwise affect not just the Mattermost service but the entire system.mattermost.service
via systemdUse this approach when configuring limits specifically and only for the Mattermost service. This is ideal for scenarios where isolated and controlled changes are necessary.
Example:
limits.conf
Use when you need to apply consistent limits across all processes run by a specific user or for legacy system compatibility. This is handy for scenarios requiring uniform configurations across a user’s entire session.
Note:
mattermost.service
affect all processes run by that user, not just the Mattermost service. This can lead to unintended side effects on other applications or services started by the same user.limits.conf
might be overridden or ignored by certain init systems or if specific per-service configurations exist, leading to potential conflicts or unexpected behaviors.Changes in
limits.conf
typically require users to log out and back in to take effect, which might necessitate a system restart to fully apply and ensure consistency.Example:
Internal Mattermost Docs Team follow-ups:
While we're here, we may need to do some cross-linking to make sure this information is easily discoverable.
For example, these guides should somehow bring me to this important consideration for large scale setups (i.e., file limit settings):
https://docs.mattermost.com/deployment/cluster.html
https://docs.mattermost.com/deployment/enterprise-deployment-guide.html
The text was updated successfully, but these errors were encountered: