L'aggiunta di più core su virtualbox rende le applicazioni più lente a partire da 16 core

Question

Attualmente sto testando un'applicazione su un server con 64 core. Questo server ha installato virtualbox che può utilizzare fino a 32 core ma non di più (questo limite è dato da virtualbox). A causa del fatto che sto usando mininet per testare la mia applicazione ho bisogno dei privilegi di root per eseguirla. Non ho i diritti di root sul server ma nella VM. Quindi la mia configurazione è:

• Host ha 64 core e Ubuntu installato

• VirtualBox VM con Ubuntu dispone di 1 - 32 nuclei

• La mia applicazione è in esecuzione su 16 host mininet, ogni host è eseguire un programma che usa multicast e unicast per comunicare tra loro, ma non troppe richieste per ora. Circa 5 richieste per host dopo l'avvio. La partenza con un ritardo di 3 secondi per evitare strozzature all'inizio

• mia applicazione utilizza più thread ma ogni istanza dell'applicazione nell'host è independend degli altri

• mia applicazione utilizza l'APScheduler di pitone ed è completamente scritto in python

Ho pensato che eseguirlo con 32 core sarebbe stato il migliore. Ma quando lo faccio, tutto inizia a bloccarsi. Ottengo i timeout in APScheduler e il carico del sistema è estremamente alto.

così ho provato con ogni numero di nuclei tra 1 e 32. Qui sono alcuni esempi:

1 nucleo

4 core

8 core

12 core

16 core

20 nuclei

23 nuclei

27 nuclei

32 core

L'asse x è in mezzo secondi, l'acronimo è il carico della CPU riportato da top -b -n 1 in percentuale. Ho eseguito l'app con ciascun core count per circa 10 minuti. la linea blu è il carico medio della CPU della mia applicazione. la linea rossa è la mia applicazione, la linea verde è il carico generale del sistema.

Come si può vedere, il carico si riduce fino a circa 16 core. quando si usano più di 16 core diventa più lento e a partire da circa 23 core diventa estremamente lento. Anche quello lento che il processo che registra il carico della CPU non viene nemmeno più chiamato. Questo è il motivo per cui i grafici negli ultimi diagrammi sono più brevi ...

Qualcuno ha un'idea di quale potrebbe essere il problema? Si tratta di un bug noto di virtualbox? Questo è un problema mininet? o un problema di linux? Come posso sapere quali parti causano il carico estremo?

Se avete bisogno di maggiori informazioni, si prega di scrivere un commento e modifico la domanda.

Il carico sul sistema ospite non è mai stato superiore al 50%, quindi penso che non sia questo il problema.

È possibile che VMWare sia più veloce?

EDIT ho rivisto le trame e ha scoperto che la linea blu che descrive il carico della CPU media della mia applicazione (media su tutte le istanze su tutti gli host mininet) è anche sempre più in quando si passa 1-2 a 3 ... 16 core. Ma da 1 a 16 core il carico della cpu della mia app aumenta solo molto molto lentamente. Mentre questo aumenta il carico complessivo del sistema va giù (che ha senso, a mio parere, come Ubuntu può fare i suoi compiti su diversi core che è più veloce finché non ci sono risorse condivise).

Quindi perché il mezzo aumenta? E perché sta aumentando esponenzialmente a partire da 16 core?

Answer 1

Questo è un comportamento comune quando un programma inizia ad attraversare il limite del socket del processore. In generale, si inizierà a vedere un comportamento di temporizzazione imprevedibile quando l'applicazione inizia l'esecuzione su core che risiedono su processori fisici diversi.

Supponendo che la macchina a 64 core abbia quattro socket di processore con 16 core ciascuno e supponendo inoltre che lo scheduler sia un programmatore intelligente che tenta di mantenere raggruppati i thread di un'applicazione sullo stesso socket, l'applicazione dovrebbe visualizzare una buona velocità parallela tra 1 e 16 core, ma inizierà a funzionare male una volta che ha utilizzato più di 16 core, poiché alcuni di questi devono risiedere su un socket separato.

Questo vale sia per le macchine normali che per le macchine virtualizzate, ma una macchina virtuale è suscettibile di aggiungere un ulteriore livello di imprevedibilità se lo scheduler non è a conoscenza di questi limiti di socket.