SWARM Performanță foarte slabă pentru rețeaua de intrare cu o mulțime de solicitări paralele · Problema # 35082 ·
Comentarii
Copiați linkul Citat răspuns
vide comentat 4 octombrie 2017
Descriere
Executarea unui număr mare de conexiuni paralele împotriva Docker simplu și Docker Swarms duce la 2 rezultate complet diferite de performanță, Swarm fiind cel mai lent de un 50x factor!
Testul este reproductibil (cel puțin pe VM-urile mele) cu ușurință cu Siege și imaginea oficială Nginx, dar de fapt mă confrunt cu problema în producție cu microserviciul nostru HTTP bazat pe Java. Nu pot vedea niciun mesaj de eroare evident în jurnalele Docker sau jurnalele kernelului.
Pași pentru a reproduce problema:
Rulați containerul nginx:
Asediați containerul, iar rezultatele sunt bune, peste 13k trans/sec, iar CPU în stresstest01 este 100% utilizat de procesul nginx.
Acum, să încercăm cu Docker Swarm (un roi de noduri, 1 stivă de containere)
După prima rundă, rezultatele sunt deja mult mai proaste decât cu Docker simplu, dar după a doua este
doar un dezastru:( Mai mult, CPU-ul gazdă este ușor utilizat și doar prin procesul nginx. Niciun proces legat de docker (dockerd, cointanerd etc.) nu pare să fie conținut de CPU.
Descrieți rezultatele pe care le-ați primit:
Performanțe bune cu Docker simplu.
Performanțe foarte proaste cu Docker Swarm activat.
Descrieți rezultatele pe care le așteptați:
Performanțe similare pentru cele două arome Docker pe aceeași mașină
Informații suplimentare pe care le considerați importante (de exemplu, problema apare doar ocazional):
Ieșirea versiunii de andocare:
Ieșirea informațiilor despre andocare:
Detalii suplimentare despre mediu (AWS, VirtualBox, fizic etc.):
Este o mașină virtuală KVM (sub oVirt), dar același lucru se întâmplă atunci când se utilizează o mașină fizică.
Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:
vide comentat 4 octombrie 2017
Această problemă este un blocaj total pentru mine și pentru implementarea Swarm în producție. Acesta este un grafic al modului în care s-a schimbat timpul de răspuns după trecerea unei componente din arhitectura noastră de la Swarm la docker simplu, pe aceleași gazde exacte
Cred că voi începe să mă mut la Kubernetes
(linia verde este operații/sec, axa Y stângă)
(comentariu copiat din # 35009 pentru că la început am crezut că este aceeași problemă)
mavenugo comentat 4 octombrie 2017
@vide intrarea în mod swarm este gestionată de IPVS și conexiunile sunt trimise către sarcinile de backend prin rețeaua de intrare suprapusă. Dar, deoarece este o configurare cu un singur nod, scăderea performanței nu se poate întâmpla din cauza anteturilor VXLAN utilizate în rețeaua de suprapunere. Singurul motiv posibil ar putea fi IPVS și ar putea necesita ajustarea performanței pentru cazul dvs.
Putem confirma teoria dacă puteți schimba fișierul stivei cu un mod de parametri suplimentar: gazdă în secțiunea porturi. Acest lucru va ocoli IPVS și va utiliza maparea portului nativ la fel cum o face rularea docker. Puteți confirma pls? ?
vide comentat 4 octombrie 2017
@mavenugo Da, IPVS a fost și suspectul meu numărul 1, nu m-am gândit la modul: trucul gazdei.
Benchmarking din nou cu setările pe care le-ați sugerat:
Ceea ce este comparabil cu rezultatele simple docker.
Deci, ce reglaj pot face pe IPVS în acest caz? Actualizarea kernel-ului poate? Evident, am nevoie de echilibrare a sarcinii IPVS în producție:)
mavenugo comentat 5 octombrie 2017
@vide mulțumesc pentru confirmare. Ar trebui să petrecem un pic mai mult timp analizând problema înainte de a privi IPVS ca sursă a problemei de performanță (deși am menționat asta în comentariul meu anterior:)). Voi încerca asediul și mă voi întoarce la tine.
vide comentat 6 octombrie 2017
@mavenugo Am încercat din nou pe aceeași casetă CentOS cu cel mai recent kernel 4.13 (4.13.4-1.el7.elrepo.x86_64) și rezultatele sunt aceleași.
În plus, am încercat instalarea Ubuntu 17.04 a laptopului meu și rezultatele sunt proaste și aici.
vide comentat 10 octombrie 2017
@mavenugo l-ai putea reproduce pe aparatul tău?
xinfengliu comentat 30 octombrie 2017
Pot reproduce exact problema. Testarea face o nouă conexiune la fiecare cerere.
Conexiunile inactive s-au îngrămădit în curând în ipv-uri.
Dacă nu puteți aștepta ca InActConn să fie zero și să rulați din nou testarea, veți obține un rezultat chiar slab așa cum este descris mai sus.
Pe partea de client sunt pline de „SYN_SENT”.
Dacă doriți să rezolvați această problemă, setați connection = keep-alive în fișierul dvs. .siegerc (utilizați siege.config pentru a genera un șablon .siegerc).
mavenugo comentat 2 noiembrie 2017 •
@vide @xinfengliu L-aș putea reproduce și restrânge la stările Conntracker care cauzează problema. Vedem performanțe mult mai bune făcând ca IPVS să nu folosească conntracker (prin --sysctl net.ipv4.vs.conntrack = 0 doar pentru containerul de asediu).
BTW, Vă rugăm să rețineți că folosesc serviciul VIP direct. Utilizarea numelui serviciului are ca rezultat un impact asupra performanței, deoarece Siege efectuează căutări DNS pentru fiecare interogare și aceasta întârzie procesul. Utilizarea serviciului VIP elimină direct căutările DNS și performanța este mult mai bună.
vide comentat 3 noiembrie 2017 •
@mavenugo Ok, deci, cum pot seta conexiunea de server virtual la 0 în modul Swarm? Conform https://docs.docker.com/compose/compose-file/#not-supported-for-docker-stack-deploy, reglarea sysctl nu este acceptată cu implementarea stivei docker:(
Există o problemă deschisă despre asta: moby/libentitlement # 35
vide comentat 3 noiembrie 2017 •
Și această problemă pare legată: # 31746
mavenugo comentat 3 noiembrie 2017
@vide idk despre stiva de andocare implementează suport. Dar puteți confirma dacă soluția sugerată funcționează într-un caz de implementare non-stack ?
BSWANG comentat 4 noiembrie 2017 •
--sysctl net.ipv4.vs.conntrack = 0 nu poate fi folosit la rețeaua de intrare mesh pe ingress_sbox. Deoarece ipv-urile vor face SNAT după redirecționare.
În serviciul kube-proxy al kubenetes. va seta acești parametri ai nucleului:
https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L88-L91
și net.netfilter.nf_conntrack_buckets, net.netfilter.nf_conntrack_max .
az-z comentat 15 decembrie 2017
Sunt pe RHEL7.4 și docker 1.12. Testarea pe un cluster de 2 noduri cu nginx: ultima implementare în modul mash. Pot reproduce rezultatele @vide. Dar cazul meu de testare este ușor diferit.
În loc să rulez asediul ca container, îl rulez din afara clusterului pentru a încărca o pereche de containere nginx. Experimentez o 10x degradare în timp de răspuns și debit.
împotriva clusterului:
împotriva unui singur nginx:
acesta este un blocaj complet pentru orice implementare ulterioară a swarm-ului pentru noi. Care este soluția și calendarul propus în acest sens? mulțumesc.
EmarMikey comentat 9 ianuarie 2018 •
Ne-am lovit de aceeași problemă cu echilibrarea LVS cu rețea, avem performanțe foarte slabe.
În prezent, am lucrat cu configurația modului gazdă, dar sper că este doar o soluție temporară.
Orice plan pentru a remedia acest lucru?
test în modul gazdă cu ab (doar 1 container):
testați în modul de intrare cu ab:
netstat pe client:
ieșire ipvsadm în spațiul de nume de intrare: