La velocità con cui il mio server può accettare () nuove connessioni TCP in entrata è davvero pessima in Xen. Lo stesso test su hardware bare metal mostra velocità 3-5x.

1. Come mai questo è così male sotto Xen?
2. Puoi modificare Xen per migliorare le prestazioni per le nuove connessioni TCP?
3. Esistono altre piattaforme di virtualizzazione più adatte a questo tipo di casi d'uso?

sfondo

Ultimamente ho cercato alcuni colli di bottiglia delle prestazioni di un server Java sviluppato internamente in esecuzione su Xen. Il server parla HTTP e risponde alle semplici chiamate TCP connect / request / response / disconnect.

Ma anche durante l'invio di carichi di traffico al server, non può accettare più di ~ 7000 connessioni TCP al secondo (su un'istanza EC2 a 8 core, c1.xlarge che esegue Xen). Durante il test, il server presenta anche uno strano comportamento in cui un core (non necessariamente CPU 0) viene caricato molto> 80%, mentre gli altri core rimangono quasi inattivi. Questo mi porta a pensare che il problema sia legato al kernel / alla virtualizzazione sottostante.

Quando collaudo lo stesso scenario su una piattaforma bare metal non virtualizzata, ottengo risultati del test che mostrano velocità TCP () accettate oltre i 35000 / secondo. Questo su una macchina Core i5 4 core che esegue Ubuntu con tutti i core quasi completamente saturi. Per me quel tipo di figura sembra giusto.

Di nuovo sull'istanza Xen, ho provato ad abilitare / modificare quasi tutte le impostazioni presenti in sysctl.conf. Compreso l'attivazione del comando Ricevi pacchetto di pacchetti e Ricevi flusso di direzione e appuntamenti di thread / processi alle CPU ma senza evidenti guadagni.

So che ci si aspetta prestazioni degradate quando si esegue la virtualizzazione. Ma fino a questo punto? Un server bare metal più lento e performante. 8 core di un fattore 5?

1. Questo comportamento è davvero atteso da Xen?
2. Puoi modificare Xen per migliorare le prestazioni per le nuove connessioni TCP?
3. Esistono altre piattaforme di virtualizzazione più adatte a questo tipo di casi d'uso?

Riproduzione di questo comportamento

Analizzando ulteriormente questo aspetto e individuando il problema, ho scoperto che lo strumento di test delle prestazioni di netperf potrebbe simulare lo scenario simile che sto vivendo. Usando il test TCP_CRR di netperf ho raccolto vari report da diversi server (sia virtualizzati che non virt.). Se desideri contribuire con alcuni risultati o consultare i miei rapporti attuali, consulta https://gist.github.com/985475

Come faccio a sapere che questo problema non è dovuto a software scritto male?

1. Il server è stato testato su hardware bare metal e quasi satura tutti i core disponibili.
2. Quando si utilizzano connessioni TCP keep-alive, il problema scompare.

Perché questo è importante?

In ESN (il mio datore di lavoro) sono il capo del progetto di Beaconpush , un server Comet / Web Socket scritto in Java. Anche se è molto performante e può saturare quasi tutta la larghezza di banda assegnata in condizioni ottimali, è ancora limitato alla velocità con cui è possibile effettuare nuove connessioni TCP. Cioè, se hai un grande abbandono di utenti in cui gli utenti vanno e vengono molto spesso, molte connessioni TCP dovranno essere configurate / abbattute. Cerchiamo di mitigare questo mantenendo le connessioni in vita il più a lungo possibile. Ma alla fine, la prestazione accept () è ciò che impedisce ai nostri core di girare e non ci piace.

Aggiornamento 1

Qualcuno ha pubblicato questa domanda su Hacker News , ci sono anche alcune domande / risposte. Ma proverò ad aggiornare questa domanda con le informazioni che trovo mentre procedo.

Hardware / piattaforme Ho provato questo su:

• EC2 con tipi di istanza c1.xlarge (8 core, 7 GB RAM) e cc1.4xlarge (2x Intel Xeon X5570, 23 GB RAM). Le AMI utilizzate erano rispettivamente ami-08f40561 e ami-1cad5275. Qualcuno ha anche sottolineato che anche i "gruppi di sicurezza" (ovvero il firewall EC2) potrebbero influire. Ma per questo scenario di test, ho provato solo su localhost per eliminare fattori esterni come questo. Un'altra voce che ho sentito dire è che le istanze EC2 non possono spingere più di 100k PPS.
• Due server virtualizzati privati ​​che eseguono Xen. Uno aveva carico zero prima del test ma non faceva differenza.
• Server Xen dedicato dedicato a Rackspace. Circa gli stessi risultati lì.

Sono in procinto di rieseguire questi test e compilare i rapporti su https://gist.github.com/985475 Se desideri aiutare, contribuisci con i tuoi numeri. È facile!

(Il piano d'azione è stato spostato in una risposta separata e consolidata)

In questo momento: le prestazioni di piccoli pacchetti fanno schifo sotto Xen

(invece è passato dalla domanda stessa a una risposta separata)

Secondo un utente su HN (uno sviluppatore KVM?) Ciò è dovuto alle prestazioni di pacchetti di piccole dimensioni in Xen e anche in KVM. È un problema noto con la virtualizzazione e secondo lui, ESX di VMWare lo gestisce molto meglio. Ha anche notato che KVM sta portando alcune nuove funzionalità progettate per alleviare questo ( post originale ).

Questa informazione è un po 'scoraggiante se è corretta. Ad ogni modo, proverò i passaggi seguenti fino a quando un guru Xen non avrà una risposta definitiva :)

Iain Kay dalla mailing list degli utenti xen ha compilato questo grafico: nota le barre TCP_CRR, confronta "2.6.18-239.9.1.el5" vs "2.6.39 (con Xen 4.1.0)".

Piano d'azione attuale basato sulle risposte / risposte qui e da HN :

1. Invia questo problema a una mailing list specifica di Xen e alla bugzilla di xensource come suggerito da syneticon-dj Un messaggio è stato inviato all'elenco di utenti xen , in attesa di risposta.

2. Crea un semplice caso di test patologico a livello di applicazione e pubblicalo.
   Un server di prova con istruzioni è stato creato e pubblicato su GitHub . Con questo dovresti essere in grado di vedere un caso d'uso più reale rispetto a netperf.

3. Prova un'istanza guest PV Xen a 32 bit, poiché 64 bit potrebbe causare un sovraccarico in Xen. Qualcuno l'ha menzionato su HN. Non ha fatto differenza.

4. Prova ad abilitare net.ipv4.tcp_syncookies in sysctl.conf come suggerito da abofh su HN. Ciò apparentemente potrebbe migliorare le prestazioni poiché l'handshake si verificherebbe nel kernel. Non ho avuto fortuna con questo.

5. Aumenta l'arretrato da 1024 a qualcosa di molto più alto, suggerito anche da abofh su HN. Questo potrebbe anche aiutare poiché il guest potrebbe potenzialmente accettare () più connessioni durante la sua porzione di esecuzione fornita da dom0 (l'host).

6. Ricontrolla che conntrack è disabilitato su tutte le macchine in quanto può dimezzare il tasso di accettazione (suggerito da deubeulyou). Sì, è stato disabilitato in tutti i test.

7. Cerca "ascolto overflow della coda e syncache bucket overflow in netstat -s" (suggerito da mike_esspe su HN).

8. Suddividere la gestione degli interrupt tra più core (RPS / RFS che ho provato ad abilitare in precedenza dovrebbero farlo, ma potrebbe valere la pena riprovare). Suggerito da Adam presso HN.

9. Disattivazione dell'offload della segmentazione TCP e accelerazione scatter / raccolta come suggerito da Matt Bailey. (Non possibile su EC2 o host VPS simili)

Aneddoticamente, ho scoperto che la disattivazione dell'accelerazione hardware NIC migliora notevolmente le prestazioni di rete sul controller Xen (vero anche per LXC):

Accell-Scatter-Accell:

/usr/sbin/ethtool -K br0 sg off

Offload della segmentazione TCP:

/usr/sbin/ethtool -K br0 tso off

Dove br0 è il bridge o il dispositivo di rete sull'host hypervisor. Dovrai configurarlo per spegnerlo ad ogni avvio. YMMV.

Forse potresti chiarire un po ': hai eseguito i test con Xen sul tuo server o solo su un'istanza EC2?

Accettare è solo un altro syscall e le nuove connessioni sono diverse solo per il fatto che i primi pacchetti avranno alcuni flag specifici: un hypervisor come Xen non dovrebbe assolutamente vedere alcuna differenza. Altre parti del tuo setup potrebbero: in EC2 per esempio, non sarei sorpreso se i Security Group avessero qualcosa a che fare con esso; conntrack è inoltre segnalato per dimezzare la velocità di accettazione delle nuove connessioni (PDF) .

Infine, sembrano esserci combinazioni CPU / Kernel che causano uno strano utilizzo / blocco della CPU su EC2 (e probabilmente Xen in generale), come recentemente bloggato da Librato .

Assicurati di aver disabilitato iptables e altri hook nel codice bridge in dom0. Ovviamente si applica solo alla configurazione di bridge di rete Xen.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

Dipende dalle dimensioni del server ma da quelle più piccole (processore a 4 core) dedica un core cpu a Xen dom0 e lo blocca. Opzioni di avvio dell'hypervisor:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

Hai provato a passare il dispositivo PCI ethernet fisico a domU? Dovrebbe esserci un buon aumento delle prestazioni.