LINUX.ORG.RU
решено ФорумAdmin

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


0

2

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

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

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

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

$ ulimit -n
1024

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

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

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

$ cat /proc/sys/fs/file-max
594904

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

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

UPD:

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

$ cat /proc/sys/fs/file-max
общесистемное ограничение.

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



Последнее исправление: Munhgauzen (всего исправлений: 3)

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

anonymous
()

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

Artificial_Thought ★★★★
()
Ответ на: комментарий от Artificial_Thought

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

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

Munhgauzen
() автор топика
Ответ на: комментарий от Munhgauzen

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

Artificial_Thought ★★★★
()
Ответ на: комментарий от Artificial_Thought

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

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

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

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

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

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

Munhgauzen
() автор топика
Ответ на: комментарий от Munhgauzen

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

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

Komintern ★★★★★
()

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

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

AS ★★★★★
()
Ответ на: комментарий от Komintern

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

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

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

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

Munhgauzen
() автор топика
Ответ на: комментарий от Munhgauzen

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

AS ★★★★★
()
Ответ на: комментарий от Munhgauzen

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

может монго?

Komintern ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.