{"id":1196,"date":"2026-09-21T22:39:59","date_gmt":"2026-09-21T22:39:59","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1196"},"modified":"2026-09-21T22:39:59","modified_gmt":"2026-09-21T22:39:59","slug":"file-descriptor-ulimits-vps-high-connection-counts","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/file-descriptor-ulimits-vps-high-connection-counts\/","title":{"rendered":"Raising File Descriptor and Process Limits on a VPS for High Connection Counts"},"content":{"rendered":"\n

Most services on a VPS have a hard ceiling that has nothing to do with CPU, RAM, or bandwidth: the number of open file descriptors and processes they are permitted. A socket is a file descriptor, so every connection your web server holds is a descriptor. When the limit is reached, the failure is abrupt and the error messages are misleading \u2014 accept4() failed (24: Too many open files)<\/code> in Nginx, or an application that simply stops responding. Here is how the limits stack and how to raise them once, correctly.<\/p>\n\n\n\n

Four layers, all of which must agree<\/h2>\n\n\n\n

This is the reason limit changes so often appear not to work. There is no single place to set this. A process receives the lowest<\/em> of five values, and any one of them left at its default silently caps everything.<\/p>\n\n\n\n

Layer<\/th>Where<\/th>Default<\/th>Notes<\/th><\/tr><\/thead>
Kernel global<\/td>fs.file-max<\/code><\/td>~1M<\/td>Rarely the limit on modern kernels<\/td><\/tr>
systemd manager<\/td>DefaultLimitNOFILE<\/code><\/td>1024<\/td>Caps every service systemd starts<\/td><\/tr>
systemd unit<\/td>LimitNOFILE=<\/code><\/td>inherits above<\/td>Per-service override<\/td><\/tr>
PAM \/ login<\/td>pam_limits.so<\/code> via \/etc\/security\/limits.conf<\/code><\/td>1024<\/td>Only affects interactive shells, not services<\/td><\/tr>
Process<\/td>ulimit -n<\/code><\/td>inherited<\/td>What the app actually sees<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The classic mistake is editing \/etc\/security\/limits.conf<\/code>, testing by logging in over SSH where it works, and wondering why Nginx still runs out. SSH sessions go through PAM; systemd services do not. Our VPS comparison page<\/a> is useful for picking a plan with enough memory to hold all those connections, but the limits themselves are yours to set.<\/p>\n\n\n\n

Reading what a running process is actually allowed<\/h2>\n\n\n\n

Never guess. Ask the kernel what the process has, and ask systemd what it was told to grant.<\/p>\n\n\n\n

# What the process actually has (works for any PID)\nPID=$(pgrep -o nginx)\ncat \/proc\/$PID\/limits | grep -Ei 'open files|processes'\n\n# What systemd thinks it granted\nsystemctl show nginx -p LimitNOFILE --value\n\n# The interactive-shell view (different number, usually)\nulimit -n; ulimit -u\n\n# Kernel-wide ceiling and current usage\nsysctl fs.file-max\ncat \/proc\/sys\/fs\/file-nr      # allocated  unused  max<\/code><\/pre>\n\n\n\n
If \/proc\/$PID\/limits<\/code> shows 1024 and systemctl show<\/code> also shows 1024, you know exactly which layer to fix. If systemd shows 65535 but the process shows 1024, the unit file or a drop-in is overriding it.<\/p>\n\n\n\n
A configuration that covers every layer<\/h2>\n\n\n\n
# 1. Kernel global\ncat >\/etc\/sysctl.d\/99-file-max.conf <\/etc\/security\/limits.d\/99-web.conf <<'EOF'\n*       soft    nofile  65535\n*       hard    nofile  65535\n*       soft    nproc   32768\n*       hard    nproc   32768\nroot    soft    nofile  65535\nroot    hard    nofile  65535\nEOF\n\nsysctl --system\nsystemctl daemon-reexec      # required for manager-level limits<\/code><\/pre>\n\n\n\n
systemctl daemon-reexec<\/code> is not optional \u2014 a plain daemon-reload<\/code> does not re-apply the manager’s own limits to services started afterward on older systemd versions. And on distributions that include a limits.d\/20-nproc.conf<\/code> file, a later-sorted file wins, so name yours 99-<\/code> to be sure. A common trap on CentOS-family images is root<\/code> being excluded from the *<\/code> wildcard, hence the explicit root lines.<\/p>\n\n\n\n
Per-service overrides<\/h2>\n\n\n\n
For a service, use a drop-in rather than editing the package’s unit file, which will be overwritten on upgrade.<\/p>\n\n\n\n
mkdir -p \/etc\/systemd\/system\/nginx.service.d\ncat >\/etc\/systemd\/system\/nginx.service.d\/limits.conf <<'EOF'\n[Service]\nLimitNOFILE=65535\nLimitNPROC=32768\nTasksMax=infinity\nEOF\n\nsystemctl daemon-reload && systemctl restart nginx\ncat \/proc\/$(pgrep -o nginx)\/limits | grep 'open files'<\/code><\/pre>\n\n\n\n
TasksMax<\/code> is easy to miss because it is a cgroup concept rather than a classic ulimit. With the systemd default of 15% of kernel.pid_max<\/code>, a worker-spawning service hits Failed to fork: Resource temporarily unavailable<\/code> long before nproc<\/code> matters.<\/p>\n\n\n\n
There is one more interaction worth knowing: fs.nr_open<\/code> caps what any single process may request, and it is the ceiling that LimitNOFILE<\/code> cannot exceed. If you set DefaultLimitNOFILE=1048576<\/code> while fs.nr_open<\/code> remains at its lower default, systemd will accept the configuration and the service will still start with the smaller number. Check sysctl fs.nr_open<\/code> before choosing a target, and raise both together rather than chasing the discrepancy later.<\/p>\n\n\n\n
Choosing a number<\/h2>\n\n\n\n