Linux максимальное количество открытых файлов

Лимиты на число одновременно открытых дескрипторов файлов

Приветствую уважаемых экспертов!

Задался вопросом, а сколько Linux (с ядром 3.2) может позволить мне держать открытыми файлов? Например, если я много дергаю текстовых файлов на чтение в PHP-скриптах.

Ограничения есть, но вот какие? И как их посмотреть, или даже поменять? Эти ограничения откносятся к одной ФС или действуют на систему в целом?

Например дома на Ubuntu:

Про ключ -n написано:

The maximum number of open file descriptors (most systems do not allow this value to be set)

А тут (эта же система):

Что это за показатели? И к чему они относятся?

Или может есть другие способы посмотреть?

Насколько я понял, ulimit показывает максимальное число открытых дескрипторов файлов на процесс, а

Допустим есть Apache + PHP (модулем). При обслуживании web-сайта какое ограничение будет действовать? В PHP-скриптах идет обращение к БД «на файлах». Неужели 1024 дескрипторов на весь Apache?

первое — лимит, устанавливаемый шеллом с пом. pam
второе — устанавливаемый ядром
ответы на твои вопросы есть, внезапно, в релевантных манах/доках

Дополнил вопрос в теме.

Файлы надо закрывать сразу после обращения в таком случае. Собственно для того всякие блоки типа with-open-file в общелиспе и придуманы. Ну или with . as . в питоне.

В коде вижу обращения к функции file_get_contents(). Они вычитывают из мелких файликов (в пределах килобайта) хранимые объекты. В процессе открытия одной страницы читается до 30 файлов (чаще до 10). Сам сайт дает около полумиллиона генераций страниц в сутки. Правда пока пиковые нагрузки никто не считал.

Так чтобы открыть fopen(), а потом что-то с ним долго делать пока не обнаружил.

Вообще именно чтобы с таким вот не геммороится, и придумали базы данных. И да, а нафига при открытии каждой страницы оно перечитывает, нельзя что ли кеш держать в памяти веб-приложения? Или php каждый раз заново перезапускается?

Вообще именно чтобы с таким вот не геммороится, и придумали базы данных.

БД вещь хорошая, но сайтов на маломощном сервачке несколько. И там где в основе БД, прослеживаются тормоза (звучит страшнее чем на самом деле). Вызывают нарекания всякие вложенности, джойны и прочие вкусности.

И да, а нафига при открытии каждой страницы оно перечитывает, нельзя что ли кеш держать в памяти веб-приложения?

Файлов много, и количество обращений (пофайловых) более-менее равномерно. Вот если бы какие-то чаще других читались. Да и памяти всего 600 Мб.

Или php каждый раз заново перезапускается?

Да. Приложения работающего постоянно нет.

там где в основе БД, прослеживаются тормоза

так ты фактически и реализуешь ту же БД, только с файлами и костылями. и при достижении того же уровня функционала тормоза будут те же.

Неужели 1024 дескрипторов на весь Apache?

Да. Но на каждый весь: ps ax|grep httpd

так ты фактически и реализуешь ту же БД

Согласен. Файлы и РБД не должны сильно отличаться по скоростям (мне так кажется). При условии проектирования структуры таблиц в РБД не по академическим правилам, а в привязке к предметной области и специфике их отображения.

А то обычно во всяких (да в любых) CMS генерация главной страницы характерна выполнением нескольких десятков SQL-запросов. И не все они простые линейные SELECT`ы.

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

Да. Но на каждый весь: ps ax|grep httpd

Вот это уже радует.

man, в этом месте, не очень вразумительный. Не сразу понятно, точнее, вообще непонятно. Но оно так.

При условии проектирования структуры таблиц в РБД не по академическим правилам, а в привязке к предметной области и специфике их отображения.

Источник

Максимально допустимо число открытых файлов в Linux?

Добрый день, Столкнулся с проблемой используя программы на Java. Которая во время используя открывает массу файлов.

Если увеличить лимит до 900000, то запускается. Может быть такое количество? почему такой лимит маленький по-умолчанию? 1024 или 2048. lsof|grep -i /opt/storage|wc -l 511231

Для пользователя, от которого запускается программа выставлен лимит на открытых файловых дескрипторов

почему такой лимит маленький по-умолчанию?

Потому что так решил создатель дистрибутива.

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

почему не соответствие в файлах и коменде?

почему не соответствие в файлах и коменде?

[root@apm-dgt-ms apm]# su — user Last login: Tue May 16 09:11:02 EEST 2017 on pts/1

-bash-4.2$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 514837 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 2048 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

#* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student — maxlogins 4 * — nofile 2048 user hard nofile 900000 # End of file

Источник

Исправляем ошибку “Too many open files“ в Linux

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

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

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

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

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

Ограничение на количество открытых файлов для текущего пользователя – 1024. Можно проверить так:

Есть два типа ограничений: Hard и Soft. Пользователь может изменить лимит для soft ограничения (но значение soft не может превышать hard). Hard ограничение можно изменить только от привилегированного пользователя.

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

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

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

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

Ели вы используете Ubuntu, нужно прописать строку:

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

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

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

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

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

# systemctl daemon-reload
# systemctl restart httpd.service

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

# systemctl status httpd.service

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы изменить общее значение в системе /proc/sys/fs/file-max, измените значение fs.file-max в /etc/sysctl.conf:

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

Источник

linux-notes.org

Несколько раз я сталкивался с ошибкой «Too many open files»(Слишком много открытых файлов) на сервере с высокой нагрузкой. Это означает, что сервер исчерпывает ресурс на максимальный предел открытых файлов (max open file limit). Теперь вопрос в том, как я могу увеличить лимиты открытых файлов на Linux? Да все очень просто, в своей статье «Увеличить Max Open File Limit в Unix/Linux» покажу как это выполняется.

Увеличить Max Open File Limit в Unix/Linux

Приведу команды на различные Unix/Linux ОС

Увеличить Max Open File Limit в Linux

Для начала проверим какой предел установлен в ОС:

Увеличиваем данный предел в Linux

Мы можем увеличить лимиты для открытых файлов:

-===ВРЕМЕННО===-

Если есть необходимость увеличить лимит временно (для тестирования, например), то можно это сделать так:

Вот еще один пример:

-===ПОСТОЯННО===-

Если есть необходимость увеличить лимит навсегда, то можно это сделать так:

Эти настройки будут сохраняться даже после перезагрузки системы. После добавления конфигурации в файл, выполните следующую команду, чтобы изменения вступили в силу:

Настройка лимитов для каждого пользователя

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

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

Подключаемся от пользователя (у меня это nginx):

Проверяем параметры Hard лимитов :

В консоле, можно ввести данную команду (очень удобно отображает):

Проверяем параметры лимитов Soft :

Увеличить Max Open File Limit в Mac OS X

Выполним проверку лимитов с помощью:

• Первый аргумент — soft limit.
• Второй аргумент — hard limit.

Можно прописать в файл:

Увеличюем nginx worker_rlimit_nofile в nginx ( на уровне Nginx)

В nginx также можно увеличить лимиты с директивой worker_rlimit_nofile, которая позволяет увеличить этот лимит, если это не хватает данного ресурса на лету на уровне процесса:

И прописываем (редактируем):

После чего, проверяем конфигурацию nginx и перезапускаем его:
Save and close the file. Reload nginx web server, enter:

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

ulimit в Kali Linux

Включение ограничений на основе PAM в Unix/Lixux

Для Debian/Ubuntu

Редактируем файл (Debian/Ubuntu):

Открываем еще один файл:

И, приводим к виду:

И выполняем рестарт:

Для CentOS/RedHat/Fedora

Редактируем файл (Debian/Ubuntu):

Открываем еще один файл:

И, приводим к виду:

И выполняем рестарт:

У меня все! Статья «Увеличить Max Open File Limit в Unix/Linux», завершено.

3 thoughts on “ Увеличить Max Open File Limit в Unix/Linux ”

в kali linux не работает смена хард и софт лимитов. всё равно пишет 4096 и 1024 соответственно.

Можно! Что-то делаете не так. Я выложил скриншот в статье и показал что можно все сделать.

Мужикам на картинке к статье явно не повезло.

Свет приглушён, явно видно зелёный оттенок табличек аварийного освещения — либо дело за полночь, либо у них блекаут и работают от дизеля.

Сидят за консолью. По сети, оно, похоже, уже не отвечает. Плохо дело.

Стул притащили. Значит, давно не отвечает. Надо было прописать MAX OPEN FILE LIMIT заранее, а не когда уже навернулось.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник