How Many Files and TCP Connections Can a Linux Server Actually Handle?

Linux file‑descriptor limits

Linux treats every resource that can be opened as a file, so the total number of open files is limited by three kernel parameters:

fs.file-max – system‑wide maximum number of file descriptors (root is exempt).

soft nofile – per‑process soft limit.

fs.nr_open – per‑process hard limit; must be greater than or equal to the hard nofile value.

These values are coupled: increasing the soft limit requires raising the hard limit, and the hard limit must not exceed fs.nr_open. Changing one often requires adjusting the others.

Configuration example for 1,000,000 descriptors

# /etc/sysctl.conf
fs.file-max=1100000   # system‑wide buffer
fs.nr_open=1100000    # must be > hard nofile

Apply the changes: sysctl -p Then set per‑user limits:

# /etc/security/limits.conf
* soft nofile 1000000
* hard nofile 1000000

After editing, log out and back in (or restart the service) for the new limits to take effect.

Maximum TCP connections on a server

A TCP connection is represented by a four‑tuple (source IP, source port, destination IP, destination port). The theoretical upper bound is 2^32 × 2^16 ≈ 2×10^14 connections, but practical limits are imposed by CPU and memory.

For an idle ESTABLISHED connection the kernel consumes roughly 3.3 KB of memory (socket structure, buffers, bookkeeping). Therefore the number of concurrent idle connections is approximately: # connections ≈ total RAM (bytes) / 3.3 KB 4 GB RAM → ~1 000 000 idle connections.

128 GB RAM → ~38 000 000 idle connections (≈5 million practical connections when accounting for kernel overhead and other services).

When traffic is present, each connection also needs send/receive buffers and CPU for packet processing, so the real concurrency will be lower.

Maximum connections a client can initiate

Each outbound TCP connection consumes a local port. The usable port range is defined by net.ipv4.ip_local_port_range (default 32768‑60999, about 28 000 ports). The maximum number of connections depends on the combination of source IPs, destination IPs, and destination ports:

Single client IP, single server IP/port → up to 65 535 connections (theoretical port count).

n client IPs, single server IP/port → up to n × 65 535 connections.

Single client IP, m server ports → up to 65 535 × m connections.

If the default local‑port range is insufficient, it can be enlarged, e.g.:

# /etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65535

Other relevant kernel settings

net.core.somaxconn – size of the listen backlog (default 128). Raising it reduces SYN‑packet drops under high connection bursts.

After a process exits, its sockets may remain in TIME_WAIT. Waiting a short period (or tuning net.ipv4.tcp_tw_reuse and net.ipv4.tcp_tw_recycle) mitigates “port already in use” errors.

Explicitly binding a client socket to a specific local port overrides the kernel’s automatic port selection and is generally discouraged because it reduces the available port pool.

“Too many open files” error

The error occurs when a process exceeds the allowed number of file descriptors. Resolve it by increasing fs.file-max, the soft nofile limit, and fs.nr_open, ensuring the coupling relationships described above are respected.

Capacity‑planning example for a long‑connection push service

Assume a push‑notification service keeps long‑lived idle TCP connections. Each idle connection consumes ~3.3 KB of RAM. On a server with 128 GB memory:

# usable memory for sockets ≈ 20 GB
connections ≈ 20 GB / 3.3 KB ≈ 5 million

To support 100 million concurrent users, roughly 20 such servers would be sufficient (100 M / 5 M ≈ 20). This estimate assumes connections remain idle most of the time; active traffic will reduce the per‑server capacity.