JMeter Too Many Open Files (ulimit)

Too Many Open Files in JMeter

Symptom

At high thread counts, samplers fail in the View Results Tree listener or jmeter.log with:

Response code: Non HTTP response code: java.net.SocketException
Response message: Non HTTP response message: Too many open files

CSV reading or log writing can fail with the same root cause:

java.io.IOException: Too many open files

The test usually passes with fewer threads and fails only once concurrency crosses a threshold.

Quick diagnosis (TL;DR)

Every open TCP connection, CSV file, and log handle consumes one operating system file descriptor. When the count exceeds the per-process limit (often 1024 on Linux, 256 on macOS), the JVM cannot open another socket and the sampler fails. Raise the limit in the shell that starts JMeter, or reduce how many descriptors each thread needs.

Common causes

Cause	Specific Error	Why it happens
High concurrency with short-lived connections	SocketException: Too many open files	Each request opens a new socket, and descriptors pile up faster than the OS reclaims them
Low default descriptor limit	Same error near 1024 or 256 active connections	Many Linux distributions default to a 1024 soft limit; macOS defaults to 256
Keep-Alive disabled	Socket count grows with thread count	Without connection reuse, one thread can hold many sockets across embedded resources
Listeners and CSV files in large plans	IOException: Too many open files	Open result files and data sets add to the descriptor count
Limit raised in the wrong shell	Error persists after ulimit -n	The new limit applies only to processes started from that shell session

Fix (ordered)

1. Confirm the current limit and usage

Check the soft limit of the shell you start JMeter from:

ulimit -n

For a running JMeter process, inspect the actual ceiling and current usage:

# Linux: hard and soft limits of the JVM process
cat /proc/<jmeter-pid>/limits | grep "open files"

# Count currently open descriptors
lsof -p <jmeter-pid> | wc -l

If the open count sits at the limit when failures start, this diagnosis is confirmed.

2. Raise the limit in the launching shell

File descriptor limits are inherited at process start, so raise the limit first and launch JMeter from the same shell:

ulimit -n 65536
./jmeter

A value of 65536 comfortably covers large single-machine tests. Setting the limit only in a different terminal, or after JMeter started, has no effect on the running JVM.

3. Make the limit persistent (Linux)

Shell changes vanish on logout. For a permanent limit, edit /etc/security/limits.conf (requires root):

*    soft    nofile    65536
*    hard    nofile    65536

If JMeter runs as a systemd service, set the limit in the unit file instead:

[Service]
LimitNOFILE=65536

4. Make the limit persistent (macOS)

# Session limit
ulimit -n 65536

# System-wide (survives reboot)
sudo launchctl limit maxfiles 65536 200000

5. Reduce descriptors per thread

Raising the limit treats the symptom; connection reuse lowers the demand:

• Enable Use KeepAlive in HTTP Request Defaults so threads reuse connections instead of opening one per request.
• Run in CLI mode (-n) with no GUI listeners; visual listeners hold extra file handles.
• Close CSV Data Sets that are no longer needed, and avoid opening a fresh file per iteration.

6. Verify under load

Re-run the test at the failing concurrency and watch descriptor usage during the run:

watch -n 5 "lsof -p <jmeter-pid> | wc -l"

Usage should now plateau well below the limit. If it grows without bound, keep-alive is not taking effect; re-check that the server actually honors persistent connections.

Related tools and topics

Resource	Use when
BindException / Address in use	The related ephemeral port exhaustion error
Thread Calculator	Estimating how much concurrency the generator should produce
Best practices	Listener and CLI-mode guidance for large tests
Docker / Kubernetes	Container runtimes apply their own descriptor limits

Frequently asked questions

What does Too many open files mean in JMeter?

The JVM tried to open a socket or file but the operating system refused because the process reached its file descriptor limit. It is an OS resource limit error, not a JMeter bug.

How do I check how many file descriptors JMeter is using?

On Linux, count them with lsof -p <jmeter-pid> | wc -l and compare against cat /proc/<jmeter-pid>/limits. On macOS, use lsof -p <pid> the same way.

Why does raising ulimit in another terminal not fix JMeter?

Limits are inherited when a process starts. The shell where you run ulimit -n must be the same shell that launches JMeter, and the change does not reach processes that are already running.

Should I set the limit to unlimited?

Prefer an explicit large value such as 65536. An unlimited setting can mask descriptor leaks, and the real fix is usually keep-alive plus a sane limit, not no limit at all.

Continue Learning

→

Next Practical Step

Raise the descriptor limit in the launching shell, enable Use KeepAlive, then re-run the test and watch the open descriptor count stay below the ceiling.

📖

Related Reference

• Distributed testing
• API load testing
• Best practices
• Troubleshooting overview