Help Wanted: Align recommendations on file descriptor limits across all docs

[matterdoc]

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:

• resource management by preventing resource leaks or exhausting system resources
• predictable server performance, particularly during heavy loads
• system stability and ensuring that Mattermost doesn't interfere with other processes

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:

1. Setting those limits in the mattermost.service systemd unit file.
2. Modifying the /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 and limits.conf), and detail the steps needed to limit file descriptors via with the following best practice recommendations for both soft and hard limits:

* soft nofile 65536
* hard nofile 65536
* soft nproc 8192
* hard nproc 8192

where:

• nofile limits refer to the maximum number of open file descriptors a process can have at any given time. A higher nofile 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 reasonable nproc 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 systemd

Use 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:

[Service]
LimitNOFILE=65536

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:

• Changes to 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.
• Configurations in 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:

mattermost    soft    nofile    10240
mattermost    hard    nofile    40960

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

[cwarnermm]

@sadohert - Would you or a member of your team be open to creating a PR for this documentation request?