Pull to refresh

Comments 13

Я-то думал, щас будет история про утечки, образующиеся по самым хитрым причинам - а нет, тут просто ulimit подняли.

Нет, знание про ulimit и правда нужное, но это ж не повод целую статью из пальца высасывать...

Кроме ulimit тут ещё объяснено что и почему, так что вполне потянет на маленькую главу.

Больше похоже на затянутое введение.

Все же, если для простой задачи открывается одновременно 1600файлов,то что то делается не так.

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

Оформление не вычитано - в кодофрагментах из исходника везде скопирован и элемент "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, а не в процессе с самими тестами - скорее всего, у него дофигаядерный процессор.

Не сильно принципиально. Интеграционные тесты в параллель особо не позапускаешь, а в обычных юнитах форкаться обычно нужды нет. Но чтобы запускать за раз 200+ тестов за раз, нужно чтобы тех тестов был очень много.

Sign up to leave a comment.

Articles