LINUX.ORG.RU
ФорумAdmin

В чем смысл дефолтного ограничения на количество открытых дескрипторов (ulimit -n = 1024) в современных дистрибутивах?

 


0

2

SUBJ. Мне приходят в голову следующие варианты:

  • экономия ресурсов
  • исторически сложилось
  • ориентацию дистрибутивов на работу даже на «кофемолке», т.е., компе с ограниченным количеством ресурсов (например, Debian)
  • защита от локального DoS
  • может и не быть epoll, а быть poll (который деградирует при большом количестве дескрипторов), или select с его максимумом в 1024

А какие ваши варианты? Почему разработчики не убрали лимиты (или хотя бы не повысили на порядок) в современных релизах?

★★★★★

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

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

yoghurt ★★★★★
()

дык это число процессов, т.е. число форков. Если bash скрипт форкнулся 1024 раза, то это баг.

emulek
()
Ответ на: комментарий от yoghurt

Как вычислить её размер в байтах?

Разве таблица не динамическая? Т.е., если лимит будет в 100k - разве выделится на каждый процесс таблица дескрипторов на 100k, даже если она будет пустая?

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

а что, есть неадекваты кторые тыщи сокетов в одном процессе отрабатывают на ненастроенной под эту специфическую нужду системе????

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

Есть админы, которые ругают предустановленные лимиты, считая это архаизмом. Я лишь пытаюсь найти причину лимитов.

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

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Chaser_Andrey

а... Ты про -n? Это да, число файлов.

-n the maximum number of open file descriptors

которые может открыть bash-скрипт или программа запущенная из bash'а.

И что тут странного? Если твоя программа открыла больше 1024х файлов, то это баг. Если это не баг, а фича, то пусть твоя программа сделает ulimit(3), и поставит Over9000.

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

которые может открыть bash-скрипт или программа запущенная из bash'а.

Не неси ерунду. Какой нахрен баш? Это более низкоуровнёвые штуки. bash может вообще отсутствовать, а быть один init, который сделает exec бинарнику.

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

Не неси ерунду. Какой нахрен баш?

совсем думать разучился, только на лоре флудить?

был назван man 3 ulimit, чего же боле? Баш для примера приведен, да и то, как видно, не помогло

Deleted
()
Ответ на: комментарий от Chaser_Andrey

Не неси ерунду. Какой нахрен баш? Это более низкоуровнёвые штуки. bash может вообще отсутствовать, а быть один init, который сделает exec бинарнику.

ты наверное спрашивал про:

RLIMIT_NOFILE Specifies a value one greater than the maximum file descriptor number that can be opened by this process. Attempts (open(2), pipe(2), dup(2), etc.) to exceed this limit yield the error EMFILE. (Historically, this limit was named RLIMIT_OFILE on BSD.)

да?

Ну мой ответ в силе. Да, цитата из setrlimit(3).

emulek
()
Ответ на: комментарий от Deleted

Баш для примера приведен

ulimit -n это команда bash'а. Встроенная. Она в сабже. Я не знаю, зачем её туда засунул ТС.

emulek
()
Ответ на: комментарий от Deleted

ulimit(3) уже deprecated

Кроме того, это не позволит прыгнуть выше hard limit

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

Батек опять пуржит, впрочем неудивительно. ulimit, как команда, определяется посиксом, баш тут не при чем совершенно.

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

баш тут не при чем совершенно.

не баш, а sh. В случае ТСа — bash очевидно.

ulimit(3) уже deprecated

да? А пруфлинк?

Кроме того, это не позволит прыгнуть выше hard limit

see also видел, да?

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

Отвечай тому, кто писал, а не анонимусу)

да? А пруфлинк?

POSIX.1-2008 marks ulimit() as obsolete.

see also видел, да?

Что я там должен увидеть, что может позволить превысить hard limit?

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

POSIX.1-2008 marks ulimit() as obsolete.

ладно, уговорил.

Что я там должен увидеть, что может позволить превысить hard limit?

там даже пример есть:

The program below demonstrates the use of prlimit()

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

Там же

Жёсткое ограничение работает как максимальное значение для мягкого ограничения: непривилегированные процессы могут определять только свои мягкие ограничения в диапазоне от 0 до жёсткого ограничения, то есть однозначно меньше жёсткого ограничения. Привилегированные процессы (в Linux: имеющие мандат CAP_SYS_RESOURCE) могут устанавливать произвольные значения в любых пределах.

Chaser_Andrey ★★★★★
() автор топика

а нахрена процессу 1К дескрипторов? ты с какой-то проблемой столкнулся или теоретизируешь?

moot ★★★★
()

А фиг их знает! Могли бы 64-битным числом ограничить. А то ведь проблем с этим — не оберешься! Проверяй каждый раз, что там за ulimit выставлен...

Идиотизм!

Eddy_Em ☆☆☆☆☆
()

Приведу пример, где мне нужно было иметь 16 миллионов открытых одновременно файлов: для отработки одной интересной задумки. Оперативы мало, поэтому хранить данные я решил в файлах, а потом уже обрабатывать их. Но получилось через жопу: 16 миллионов файлов одновременно открыть мне ulimit не дал (и я не сильно тогда парился с настройками, то ли вообще нельзя было лимиты выставить по-человечески), поэтому пришлось постоянно открывать/закрывать файлы. Ну и обработчик вынужден был открывать/закрывать. В общем, две недели у меня оно считалось. Но таки метод годным оказался. Надо лишь придумать, как его ускорить без необходимости заведения терабайт оперативки.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от emulek

Стало быть, обычный непривилегированый процесс (запущенный не от рута и без мандата CAP_SYS_RESOURCE) выше hard limit не подскочит.

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

Лично я сталкивался только пару раз, когда брутфорсеру не хватало открытых сокетов для соединений через прокси. Но тогда у меня с этим проблем не было, повысил ulimit и всё.

Сейчас просто теоризирую.

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

Но получилось через жопу: 16 миллионов файлов одновременно открыть мне ulimit не дал

а man 3 ulimit ты прочитать конечно не догадался?

emulek
()
Ответ на: комментарий от Chaser_Andrey

Стало быть, обычный непривилегированый процесс (запущенный не от рута и без мандата CAP_SYS_RESOURCE) выше hard limit не подскочит.

ну. И что дальше-то? Ты этого не знал? Ну круто — теперь знаешь.

У тебя как у Эдди проблема с открытием 16М файлов сразу что-ли? Ну бывает, но редко. В 95% случаев хватает 1023х, а если больше, то это баг. Потому-то такой дефолт. Что-бы можно было-бы быстро и просто найти говнокод, который файлов открывает Over9000.

emulek
()
Ответ на: комментарий от Eddy_Em

Это здесь каким боком? man 3 sysconf здесь нужен, установить OPEN_MAX в 16 миллионов. Только не установится же!

блжад, Эдди, иди проспись.

emulek
()
Ответ на: комментарий от Eddy_Em

Ну я и дебил!

sysctl -w fs.file-max=18000000
fs.file-max = 18000000
Eddy_Em ☆☆☆☆☆
()

Выявлять говнокодеров как можно раньше

anonymous
()

select с его максимумом в 1024

В 64-битном Солярисе - 65536, бг-бг-бг.

anonymous
()
Ответ на: комментарий от Eddy_Em

man 3 sysconf здесь нужен, установить OPEN_MAX в 16 миллионов

Если бог хочет наказать, он отнимает разум.

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