Impostazione dimensione ideale del pool di thread

Question

Qual è la differenza tra-

newSingleThreadExecutor vs newFixedThreadPool(20)

in termini di sistema operativo e il punto di vista della programmazione.

Ogni volta che eseguo il mio programma utilizzando newSingleThreadExecutor il mio programma funziona molto bene e la latenza end-to-end (95 ° percentile) arriva intorno a 5ms.

Ma appena comincio correre il mio programma using-

newFixedThreadPool(20)

miei programmi degrada le prestazioni e mi metto a vedere un capo all'altro la latenza come 37ms.

Quindi ora sto cercando di capire dal punto di vista dell'architettura cosa significa qui il numero di thread? E come decidere qual è il numero ottimale di discussioni che dovrei scegliere?

E se sto usando più numero di thread, allora cosa succederà?

Se qualcuno mi può spiegare queste semplici cose in un linguaggio laico, questo mi sarà molto utile. Grazie per l'aiuto.

mio config macchina spettrofotometria sto facendo funzionare il mio programma da Linux Machine

processor  : 0 
vendor_id  : GenuineIntel 
cpu family  : 6 
model   : 45 
model name  : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz 
stepping  : 7 
cpu MHz   : 2599.999 
cache size  : 20480 KB 
fpu    : yes 
fpu_exception : yes 
cpuid level  : 13 
wp    : yes 
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm arat pln pts 
bogomips  : 5199.99 
clflush size : 64 
cache_alignment : 64 
address sizes : 40 bits physical, 48 bits virtual 
power management: 

processor  : 1 
vendor_id  : GenuineIntel 
cpu family  : 6 
model   : 45 
model name  : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz 
stepping  : 7 
cpu MHz   : 2599.999 
cache size  : 20480 KB 
fpu    : yes 
fpu_exception : yes 
cpuid level  : 13 
wp    : yes 
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm arat pln pts 
bogomips  : 5199.99 
clflush size : 64 
cache_alignment : 64 
address sizes : 40 bits physical, 48 bits virtual 
power management: 

Answer 1

Ok. Idealmente supponendo che i thread non abbiano un blocco tale da non bloccarsi l'un l'altro (indipendentemente l'uno dall'altro) e si può presumere che il carico di lavoro (elaborazione) sia lo stesso, si scopre che hanno una dimensione di pool di Runtime.getRuntime().availableProcessors() o availableProcessors() + 1 dà i migliori risultati.

Ma diciamo, se i fili interferiscono tra loro o l'I/O è coinvolto, allora la legge di Amadhal spiega piuttosto bene. Da wiki,

legge di Amdahl afferma che se P è la proporzione di un programma che può essere fatto in parallelo (cioè beneficiare parallelizzazione), e (1 - P) è la percentuale che non può essere parallelized (rimane seriale), quindi l'aumento di velocità massima che può essere ottenuta utilizzando N processori è

Nel suo caso, in base al numero di core disponibili, e quale lavoro precisamente do (calcolo puro? I/O? Tenere blocchi? Bloccato per qualche risorsa? Ecc.), È necessario venire con la soluzione basata sopra i parametri sopra.

Ad esempio: alcuni mesi fa ero coinvolto nella raccolta di dati da siti Web numerici. La mia macchina era a 4 core e avevo una dimensione di piscina di 4. Ma poiché l'operazione era puramente I/O e la mia velocità di rete era decente, mi sono reso conto che avevo le migliori prestazioni con una dimensione di piscina di 7. E questo perché i thread non combattevano per il potere computazionale, ma per I/O. Quindi ho potuto sfruttare il fatto che più thread possono contestare positivamente il core.

PS: Suggerisco, passando attraverso il capitolo Performance dal libro - Java Concurrency in Practice di Brian Goetz. Si occupa di tali argomenti in dettaglio.

Answer 2

Quindi ora sto cercando di capire dal punto di vista dell'architettura cosa significa qui il numero di thread?

Ogni thread ha una propria memoria di stack, un contatore di programma (come un puntatore a quale istruzione viene eseguita successivamente) e altre risorse locali. Scambiarli fa male la latenza per una singola attività. Il vantaggio è che mentre un thread è inattivo (di solito quando si attende I/o), un altro thread può funzionare. Inoltre, se sono disponibili più processori, possono essere eseguiti in parallelo se non vi sono conflitti di risorse e/o di blocco tra le attività.

E come decidere qual è il numero ottimale di thread che dovrei scegliere?

Il trade-off tra di swap-prezzo contro la possibilità di evitare il tempo di inattività dipende dai piccoli dettagli di quello che il vostro compito sembra (quanto i/o, e quando, con la quantità di lavoro tra i/o , utilizzando quanta memoria per completare). La sperimentazione è sempre la chiave.

E se sto usando più numero di thread, allora cosa succederà?

Di solito ci sarà una crescita lineare della velocità effettiva, quindi una relativa parte piatta, quindi una caduta (che può essere piuttosto ripida). Ogni sistema è diverso.

Answer 3

Guardare la legge di Amdahl va bene, soprattutto se si sa esattamente quanto P e N sono grandi. Dal momento che ciò non accadrà mai, è possibile monitorare le prestazioni (cosa che si dovrebbe fare comunque) e aumentare/ridurre la dimensione del pool di thread per ottimizzare le metriche relative al rendimento che sono importanti per l'utente.