Increase file-max and nofile limit in Linux for MQ Installation

As an IT professional and technology enthusiast, I‘m always exploring ways to optimize system configurations for peak performance. One area that often gets overlooked is setting proper file handle limits for enterprise messaging middleware like IBM MQ. From my experience deploying MQ in production environments, I‘ve learned the hard way how important it is to increase the fs.file-max and nofile kernel limits beyond their default values.

In this comprehensive guide, I‘ll share my insights on:

What the fs.file-max and nofile limits control
Why MQ needs these limits increased
How to calculate appropriate limit values
Steps to configure the limits on common Linux distros
How to validate the new settings

My goal is to provide a detailed, yet easy to follow reference that can help fellow tech geeks avoid thepitfalls of undersized file handle limits when rolling out MQ.

A Quick Primer on File Handle Limits

First, let‘s briefly overview what these kernel limits control on Linux systems:

fs.file-max – This parameter sets the absolute maximum number of open file handles allowed on the entire system. It applies globally to all processes and users.

nofile – The nofile limit sets the maximum number of open files per process. It can be set individually per user/group in /etc/security/limits.conf.

The default fs.file-max is often set around 200,000. The default nofile limit varies but is usually 1024 or 4096.

For most Linux servers, these defaults are way too low for a high-throughput MQ implementation. MQ systems easily open hundreds of thousands of handles when handling heavy traffic loads. Hitting the limit causes errors and refused connections.

Let‘s take a deeper look at why MQ needs so many open files…

Why IBM MQ Needs Lots of Open File Handles

Based on my experience managing real-world MQ deployments, here are some of the main reasons the file handle requirements go so high:

Each concurrent client connection to the MQ queue manager uses at least one handle. For busy systems, you often see 50,000+ simultaneous connections.
MQ uses additional file handles for managing and syncing metadata on internal queues and logs. More queues means more handles.
Other compatible IBM middleware like API apps, MQ ACE, Integration Bus, and Managed File Transfer gobble up handles when integrated with MQ.
Handles are needed for dynamic libraries used by MQ channels and bindings. Channel count directly increases handle usage.

As you can see, it adds up fast! It‘s not uncommon to have MQ environments handling 100,000+ concurrent open file handles when operating under heavy loads.

This table shows some typical handle count examples:

Deployment Profile	Approx. Open Handles
Small dev/test environment	5,000
Medium workload production	25,000
Large enterprise site	100,000+

Table 1 – Approximate open file handles for MQ under various workload levels

Clearly, the default kernel limits will restrict this amount of handle usage!

Next, let‘s go over how to properly size these limits so MQ can operate without restrictions…

Calculating Appropriate Limits for Your MQ Implementation

As a rule of thumb, I recommend setting fs.file-max to at least 2x your expected max handle utilization.

For nofile, set it at least 1.5x higher than expected max handles for the mqm user that MQ runs as.

For example, if you estimate needing 100,000 handles on a busy production server, set:

fs.file-max to 200,000 or more

nofile for mqm user to 150,000 or more

This provides plenty of headroom so that load spikes don‘t cause problems.

On systems dedicated to MQ, you may even set these limits higher, like 1 million+ handles. There is no harm in oversizing them if you have the available memory.

Setting the Limits on Common Linux Distros

The steps to configure fs.file-max and nofile are very similar on most mainstream Linux distros like RHEL, CentOS, Ubuntu, SLES, etc. Here are the specifics:

fs.file-max:

Edit /etc/sysctl.conf and add a line like: fs.file-max = 1000000
Load new value immediately with: sysctl -p

nofile (for mqm user):

Edit /etc/security/limits.conf
Add lines like:

mqm          hard   nofile         150000
mqm          soft   nofile         150000

Reboot or logout/login to apply nofile

That‘s it! The OS will now respect the higher limits.

Validating the New Limit Settings

Once configured, verify the settings are active on the system:

# Check nofile 
ulimit -Hn 

# Check fs.file-max
sysctl fs.file-max

The output should match what you configured earlier.

The Impact of Properly Sized File Handle Limits

After increasing these limits per the guidance above on dozens of MQ servers over the years, I‘ve seen the positive impact firsthand.

Connections ramp up smoothly without hitting access denied errors as client load increases.
Queue managers remain stable and responsive under high traffic loads without crashing.
Integrated products like MB and API apps don‘t choke on handle exhaustion.
No more obscure "too many open files" messages!

It really makes a huge difference in unlocking the full potential of MQ. I hope this guide helps everyone learn from my experience when it comes to configuring file handle limits. Feel free to reach out if you have any other questions!