Quanto risorse fanno di sonno e di attesa discussioni consumano

voti
19

Mi chiedo, quanto costoso è quello di avere molti thread in stato di attesa in Java 1.6 x64.

Per essere più precisi, sto scrivendo applicazioni che attraversa molti computer e invia / riceve i dati da uno all'altro. Ritengo più comodo avere thread separato per ogni macchina e attività connesse, come 1) l'invio di dati, 2) la ricezione di dati, 3) ristabilendo connessione quando viene interrotta. Quindi, dato che ci sono N nodi in cluster, ogni macchina sta per avere 3 thread per ciascuna di N-1 vicini. Tipicamente ci saranno 12 macchine, che viene a 33 thread di comunicazione.

La maggior parte di quei fili saranno dormendo la maggior parte del tempo, quindi a scopo di ottimizzazione ho potuto ridurre il numero di thread e dare più lavoro per ciascuno di essi. Come, per esempio. ristabilendo connessione è responsabilità di ricezione thread. O l'invio a tutte le macchine collegate è fatto da singolo thread.

Quindi non v'è alcun significativo impatto perfomance di avere tanti fili di sonno?

È pubblicato 19/09/2008 alle 08:24
fonte dall'utente
In altre lingue...                            


5 risposte

voti
15

Per la maggior parte dei casi, le risorse consumate da un filo di sonno sarà il suo spazio di stack. Utilizzando una connessione modello 2-threads-per-, che credo sia simile a quello che stai descrivendo, è noto per provocare grandi problemi di scalabilità per questo motivo, quando il numero di connessioni crescere di grandi dimensioni.

Sono stato in questa situazione me stesso, e quando il numero di connessioni è cresciuto al di sopra di 500 connessioni (circa un migliaio di thread), si tende ad entrare in un sacco di casi in cui si ottiene OutOfMemoryError, dal momento che i fili impilano l'utilizzo dello spazio supera l'importo massimo di memoria per un singolo processo. Almeno nel nostro caso, che era in un Java su 32 bit di Windows mondo. È possibile sintonizzare le cose e ottenere un po 'oltre, immagino, ma alla fine non è solo molto scalabile in quanto si rifiuti di un sacco di memoria.

Se avete bisogno di un gran numero di connessioni, Java NIO (nuova IO o qualsiasi altra cosa) è la strada da percorrere, rendendo possibile gestire un sacco di connessioni nello stesso thread.

Detto questo, non si deve incontrare più di un problema con sotto un 100 thread sul server abbastanza moderno, anche se è probabilmente ancora uno spreco di risorse.

Risposto il 19/09/2008 a 08:34
fonte dall'utente

voti
1

Questo non scala molto bene. Avere un gran numero di fili significa VM deve spendere più tempo context-switching, e la memoria useage sarà maggiore a causa di ogni thread richiede un proprio spazio dello stack. Si sarebbe meglio con un numero minore di trasformazione fili in modo tubazione, oppure utilizzare il pool di thread con tecniche asincrono.

Risposto il 19/09/2008 a 08:40
fonte dall'utente

voti
1

Un sacco di discussioni equivale a un sacco di spazio di stack, che mangiare la tua memoria - Check out le impostazioni -Xss per quanta, poi fare i conti.

E se mai di fare un notifyAll () per qualche ragione, poi, naturalmente, si sta svegliando i carichi di discussioni in più - anche se potrebbe non essere necessario farlo in architettura proposta.

Non sono sicuro che si può facilmente evitare di avere un thread per socket di ascolto in questo modello (anche se so molto poco su NIO - che potrebbe risolvere anche questo problema), ma date un'occhiata al java.util.concurrent.Executor dell'interfaccia e le classi di attuazione per un modo discreto per evitare di avere troppi thread aggiuntivi giro. In effetti, il ThreadPoolExecutorpotrebbe essere un buon modo per gestire i thread di ascolto anche, in modo da non spendere troppo tempo creare e distruggere le discussioni unneccessarily.

Risposto il 19/09/2008 a 09:33
fonte dall'utente

voti
2

Abbiamo avuto molto lo stesso problema prima di passare a NIO, quindi mi seconda raccomandazione Liedmans di andare con quel quadro. Si dovrebbe essere in grado di trovare un tutorial, ma se si desidera che i dettagli, posso raccomandare Java NIO da Ron Hitchens.

Swithcing al NIO aumentato il numero di connessioni che potremmo gestire un sacco, che era davvero importante per noi.

Risposto il 19/09/2008 a 09:56
fonte dall'utente

voti
0

Dalle prove che ho fatto in C, Lua e Python, è possibile creare il proprio sonno o la funzione attendere con scarsissimi linee di codici per fare un semplice ciclo leggero. Utilizzare una variabile locale con il tempo in futuro si vuole raggiungere e quindi verificare per il timestamp corrente in un ciclo while. Se ci si trova in un ambito in cui si lavora con fps, rendere la funzione di attesa eseguito una volta per fotogramma per risparmiare sulle risorse. La precisione di più è necessario, è consigliabile utilizzare l'orologio al posto del timestamp, dal momento che timestamp è limitata a pochi secondi. I più righe di codice si aggiunge in una funzione di attesa, il meno preciso diventa e più risorse che consuma, anche se nulla di meno di 10 linee dovrebbero essere abbastanza veloce.

Risposto il 29/11/2016 a 07:55
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more