Perché park/unpark ha un utilizzo della CPU del 60%?

Recentemente abbiamo iniziato a testare la nostra applicazione (un server di chat basato su XMPP) utilizzando YJP 11.0.9. Durante il nostro test abbiamo notato un comportamento strano.Perché park/unpark ha un utilizzo della CPU del 60%?

Il campionamento mostra sun.misc.Unsafe.unpark (Object) ha occupato il 60% della CPU.
Per la stessa applicazione Traccia mostra che LockSupport.park (Object) ha preso il 52% della CPU.

Ho eseguito più test per confermare i risultati e ogni volta ho ottenuto risultati simili.

Non riesco a capire perché unpark debba impiegare il 60% di tempo e perché la traccia mostra risultati esattamente opposti.

Qualcuno può aiutarmi a capire questi risultati. Mi sto perdendo qualcosa qui?

Ambiente:

java -version 
java version "1.6.0_31" 
Java(TM) SE Runtime Environment (build 1.6.0_31-b04) 
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

fonte

2012-10-19 Kalpesh Patel

Potrebbe richiedere molto se chiamare "unpark' è praticamente l'unica cosa che il thread fa. Cosa intendi per "tracciamento che mostra risultati esattamente opposti"? Il tracciamento forse misura il tempo trascorso all'interno di un metodo? 'park' è un metodo di blocco, quindi non ci si può meravigliare del tempo al suo interno. –

Il thread @MarkoTopolnik esegue anche altre operazioni. Fondamentalmente il suo problema produttore/consumatore. Produrre attività di produzione e inviarla nella coda e avvisare i consumatori in attesa. Il consumatore agisce sull'attività e se non ci sono attività disponibili che parcheggiare. –

Il thread che chiama 'unpark' non è il thread che non viene parcheggiato. Quel thread, a sua volta, potrebbe davvero fare solo un piccolo lavoro oltre a rimuovere i thread di consumo appropriati. Per quanto riguarda il tempo di CPU di 'park', è un) difficile da misurare a causa del blocco e b) irrilevante dal momento che sarà una frazione insignificante del tempo effettivo trascorso nello stato parcheggiato. –

Con comandi di blocco certo di basso livello di lettura/scrittura/parco/bloccare il tempo di "CPU" è finita stimata in quanto presuppone che sta consumando CPU quando in realtà l'operazione sta bloccando. Il fatto che unpark/park siano entrambi alti suggerisce che hai un problema, ma sospetto che dovresti prendere la più bassa delle due percentuali come stima.

fonte

2012-10-19 11:58:31

Il tempo di CPU elevato di Unsafe.unpark è un segno di eccessivo Cambio di contesto. Ecco un articolo per avere l'idea di come costoso è un cambio di contesto:

How long does it take to make a context switch?

L'opzione più semplice per scoprire conteggio CS su Linux viene eseguito vmstat <seconds>.

Una volta confermato il valore CS elevato (ad esempio più interruttori 10K per core/per secondo) si prende il thread offendente (è possibile ordinare i thread in YJP in base al tempo CPU) ed eseguire strace -p <pid> -c per individuare la causa della commutazione, ad es. thread sta leggendo dal socket in piccoli pezzi e viene disattivato, nel qual caso potrebbe essere utile aumentare il buffer del socket.

fonte

2015-04-02 13:47:13

Perché park/unpark ha un utilizzo della CPU del 60%?

risposta

Problemi correlati