Puncte:1

Serverul Linux nu permite mai mult de 2048 de conexiuni simultane

drapel in

Am încercat să fac un test de încărcare pe MQTT de la MACOS-ul meu și am reușit să realizez cu succes mai mult de 12k conexiuni până când lățimea de bandă a fost epuizată.

Am încercat să fac același test pe mașina GCP și mi-a dat excepția expirării conexiunii odată ce porturile deschise au ajuns la 2048 și 2048 conexiuni cu broker MQTT.

Când mă conectez, ConnectionTimeout este de 100 de secunde (în așteptarea conectării) și KeepAlive = 300 de secunde (odată ce conexiunea este stabilită)

Această problemă se întâmplă indiferent de software-ul de testare a sarcinii, adică mzbench, jmeter și emqtt-bench. Deci, cred că această problemă este legată de serverul Linux.

Nu caut să obțin 1 milion de conexiuni deschise, ci caut cel puțin 30.000 de conexiuni deschise.

Am încercat deja să schimb ulimit și acestea sunt configurațiile mele ulimit

dimensiunea fișierului de bază (blocuri, -c) 0
dimensiunea segmentului de date (kbytes, -d) nelimitat
prioritate de programare (-e) 0
dimensiunea fișierului (blocuri, -f) nelimitată
semnale în așteptare (-i) 63887
memorie maximă blocată (kbytes, -l) 64
dimensiunea maximă a memoriei (kbytes, -m) nelimitată
deschideți fișierele (-n) 102400
dimensiunea conductei (512 octeți, -p) 8
Cozi de mesaje POSIX (octeți, -q) 819200
prioritate în timp real (-r) 0
dimensiunea stivei (kbytes, -s) 8192
timp CPU (secunde, -t) nelimitat
max. procese utilizator (-u) 200000
memorie virtuală (kbytes, -v) nelimitată
blocări de fișiere (-x) nelimitate

cat on proc oferă, de asemenea, fișierul maxim deschis ca 102400

de asemenea, acestea sunt valori setate în sysctl-ul meu

fs.file-max = 200000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576 64768 98152
net.core.netdev_max_backlog = 2500

Editare: S-au adăugat detalii despre mașină și model de testare

Tip de mașină: n2-highcpu-16 (16 vCPU, 16 GB memorie)

Rezultatul lscpu

Arhitectură: x86_64
Modul operațional al procesorului: 32 de biți, 64 de biți
Ordinea octetilor: Little Endian
CPU(e): 16
Lista CPU(e) on-line: 0-15
Filet(e) per miez: 2
Miez(e) per soclu: 8
Priză(i): 1
Nod(e) NUMA: 1
ID furnizor: GenuineIntel
Familia CPU: 6
Model: 85
Nume model: CPU Intel(R) Xeon(R).
Pasul: 7
CPU MHz: 2800.200
BogoMIPS: 5600,40
Furnizor de hypervisor: KVM
Tip de virtualizare: complet
Cache L1d: 32K
Cache L1i: 32K
Cache L2: 1024K
Cache L3: 33792K
CPU nod0 NUMA: 0-15
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat avx512_vnni md_clear arch_capabilities

Model de testare: Deschiderea a 200 de conexiuni pe secundă și așteptarea conectării la o rată constantă.

drapel jp
Ce tip de mașină ați folosit? Cât de repede ți-ai stabilit toate conexiunile?
drapel in
@SerhiiRohoza a editat întrebarea și a adăugat detaliile cerute
Matthew Ife avatar
drapel jo
Puteți furniza informații suplimentare cu privire la brokerul pe care îl utilizați pe Linux?
drapel in
@MatthewIfe Da, brokerul pe care îl folosesc este și pe Linux. Cu toate acestea, nu cred că ar trebui să fie cauza principală, deoarece pot deschide 12k conexiuni din local, dar numai 2k conexiuni de la serverul meu de testare.
Matthew Ife avatar
drapel jo
Sunt interesat de implementarea software-ului pe care o utilizați, deoarece diferitele mecanisme de concurență au limite diferite. De asemenea, limitele tale din shell nu sunt neapărat limitele software-ului, dar din moment ce nu ai oferit implementarea brokerului pe care îl folosești și nici mijloacele prin care l-ai implementat, nu există suficiente informații cu care să lucrezi.
drapel in
Brokerii utilizați sunt brokeri emqx implementați pe o mașină gcloud similară. Ulimitele furnizate mai sus sunt ulimit-ul clientului care încearcă să creeze o conexiune la broker.
John Hanley avatar
drapel cn
S-ar putea să mă înșel, dar cred că VM-ul dvs. GCP este supus unor porturi deschise simultane de către firewall-ul/gateway-ul VPC. Conexiunile în Google Cloud sunt cu stare și sunt urmărite astfel încât să fie acceptat traficul de retur.
John Hanley avatar
drapel cn
Tipurile de mașini cu 1 - 8 vCPU-uri sunt limitate la 500 de conexiuni per vCPU la 5 secunde, cu un maxim de 4000 pentru tipurile de mașini mai mari. https://cloud.google.com/vpc/docs/quota#per_instance Acesta nu se potrivește cu plafonul dvs. de 2000...
Puncte:1
drapel in

Am reușit să rezolv această problemă, datorită comentariilor de mai sus.

Am lovit IP-ul public LoadBalancer de la VM-ul meu de testare. Cu toate acestea, GCP are o limită de maximum 2048 de conexiuni de la o VM la IP public. Odată ce l-am schimbat la IP privat, am reușit să obțin conexiuni de aproape 65k.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.