Nginx ошибка 24 too many open files

Очень часто при работе на высоконагруженных Linux серверах могут возникать ошибки “too many open files”. Это означает, что процесс открыл слишком много файлов (читай файловых дескрипторов) и не может открыть новые. В Linux ограничения “max open file limit“ установлены по умолчанию для каждого процесса и пользователя, и они не слишком высокие.

В данной статье мы рассмотрим, как проверить текущие ограничения на количество открытых файлов в Linux, как изменить этот параметр для всего сервера, для отдельных сервисов и для сеанса. Статья применима для большинства современных дистрибутивов Linux (Debian, Ubuntu, CentOS, RHEL, Oracle Linux, Rocky и т.д.)

Ошибка: Too many open files и лимиты на количество открытых файлов в Linux

Чаще всего ошибку “too many open files“. Чаще всего эта ошибка встречается на серверах с установленным веб-сервером NGINX/httpd, сервером БД (MySQL/MariaDB/PostgreSQL), при чтении большого количества логов. Например, когда веб-серверу Nginx не хватает лимита для открытия файлов, вы получите ошибку:

socket () failed (24: Too many open files) while connecting to upstream

Или:

HTTP: Accept error: accept tcp [::]:<port_number>: accept4: too many open files.

В Python:

OSError: [Errno 24] Too many open files.

Максимально количество файловых дескрипторов, которые могут быть открыты в вашей файловой системе всеми процессами можно узнать так:

# cat /proc/sys/fs/file-max

Чтобы узнать, сколько файлов открыто сейчас, выполните:

$ cat /proc/sys/fs/file-nr

7744    521      92233720

• 7744 — суммарное количество открытых файлов
• 521– число открытых файлов, но которые сейчас не используются
• 92233720– максимальное количество файлов, которое разрешено открывать

В Linux ограничение на максимальное количество открытых файлов можно натсроить на нескольких уровнях:

• Ядра ОС
• Сервиса
• Пользователя

Чтобы вывести текущее ограничение на количество открытых файлов в ядре Linux, выполните:

# sysctl fs.file-max

fs.file-max = 92233720

Выведем ограничение на количество открытых файлов для одного процесса текущего пользователя:

# ulimit -n

По умолчанию количество файлов для одного процесса этого ограничено числом 1024.

Выведем максимальное количество для одного пользователя (max user processes):

# ulimit –u

5041

Умножаем 1024 * 5041 дает нам 5161984 – это максимально количество открытых файлов всеми процессами пользователя.

В Linux есть два типа ограничений на количество открытых файлов: Hard и Soft. Soft ограничения носят рекомендательный характер, при превышении значения пользователь будет получать предупреждения. Если количество открытых файлов превысило hard лимит, пользователь не сможет открыть новые файлы пока не будет закрыты ранее открытые.

Для просмотра текущих лимитов используется команда ulimit с опцией
-S
(soft) или
-H
(hard) и параметром
-n
(the maximum number of open file descriptors).

Для вывода Soft-ограничения:

# ulimit -Sn

Для вывода Hard-ограничения:

# ulimit -Hn

Глобальные ограничения на количество открытых файлов в Linux

Чтобы разрешить всем сервисам открывать большее количество файлов, можно изменить лимиты на уровне всей ОС Linux. Чтобы новые настройки работали постоянно и не сбрасывались при перезапуске сервера или сессии, нужно поправить файл /etc/security/limits.conf. Строки с разрешениями выглядит так:

Имя_пользователя тип_огрничение название_ограничения значение

Например:

apache  hard nofile 978160
apache soft nofile 978160

Вместо имени пользователя можно указать
*
. Это означает, что это ограничение будет применяться для всех пользователей Linux:

* hard nofile 97816
* soft nofile 97816

Например, вы получили ошибку too many open files для nginx. Проверьте, сколько файлов разрешено открывать процессу этому пользователю:

$ sudo -u nginx bash -c 'ulimit -n'

1024

Для нагруженного сервера этого недостаточно. Добавьте в /etc/security/limits.conf строки

nginx hard nofile 50000
nginx soft nofile 50000

В старых ядрах Linux значение fs.file-max может быть равно 10000. Поэтому проверьте это значение и увеличьте его, чтобы оно было больше чем ограничение в limits.conf:

# sysctl -w fs.file-max=500000

fs.file-max = 500000

Проверьте, что в файле /etc/pam.d/common-session (Debian/Ubuntu или /etc/pam.d/login для CentOS/RedHat/Fedora) есть строчка:

session required pam_limits.so

Если нет, добавьте ее в конец. Она нужна, чтобы ограничения загружались при авторизации пользователя.

После изменений, перезапустите терминал и проверьте значение лимита max_open_files:

# ulimit -n


97816

Увеличить лимит открытых файловых дескрипторов для отдельного сервиса

Вы можете изменить лимит на количество открытых файловых дескрипторов для конкретного сервиса, а не для всей системы. Рассмотрим на примере apache. Чтобы изменить значения, откройте настройки службы через systemctl:

# systemctl edit httpd.service

Добавьте необходимые лимиты, например:

[Service]
LimitNOFILE=16000
LimitNOFILESoft=16000

После изменения, нужно обновить конфигурацию сервиса и перезапустить его:

# systemctl daemon-reload
# systemctl restart httpd.service

Чтобы проверить, изменились ли значения, нужно получить PID сервиса:

# systemctl status httpd.service

Например, вы определил PID сервиса 32724:

# cat /proc/32724/limits | grep "Max open files”

Значение должно быть 16000.

Так вы изменили значения Max open files для конкретного сервиса.

Увеличить количество открытых файлов для Nginx и Apache

После того, как вы увеличил ограничения на количество открытых файлов для сервера, нужно также поправить конфигурационный файл службы. Например, для веб-сервера Nginx в файле конфигурации /etc/nginx/nginx.conf нужно задать значение в директиве:

worker_rlimit_nofile 16000

Директива worker_rlimit_nofile задает ограничение на количество файлов, открытых в рабочем процессе (
RLIMIT_NOFILE
). В Nginx файловые дескрипторы нужны для возврата статического файла из кэша для каждого подключения клиента. Чем больше пользователей использует ваш сервер и чем больше статических файлов отдает nginx, тем большее количество дескрипторов используется. Сверху максимальное количество дескрипторов ограничивается на уровне ОС и/или сервиса. При превышении количеств открытых файлов nginx появится ошибка
socket() failed (24: Too many open files) while connecting to upstream
.

При настройке Nginx на высоконагруженном 8-ядерном сервере с worker_connections 8192 нужно в worker_rlimit_nofile указать 8192*2*8 (vCPU) = 131072.

После чего выполнить рестарт Nginx:

# nginx -t && service nginx -s reload

Для apache, нужно создать директорию:

# mkdir /lib/systemd/system/httpd.service.d/

После этого создайте файл limit_nofile.conf:

# nano /lib/systemd/system/httpd.service.d/limit_nofile.conf

И добавьте в него:

[Service]
LimitNOFILE=16000

Не забудьте перезапустить сервис httpd.

Лимиты file-max для текущей сессии

Чтобы изменить лимиты на открытые файлы в рамках текущей сессии пользователя, выполните команду:

# ulimit -n 3000

Если указать здесь значение большее, чем заданное в hard limit, появится ошибка:

-bash: ulimit: open files: cannot modify limit: Operation not permitted

Когда вы завершите текущую сессию терминала и откроете новую, лимиты вернутся к начальным значениям, указанным в файле /etc/security/limits.conf.

В данной статье мы разобрались, как решить проблему с недостаточным лимитом для открытых файловых дескрипторов в Linux и рассмотрели несколько вариантов изменения лимитов на сервере.

[I posted this on the Nginx forums, but had no responses a week later, so trying here]

I am a Linux and Nginx novice, but have learnt enough to get it installed and running and working as a simple reverse proxy for two internal webservers. This has been running fine for months, but I recently started getting 500 errors.

Here is the recent output of /var/log/nginx/error.log
(I have replaced our company name with «companyname.com» and replaced our public WAN IP address with

2020/02/10 15:17:49 [alert] 1069#1069: *1011 socket() failed (24: Too many open files) while connecting to upstream, client: 10.10.10.1, server: web1.companyname.com, request: "GET / HTTP/1.0", upstream: "https://<WANIP>:443/", host: "web1.companyname.com"

2020/02/10 15:21:41 [alert] 1069#1069: *2022 socket() failed (24: Too many open files) while connecting to upstream, client: 10.10.10.1, server: web2.companyname.com, request: "GET / HTTP/1.0", upstream: "https://<WANIP>:443/", host: "web2.companyname.com"

2020/02/10 15:33:28 [alert] 1084#1084: *19987 socket() failed (24: Too many open files) while connecting to upstream, client: 10.10.10.1, server: web2.companyname.com, request: "GET / HTTP/1.0", upstream: "https://<WANIP>:443/", host: "web2.companyname.com"

2020/02/10 15:34:16 [alert] 1084#1084: *39974 socket() failed (24: Too many open files) while connecting to upstream, client: 10.10.10.1, server: web1.companyname.com, request: "GET / HTTP/1.0", upstream: "https://<WANIP>:443/", host: "web1.companyname.com"

2020/02/10 15:50:30 [error] 1086#1086: *1 client intended to send too large body: 4294967295 bytes, client: 176.58.124.134, server: london.companyname.com, request: "GET /msdn.cpp HTTP/1.1", host: "<WANIP>"

2020/02/10 16:32:56 [alert] 1086#1086: *19989 socket() failed (24: Too many open files) while connecting to upstream, client: 10.10.10.1, server: web1.companyname.com, request: "GET / HTTP/1.0", upstream: "https://<WANIP>:443/", host: "web1.companyname.com"

I have added the following to the end of /etc/security/limits.conf

nginx soft nofile 10000
nginx hard nofile 30000

I have added the following to /etc/sysctl.conf

fs.file-max=70000

…And rebooted. However, I’m getting the same problem immediately after a reboot.

Interestingly the IP address that appears in the log «176.58.124.134» I don’t recognise and a quick google search suggests this is an abusive IP address. I can block at the firewall, but I’m not sure that’s the problem.

Any tips, suggestions are grealy appreciated. Thanks.

Our monitoring informed me about a HTTP 500 error from a central reverse proxy running with Nginx. Checking the error logs revealed the following issue:

2019/05/09 08:43:35 [crit] 25655#0: *524505514 open() «/usr/share/nginx/html/50x.html» failed (24: Too many open files)
[…]
2019/05/09 09:04:27 [alert] 28720#0: *59757 socket() failed (24: Too many open files) while connecting to upstream,

This basically means that the Nginx process had too many files open, which could also be checked on the Nginx status page. Here the graph from check_nginx_status.pl:

The default is set to a limit of 4096 files per (worker) process, which can be seen in /etc/default/nginx:

# cat /etc/default/nginx
# Note: You may want to look at the following page before setting the ULIMIT.
#  http://wiki.nginx.org/CoreModule#worker_rlimit_nofile
# Set the ulimit variable if you need defaults to change.
#  Example: ULIMIT=»-n 4096″
#ULIMIT=»-n 4096″

However don’t be fooled. Changing this file doesn’t help. Instead this needs to be set in /etc/security/limits.conf:

Here a soft limit of 30k and a hard limit of 50k files are defined per nginx process.

Note: I tried this here with www-data first (the user under which Nginx runs), but this didn’t work. Although a user name could be used as a «domain» in this config file…

Additionally Nginx should be told how many files can be opened. In the main config file /etc/nginx/nginx.conf add:

After a service nginx restart the limits of the worker processes can be checked:

The «too many open files» errors disappeared from the Nginx logs after this change.

But what did cause this sudden problem? As you can see in the graph above this Writing (and Waiting) connections suddenly sharply increased. It turned out that an upstream server behind this reverse proxy did not work anymore and this particular virtual host received a lot of traffic, causing general slowness and holding files open while waiting for a timeout from Nginx (504 in this case).

Different solution when using Systemd

Update: February 1st 2021: The above fix was written two years ago and was working fine on a system without Systemd as init system. However when Nginx is started and controlled by Systemd, the limits defined in /etc/security/limits.conf seem to be ignored. Instead Systemd applies its own default limits. See Fredrik Averpil’s blog post for additional info.

This can be nicely verified. An unlimited nofile limit was defined for multiple domains in /etc/security/limits.conf to see which would be applied to Nginx’s processes:

root@nginx:~# cat /etc/security/limits.conf
[…]
# Added Nginx nofile limit
nginx       soft    nofile  50000
nginx       hard    nofile  80000
root       soft    nofile  unlimited
root       hard    nofile  unlimited
www-data    soft    nofile  unlimited
www-data    hard    nofile  unlimited

But after setting worker_rlimit_nofile in nginx.conf and a restart of Nginx, the limits still exists:

Even the nginx master process, executed as root, still has a file limit of 1024 (soft) and 4096 (hard).

This obviously causes errors when Nginx needs to open new sockets or file handlers and the error log can contain events like this:

2021/02/01 09:28:13 [emerg] 28935#28935: open() «/var/log/nginx/example.com.access.log» failed (24: Too many open files)

To solve this, the limits must be changed in the Systemd service unit configuration for Nginx. The quickest way to do this is to copy the original Nginx service unit and add the LimitNOFILE option:

Note: A more proper solution is to create a service sub-directory (/etc/systemd/system/nginx.service.d) and append the LimitNOFILE option into a single config file with a [Service] section.

After another Nginx restart, the new limits can be verified:

The limit, configured in Systemd’s service unit file for Nginx, is applied for both master and worker processes.

Add a comment

Show form to leave a comment

Comments (newest first)

bao from wrote on Mar 6th, 2023:

thanks. It helped me.

moh from wrote on Jun 18th, 2022:

Thanks. This really helped

Sumit from wrote on Aug 11th, 2021:

Thanks for explaining it so well. I was checking all the above locations but unable to locate where the defaults were read from.

mycoolemail@gmail.com from wrote on May 27th, 2021:

Really thank you

vidocq from wrote on Mar 25th, 2021:

Thankyou very much. I was test success on my server with multiple domain higtload.

Abhi from wrote on Mar 12th, 2021:

Thanks a lot man! it really helped

qinnan from wrote on Jul 22nd, 2020:

Thanks. This really helped

Clyde Dsouza from India wrote on Jun 9th, 2020:

Thanks. This really helped

Описание проблемы

Во процессе обслуживания высокого количества соединений (высокая нагрузка), в логе ошибок Вашего сервера могут появляться записи 24: Too Many Open Files. Происходит это потому что сервер nginx пытается открыть больше файловых дескрипторов чем ему позволено. Ограничение может быть наложено конфигурацией nginx сервера или конфигурацией операционной системы. На каждое соединение nginx открывает как минимум два дескриптора, один для соединения, второй для передаваемого файла.

Диагностика

Для выяснение причин проведем короткую диагностику. Прежде всего посмотрим конфигурационный файл nginx, обычно он расположен в

/etc/nginx/nginx.conf

Нас интерисуют следующие строки

user [xxx];
worker_processes [x];
worker_rlimit_nofile [xxx];
events {
   worker_connections [xxxx];
}

user — от имени какого пользователя nginx работает в системе, нам необходимо будет проверить лимиты для данного пользователя.
worker_processes — кол-во процессов nginx работающих при запуске демона, так как лимит операционной системы общий для всех процессов, соответственно нам надо будет устанавливать лимиты исходя из кол-ва процессов.worker_rlimit_nofile — максимальное кол-во файловых дескрипторов на один процесс.
worker_connections (может присутствовать только в контексте events) — максимальное кол-во соединений на один процесс.

Далее выясним лимиты установленные операционной системой, для этого перейдем под пользователя nginx

su nginx

Если получаем от OS сообщение вида

This account is currently not available.

Значит в файле /etc/passwd для нашего пользователя указана оболочка запрещающая вход в систему и работу с консолью, например /sbin/nologin

Отредактируем файл /etc/passwd, заменим строку

nginx:x:500:500:nginx user:/var/cache/nginx:/sbin/nologin

на строку

nginx:x:500:500:nginx user:/var/cache/nginx:/bin/bash

и вновь выполним su nginx.

Теперь посмотрим лимиты:

ulimit -Hn
ulimit -Sn

-Hn — жесткий лимит максимального кол-ва открытых файловых дискрипторов
-Sn — мягкий лимит максимального кол-ва открытых файловых дискрипторов
Отличие между жестким и мягким лимитами в том, что жесткий может быть установлен только root пользователем, а мягкий может быть установлен пользователем на которого наложен лимит, но не больше чем жесткий лимит.

Теперь мы знаем текущие ограничения OS наложенные на пользователя nginx, можно выйти из под su

exit

Посмотрим глобальное ограничение на количество дескрипторов, для этого выполним команду

sysctl fs.file-max

Итак мы значем все ограничения, теперь попробуем сделать так чтобы наш nginx получил возможность открывать столько дескрипторов, сколько ему нужно.

Решение проблемы

Посчитаем сколько нам нужно дескрипторов для nginx

(worker_connections * 4 * worker_processes) + 100 = примерно нужное кол-во дескрипторов

Соответственно для будущего расширения это значение можно умножить еще на два и задавать лимиты.

Например, (1024 * 4 * 2) + 100 = 8292

Значение не большое, можно его свободно увеличить до 25000

Устанавливаем глобальные лимиты операционной системы, в файле /etc/sysctl.conf прописываем или изменяем строку:

fs.file-max = 203463

Устанавливаем лимиты на пользователя, в файле /etc/security/limits.conf прописываем или изменяем строки:

nginx soft nofile 25000
nginx hard nofile 50000

Применяем установленные лимиты к системе

sysctl -p

Проверяем что все применилось

sysctl fs.file-max
su nginx
ulimit -Hn
ulimit -Sn
exit

Устанавливаем лимиты для nginx

worker_rlimit_nofile 12500

Перезагружаем конфигурацию nginx

nginx -s reload

Ошибка более не должна повторяться.

Возвращаем shell для nginx в файле /etc/passwd в исходное состояние

nginx:x:500:500:nginx user:/var/cache/nginx:/sbin/nologin