Os x терминал, ssh и слишком много открытых файлов

Привет, ребята: у меня есть некоторый код, который выполняет несколько запросов rest по соединению, которое ssh пересылается на машину AWS (к вашему сведению: эти запросы попадают на сервер Solr, работающий на этой машине), и запросы выполняются на моем локальном хосте (который пересылается к экземпляру AWS).

Первоначально код работает отлично, получая данные по мере необходимости, но после некоторого времени выполнения код останавливается (в eclipse).

At this exact moment, the terminal (i.e. where I have started my ssh tunnel) goes completely frozen, filling up with the String :

& quot; принять: слишком много открытых файлов & quot;

Поскольку эта бесконечная печать не связана с терминалом bash (т. Е. Я не могу сказать, является ли ssh-соединение живым или нет, и нет текста, указывающего, в какой оболочке я ... просто нефиксированные, неустанные операторы печати), я не могу Скажите, идет ли он от Amazon или от моего клиентского терминала.

I want to find the cause of this behavior and pinpoint the machine which is causing my terminal to explode

Чтобы проверить, какая из двух машин вызывала бесконечные распечатки ошибки, я запустил команду ulimit на сервере ... и нашелthat the max number of open files allowed (on the aws server) was well above the amount of open files (also determined using ulimit) at any given time while the client program (running from my ide) выполняется.

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

Некоторые дополнительные детали: я выполняю несколько сотен запросов на сервере SOLR, который имеет более 100 ГБ данных за короткий промежуток времени.

Любые намекиon how to determine why my sshd mac os x terminal is dying and infinitely printing this message было бы потенциально очень полезно для меня. Конечно, были ли они специфичны для Solr. Это сказало,any insights into why this would happen when using a solr service may also help Для решения этой проблемы.

Ответы на вопрос(5)

Вы можете попробовать посмотреть наulimit (через тип терминала):

ulimit -a

В частности, проверьте значение дляopen files, На моей машине (OS X) он сообщает 256. Вы можете попробовать увеличить его до 512:

ulimit -n 512
 08 апр. 2013 г., 12:42
Это не сработало для меня.
 04 авг. 2015 г., 23:56
Я должен был сделать это для каждого экземпляра bash, на котором выполнялись программы, для которых требовалось больше файлов.
 11 апр. 2012 г., 01:11
Возможно, вам придется сделать это для пользователя, под которым работает SOLR, например, как кот.

echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf
echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf
echo 'ulimit -n 4096' | sudo tee -a /etc/profile

Затем перезапустите OS X.

https://superuser.com/questions/302754/increase-the-maximum-number-of-open-file-descriptors-in-snow-leopard

Следующая команда помогла мне,

launchctl limit maxfiles
sudo launchctl limit maxfiles 1000000 unlimited

или же

sudo sysctl -w kern.maxfilesperproc=1000000
sudo sysctl -w kern.maxfilesperproc=18000

Чтобы сделать изменение постоянным, используйте sudo, чтобы поместить ваши настройки в /etc/sysctl.conf (который вам, возможно, придется создать), например так:

kern.maxfiles=20480 
kern.maxfilesperproc=18000

Note - select the number at your own risk

Здесь недостаточно информации, чтобы быть уверенным, но это звучит какssh достигает предела дескриптора файла для каждого процесса при попытке локально принимать подключения к перенаправленному сокету, что, в свою очередь, говорит о том, что уже открытые подключения не закрываются своевременно. Вы можете запуститьssh с-d видеть детали подключений и отключений; Вы можете захотеть перехватить его stderr и использовать скрипт для отслеживания операций с сокетами, поскольку они будут скрыты во многих других отладочных данных.

Обратите внимание, чтоssh сам может ограничить свои дескрипторы открытых файлов за пределы по умолчанию, чтобы избежать атак отказа в обслуживании на свой перенаправленный порт; Я не вижу никаких указаний на это в документации, но это именно то, чего я ожидал бы.

Ваш ответ на вопрос