Vraag Waarom is de acceptatie van TCP onder Xen zo slecht?


De snelheid waarmee mijn server nieuwe inkomende TCP-verbindingen kan accepteren () is echt slecht onder Xen. Dezelfde test op bare-metal hardware vertoont 3-5x snelheden.

  1. Waarom is dit zo slecht onder Xen?
  2. Kun je Xen aanpassen om de prestaties van nieuwe TCP-verbindingen te verbeteren?
  3. Zijn er andere virtualisatieplatformen die beter geschikt zijn voor dit soort gebruiksscenario?

Achtergrond

De laatste tijd heb ik onderzoek gedaan naar enkele knelpunten in de prestaties van een in eigen beheer ontwikkelde Java-server die draait onder Xen. De server spreekt HTTP en beantwoordt eenvoudige TCP connect / request / response / disconnect calls.

Maar zelfs tijdens het verzenden van bootladingen verkeer naar de server, kan het niet meer dan ~ 7000 TCP-verbindingen per seconde accepteren (op een 8-core EC2-instantie, c1.xlarge met Xen). Tijdens de test vertoont de server ook een vreemd gedrag waarbij een kern (niet noodzakelijk cpu 0) zwaar wordt belast> 80%, terwijl de andere kernen bijna leeg blijven. Dit doet me denken dat het probleem te maken heeft met de kernel / onderliggende virtualisatie.

Bij het testen van hetzelfde scenario op een niet-gevirtualiseerd platform krijg ik testresultaten met TCP-accept () -tarieven boven 35.000 / seconde. Dit op een Core i5 4-kernmachine met Ubuntu waarvan alle kernen bijna volledig verzadigd zijn. Voor mij lijkt dat soort figuur ongeveer juist.

Op de Xen-instantie opnieuw, heb ik geprobeerd om bijna alle instellingen die zich in sysctl.conf bevinden aan te passen / tweaken. Inclusief inschakelen Stuurpakketsturing ontvangen en Ontvang flowsturing en het vastzetten van threads / processen naar CPU's maar zonder duidelijke winst.

Ik weet dat gedegradeerde prestaties te verwachten zijn bij gevirtualiseerd werken. Maar in deze mate? Een langzamere, kale metalen server die beter presteert dan de virt. 8-core met een factor 5?

  1. Is dit werkelijk verwachte gedrag van Xen?
  2. Kun je Xen aanpassen om de prestaties van nieuwe TCP-verbindingen te verbeteren?
  3. Zijn er andere virtualisatieplatformen die beter geschikt zijn voor dit soort gebruiksscenario?

Dit gedrag reproduceren

Bij nader onderzoek hiervan en het probleem op te sporen kwam ik erachter dat het netperf performance testing tool zou het vergelijkbare scenario kunnen simuleren dat ik ervaar. Met behulp van de TCP_CRR-test van netperf heb ik verschillende rapporten verzameld van verschillende servers (zowel gevirtualiseerd als niet-virt.). Als u wilt bijdragen met enkele bevindingen of mijn huidige rapporten opzoekt, raadpleegt u https://gist.github.com/985475

Hoe weet ik dat dit probleem niet te wijten is aan slecht geschreven software?

  1. De server is getest op bare-metal hardware en bijna alle beschikbare cores verzadigd.
  2. Bij het gebruik van TCP-verbindingen die in leven blijven, verdwijnt het probleem.

Waarom is dit belangrijk?

Op ESN (mijn werkgever) Ik ben de projectleider van Beaconpush, een Comet / Web Socket-server geschreven in Java. Hoewel het zeer performant is en vrijwel elke bandbreedte die het krijgt onder optimale omstandigheden kan verzadigen, is het nog steeds beperkt tot hoe snel nieuwe TCP-verbindingen kunnen worden gemaakt. Dat wil zeggen, als u een grote gebruikersverloop hebt waarbij gebruikers vaak komen en gaan, zullen veel TCP-verbindingen moeten worden ingesteld / afgebroken. We proberen deze verbindingen zo lang mogelijk levend te houden. Maar uiteindelijk zorgt de accept () -prestatie ervoor dat onze kernen niet draaien en dat vinden we niet leuk.


Update 1

Iemand plaatste deze vraag op Hacker News, er zijn ook enkele vragen / antwoorden. Maar ik zal proberen deze vraag up-to-date te houden met informatie die ik vind terwijl ik meega.

Hardware / platforms waarop ik dit heb getest:

  • EC2 met instantietypen c1.xlarge (8 cores, 7 GB RAM) en cc1.4xlarge (2x Intel Xeon X5570, 23 GB RAM). Gebruikte AMI's waren respectievelijk ami-08f40561 en ami-1cad5275. Iemand wees er ook op dat de "Beveiligingsgroepen" (d.w.z. EC2s-firewall) ook van invloed kunnen zijn. Maar voor dit testscenario heb ik alleen op localhost geprobeerd om externe factoren zoals deze te elimineren. Een ander gerucht dat ik heb gehoord is dat EC2-instanties niet meer dan 100.000 PPS kunnen pushen.
  • Twee private gevirtualiseerde servers met Xen. Eén had nul belasting voorafgaand aan de test maar maakte geen verschil.
  • Private dedicated, Xen-server bij Rackspace. Over dezelfde resultaten daar.

Ik ben bezig met het opnieuw uitvoeren van deze tests en het invullen van de rapporten op https://gist.github.com/985475 Als je wilt helpen, geef je je cijfers op. Het is makkelijk!

(Het actieplan is verplaatst naar een afzonderlijk, geconsolideerd antwoord)


87
2018-05-22 16:39


oorsprong


Uitstekend werk om een ​​kwestie op te sporen, maar ik geloof dat je veel beter wordt bediend op een Xen-specifieke mailinglijst, ondersteuningsforum of zelfs de xensource bugrapport-site. Ik denk dat dit een bug in de scheduler zou kunnen zijn - als u uw aantallen van 7.000 connecties * 4 cores / 0.80 CPU-belasting haalt, krijgt u precies 35.000 - het nummer dat u zou krijgen als 4 cores volledig verzadigd zouden zijn. - the-wabbit
Ah, en nog iets: probeer een andere (recentere misschien) kernelversie voor je gast, als je kunt. - the-wabbit
@ syneticon-dj Bedankt. Ik probeerde het op een cc1.4xlarge op EC2 met kernel 2.6.38. Ik zag ongeveer een toename van ~ 10% als ik me niet vergis. Maar het is waarschijnlijker vanwege de zwaardere hardware van dat instantietype. - cgbystrom
bedankt dat je dit up-to-date hebt gehouden met de HN-reacties, het is een geweldige vraag. Ik stel voor om het actieplan mogelijk in een geconsolideerd antwoord te plaatsen, omdat dit allemaal mogelijke antwoorden op het probleem zijn. - Jeff Atwood
@jeff Verplaats het actieplan, controleer. - cgbystrom


antwoorden:


Op dit moment: kleine pakketprestaties zuigt onder Xen

(verplaatst van de vraag zelf naar een apart antwoord)

Volgens een gebruiker op HN (een KVM-ontwikkelaar?) Komt dit door de kleine pakketprestaties in Xen en ook KVM. Het is een bekend probleem met virtualisatie en volgens hem werkt VMWare's ESX dit veel beter. Hij merkte ook op dat KVM enkele nieuwe functies introduceert die zijn ontworpen om dit te verlichten (origineel bericht).

Deze info is een beetje ontmoedigend als het correct is. Hoe dan ook, ik zal de onderstaande stappen proberen totdat een Xen-goeroe komt met een definitief antwoord :)

Iain Kay van de xen-users mailinglijst compileerde deze grafiek: netperf graph Let op de TCP_CRR balken, vergelijk "2.6.18-239.9.1.el5" vs "2.6.39 (met Xen 4.1.0)".

Huidig ​​actieplan gebaseerd op antwoorden / antwoorden hier en van HN:

  1. Dien dit probleem in op een Xen-specifieke mailinglijst en de bugzilla van xensource zoals gesuggereerd door syneticon-dj EEN bericht is in de xen-gebruikerslijst geplaatst, In afwachting van een antwoord.

  2. Maak een eenvoudige pathologische, applicatie-level testcase en publiceer deze.
    Er is een testserver met instructies gemaakt en gepubliceerd op GitHub. Hiermee zou u een realistischere use-case moeten kunnen zien in vergelijking met netperf.

  3. Probeer een 32-bits PV Xen-gastexemplaar, omdat 64-bits mogelijk meer overhead in Xen veroorzaakt. Iemand heeft dit op HN vermeld. Heeft geen verschil gemaakt.

  4. Probeer het inschakelen van net.ipv4.tcp_syncookies in sysctl.conf zoals voorgesteld door abofh op HN. Dit blijkbaar macht de prestaties verbeteren, omdat de handshake in de kernel zou plaatsvinden. Ik had hier geen geluk mee.

  5. Verhoog de backlog van 1024 naar iets veel hoger, ook gesuggereerd door abofh op HN. Dit zou ook kunnen helpen, omdat de gast mogelijk () meer verbindingen zou kunnen accepteren tijdens het uitvoeringspiep gegeven door dom0 (de host).

  6. Controleer nogmaals of conntrack op alle machines is uitgeschakeld, omdat het de acceptatiegraad kan halveren (voorgesteld door deubeulyou). Ja, het was uitgeschakeld in alle tests.

  7. Controleer op "overloop overloopwachtrij en syncache-emmers overloop in netstat -s" (gesuggereerd door mike_esspe op HN).

  8. Splits de interruptafhandeling tussen meerdere kernen (RPS / RFS die ik eerder heb geprobeerd te activeren verondersteld om dit te doen, maar het zou de moeite waard zijn om het opnieuw te proberen). Aanbevolen door adamt op HN.

  9. Het uitschakelen van de TCP-segmentatie uitschakelen en de versnelling versnellen / verzamelen zoals voorgesteld door Matt Bailey. (Niet mogelijk op EC2 of vergelijkbare VPS-hosts)


26
2018-05-22 23:41



+1 Plaats de prestatieresultaten definitief als je erachter bent! - chrisaycock
Iemand heeft me op Twitter gepest met betrekking tot deze vraag. Helaas lijkt het alsof deze problemen blijven bestaan. Ik heb sinds vorig jaar niet veel onderzoek gedaan. Xen KAN in deze periode zijn verbeterd, ik weet het niet. De KVM-ontwikkelaar zei ook dat ze dergelijke problemen aanpakken. Zou de moeite van het nastreven waard zijn. Een andere aanbeveling die ik heb gehoord is om OpenVZ uit te proberen in plaats van Xen / KVM omdat het minder of geen laagjes / onderschepping van syscalls toevoegt. - cgbystrom


Anekdotisch vond ik dat het uitschakelen van NIC hardwareversnelling de netwerkprestaties op de Xen-controller enorm verbetert (ook voor LXC):

Scatter-gather accell:

/usr/sbin/ethtool -K br0 sg off

TCP Segmentation offload:

/usr/sbin/ethtool -K br0 tso off

Waarbij br0 uw bridge- of netwerkapparaat op de hypervisorhost is. U moet dit instellen om het bij elke start uit te schakelen. YMMV.


20
2018-05-22 19:09



Ik tweede dit. Ik had een server van Vensters 2003 die op Xen loopt die sommige vreselijke pakketverliesproblemen onder hoge productieomstandigheden onderging. Het probleem ging weg toen ik TCP-segment offload uitschakelde - rupello
Bedankt. Ik heb het 'actieplan' in de oorspronkelijke vraag bijgewerkt met uw suggesties. - cgbystrom
zie ook cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


Misschien kon je een beetje ophelderen - heb je de tests onder Xen uitgevoerd op je eigen server of alleen op een EC2-instantie?

Accept is gewoon een andere syscall en nieuwe verbindingen zijn alleen verschillend omdat de eerste paar pakketten een aantal specifieke vlaggen hebben - een hypervisor zoals Xen zou absoluut geen verschil moeten zien. Andere delen van je setup kunnen zijn: in EC2 bijvoorbeeld zou het me niet verbazen als Security Groups er iets mee te maken hadden; Conntrack is ook naar verluidt halve nieuwe acceptatiegraad (PDF).

Ten slotte lijken er CPU / Kernel-combinaties te zijn die vreemd CPU-gebruik / hangups op EC2 veroorzaken (en waarschijnlijk Xen in het algemeen), zoals blogde onlangs over door Librato.


2
2018-05-22 19:56



Ik heb de vraag bijgewerkt en verduidelijkt op welke hardware ik dit heb geprobeerd. abofh stelde ook voor om de achterstand boven 1024 te verhogen om het aantal mogelijke accept () s tijdens een uitvoeringsplak voor de gast te versnellen. Wat conntrack betreft, moet ik zeker controleren of dergelijke dingen zijn uitgeschakeld, bedankt. Ik heb dat Liberato-artikel gelezen maar gezien de hoeveelheid verschillende hardware waarop ik dit heb geprobeerd, zou het niet het geval moeten zijn. - cgbystrom


Zorg ervoor dat u iptables en andere hooks in bridging-code in dom0 hebt uitgeschakeld. Het is duidelijk dat dit alleen van toepassing is op Xen-instellingen voor bridge-netwerken.

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

Het hangt af van de grootte van de server, maar op kleinere (4-coreprocessor) wijden één cpu-kern aan Xen dom0 en pinnen deze. Hypervisor opstartopties:

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

Heb je geprobeerd het fysieke ethernet PCI-apparaat door te geven aan domU? Er moet een mooie prestatieverbetering zijn.


0
2018-02-11 11:35