In che modo l'applicazione Web supporta 150 thread max quando la cpu supporta solo 2? [duplicare]

-5

facendo un lscpu cmd questo è quello che ottengo

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
Stepping:              0
CPU MHz:               2494.224
BogoMIPS:              4988.44
Hypervisor vendor:     VMware
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,1

facendo la matematica mi dice che dovrebbe essere in grado di eseguire 2 thread in un dato momento

Thread (s) per core: 1 Core (s) per socket: 1 Presa / e: 2

tuttavia la configurazione di tomcat imposta i thread massimi a 150

redirectPort="8443" maxThreads="150" acceptCount="15" enableLookups="true"

in che modo l'applicazione Web supporta 150 thread max quando la cpu supporta solo 2?

    
posta rtd353 16.01.2017 - 21:59
fonte

2 risposte

2

Ci sono due tipi di thread. Esecuzione di thread e thread non in esecuzione, ovvero thread sospesi.

I thread sospesi (non in esecuzione) sono semplicemente strutture di dati. Sì, queste strutture dati hanno necessariamente dei puntatori al codice, ma sono ancora molto strutture di dati in tutti i sensi.

I thread sospesi possono essere ripresi e in seguito nuovamente sospesi. Tuttavia, i thread sospesi sono solo stati (strutture dati). Quindi, in definitiva, il computer è limitato nei thread sospesi solo per la sua capacità di memorizzare lo stato, lo stato viene memorizzato in memoria, quindi i thread sospesi sono limitati solo dalla capacità di memoria (quirk / limitazioni del design del sistema operativo modulo). p>

L'esecuzione di thread, al contrario, richiede l'hardware di supporto. Non possiamo avere più thread in esecuzione di quanto non abbiano capacità hardware.

Tuttavia, sotto la supervisione di un sistema operativo (scheduler dei thread), un thread in esecuzione può essere sospeso e quindi viene ripreso un thread sospeso diverso, il che fa sembrare che ci siano molti più thread "in esecuzione" rispetto a hardware con transistor per .

    
risposta data 17.01.2017 - 06:31
fonte
0

Un server Web come Tomcat è una cosa fantastica da infilare perché la maggior parte delle volte i thread non stanno facendo nulla - sono, per esempio, bloccati in attesa di una richiesta dalla rete. Sì, un singolo core CPU può eseguire solo un singolo thread in un dato istante. Ma può anche scambiare quel thread e passare a uno nuovo molto rapidamente.

Tomcat può far girare molti thread anche su una CPU single core. Il vantaggio è che, dal punto di vista dell'architettura del codice, il codice è molto più semplice da gestire rispetto al fatto che un singolo thread controlla costantemente se c'è un I / O da fare o qualcosa del genere.

Un processo associato alla CPU, in cui ogni thread utilizza un po 'di tempo di elaborazione non è adatto a questo modello. In questo caso, la CPU trionfa cercando di elaborare e scambiare i contesti rapidamente e il codice verrebbe probabilmente eseguito più lentamente di se si eseguisse l'attività in sequenza.

Poiché la JVM si interfaccia con il livello O / S, possono esserci anche diversi modelli di threading. Il JDK aveva il supporto per "thread verdi" (vedi alcuni documenti molto vecchi per maggiori informazioni). Nel modello "thread verde", più thread Java venivano mappati su un singolo thread nativo. Ma scrivere codice Java con più thread aveva ancora senso per qualcosa come un server web a causa del cambio di attività.

    
risposta data 16.01.2017 - 22:47
fonte

Leggi altre domande sui tag