Comments 13
Я-то думал, щас будет история про утечки, образующиеся по самым хитрым причинам - а нет, тут просто ulimit подняли.
Нет, знание про ulimit и правда нужное, но это ж не повод целую статью из пальца высасывать...
Оформление не вычитано - в кодофрагментах из исходника везде скопирован и элемент "rust/bash/console", который не часть кода, а указание на каком языке кодофрагмент.
К переводу, впрочем, тоже начинаются вопросы. "# This function exits the script gracefully
" -> "# Эта функция выполняет мягкое завершение скрипта
"? Учитывая, что "мягкое" в тексте вовсю используется про soft-ограничение количества дескрипторов - такой переводу путает. "Аккуратное" скорее уж. Или, из того же кодофрагмента, "беспроблемное"
ну по идее, эта функция завершилась изящным скриптом(вообще похожих слов много, но да явно слова софт не написано), там если посмотреть в переводе от слова грац, там целый вал похожих это могло быть желанием первоисточника как шуточное оповещение в консоли его возможностей написания скрипта, тоесть по сути оценка через оповещение в консоль что скрипт написан самим автором, поэтому грац на скрипте) помните когда мы достигали ачивку "вы прошли весь лор" - ура я завершил ачивку, в гильде линкуется что участник гильды получил ачивку и вся гильда обычно пишет, грац, это требует мало времени) и понятно что тебя типо поздравляют) да и потом это развернуть можно от слова конгратюлейшн)
Спасибо, исправлю. По поводу опечаток лучше писать в личку.
Как вы видите, максимальное значение достигает примерно 1600, что намного выше исходных 256.
А когда-то хватало:
dos=high
buffers=15
files=20
Ну а если выскочит ошибка, то files=30, ну хорошо, files=40 точно решит все проблемы...
sysctl kern.maxfiles
sysctl kern.maxfilesperproc
на фрибсд тоже доступны
Заметил вот...
Стоит учесть, что обычно для получения точного количества открытых дескрипторов файлов также нужно учесть всё дерево процессов, а не только основной процесс. Это вызвано тем, что дочерние процессы тоже могут открывать файлы, а их дескрипторы файлов учитываются в общем количестве. В моём случае был запущен только один процесс (cargo test), так что я этого не делал.
Это замечание показывает что автор вообще не понимает что делает. Потому что суть cargo test как раз и заключается в том, чтобы запустить кучу других процессов...
Интересно что ж у него там за тесты такие, что у него сотня процессов спавнится.
Учитывая, что лимит дескрипторов достигается в процессе cargo, а не в процессе с самими тестами - скорее всего, у него дофигаядерный процессор.
Слишком много открытых файлов