Os x terminal, ssh e troppi file aperti

Question

Ciao ragazzi: ho un po 'di codice che esegue diverse interrogazioni su una connessione che viene inoltrata a una macchina AWS (fyi: queste query stanno colpendo un server Solr in esecuzione su questo macchina) e le query vengono eseguite contro il mio localhost (che viene inoltrato all'istanza AWS).

Il codice inizialmente funziona alla grande ottenendo i dati necessari, ma dopo aver eseguito per un po ', il codice si blocca (in eclissi).

In questo momento esatto, il terminale (cioè dove ho iniziato il mio tunnel ssh) va completamente congelato, riempiendo con la stringa:

"accettare: troppi file aperti"

Perché questa stampa infinita non è associata ad un terminale bash (cioè non posso dire se la connessione ssh è ancora viva o no, e non c'è un testo che indichi quale im in di shell ... solo dichiarazioni di stampa spregiudicate, inesorabili) Non posso dire sia che provenga da Amazon, o dal mio terminale client.

voglio trovare la causa di questo comportamento e individuare la macchina che sta causando mio terminale ad esplodere

Per testare quale delle due macchine stava causando le stampe infinite dell'errore, ho eseguito il comando ulimit sul server ... e trovato che il numero massimo di file aperti consentiti (sul server aws) era ben al di sopra della quantità di file aperti (determinata anche usando ulimit) in qualsiasi momento mentre il programma client (in esecuzione da il mio ide) è in esecuzione.

Ho eseguito lo stesso test sul mio client e non ho riscontrato alcun aumento significativo del numero di file aperti.

Alcuni dettagli laterali: eseguo diverse centinaia di query in un server SOLR con oltre 100 GB di dati in un breve periodo di tempo.

Qualsiasi suggerimento su come determinare perché il mio terminale sshd mac os x sta morendo e la stampa infinita di questo messaggio potrebbe essere potenzialmente molto utile per me. Ovviamente, se fossero o meno specifici per SOLR. Detto questo, eventuali approfondimenti sul perché ciò accadrebbe quando si utilizza un servizio solr può anche aiutare per risolvere questo problema.

Answer 1

Non c'è abbastanza informazioni qui per essere certi, ma suona come ssh sta colpendo il suo limite descrittore di file per processo durante il tentativo di accettare connessioni alla presa inoltrato a livello locale, che a sua volta suggerisce che già connessioni aperte non sono essere chiuso in modo tempestivo. È possibile eseguire ssh con -d per visualizzare i dettagli di connessioni e disconnessioni; potresti voler catturare il suo stderr e usare uno script per tracciare le operazioni del socket in quanto saranno sepolti in molte altre informazioni di debug.

Nota che lo stesso ssh potrebbe limitare i descrittori di file aperti oltre il valore predefinito per evitare attacchi di tipo denial of service sulla sua porta inoltrata; Non vedo alcuna indicazione di ciò nella documentazione, ma è il tipo di cosa che mi aspetterei.

Answer 2

Si potrebbe provare a guardare ulimit (tramite tipo Terminal):

ulimit -a 

In particolare, controllare il valore per open files. Sulla mia macchina (OS X) riporta 256.Si potrebbe desiderare di provare ad aumentare a 512:

ulimit -n 512 

Answer 3

Questo sembra aver funzionato per me:

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 

quindi riavviare OS X.

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

Answer 4

sudo launchctl limit maxfiles 1000000 unlimited 

o

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

Per rendere permanente la modifica, l'uso di sudo per mettere le impostazioni in /etc/sysctl.conf (che potrebbe essere necessario creare), in questo modo:

kern.maxfiles=20480 
kern.maxfilesperproc=18000 

Nota - selezionare il numero a vostra proprio rischio