înregistrare Logare
Puncte:0
OpenSource avatar Ubuntu

Sarcină uriașă a procesorului sub un număr mare de conexiuni TCP

drapel tr
OpenSource

Sub o cantitate mare de conexiuni TCP, un nucleu CPU va ajunge întotdeauna la 100%. După ce se întâmplă acest lucru, întreaga VM va începe să întârzie și va exista o pierdere evidentă a pachetelor.

Există o modalitate de a o rezolva, de a face conexiunile TCP să utilizeze mai puțin CPU sau chiar de a o limita?

NOTĂ: Limitarea ratei prin iptables nu va funcționa. A încercat următoarele:

iptables -A INPUT -i eth0 -m stare --state NOU -p tcp -m limit --limit 30/minut --dport 25565 -j ACCEPT

iptables -A INPUT -i eth0 -m stare --state NEW -p tcp --dport 25565 -j DROP

Rețineți că chiar și renunțarea la portul cu iptables -A INPUT -p tcp --dport 25565 -j DROP nu va funcționa.

Sub htop, nu pot vedea ce proces ia procesorul, așa că presupun că este ceva cu Kernel. Unii furnizori de hosting precum OVH au rezolvat acest lucru, dar sub mulți alții, se întâmplă. Care sunt opțiunile mele?

Toate cele bune

104
1 + 8
nic
Doug Smythies avatar
drapel gn
Doug Smythies
Te confrunți cu un atac DDOS (Distributed Denial Of Service)? Da-ne mai multe detalii. Pentru ce folosești portul 25565? Un server minecraft? Au fost aplicate regulile tale de testare iptables în locul potrivit în raport cu celelalte reguli pentru a fi eficiente? Utilizați ` sudo iptables -xvnL` pentru a observa câte pachete v-au luat căile de testare. Ce versiune de Ubuntu?
2
Răspunde
OpenSource avatar
drapel tr
OpenSource
O utilizare intenționată ar fi într-adevăr un MC Reverse Proxy, cu toate acestea, la momentul testării, portul era deschis cu Ubuntu 20.04 fără niciun serviciu care rulează sub acesta (deși rezultatul este același chiar dacă este închis prin IPTables). Singura regulă pe care am aplicat-o la momentul testării a fost: iptables -A INPUT -p tcp --dport 25565 -j DROP. Chiar și cu acel port închis complet, o cantitate mare de conexiuni fac ca VM să folosească 100% CPU. Un punct de referință este practic un atac de bot de 20.000 CPS, deoarece intenționăm să implementăm un proxy invers pe acel port, ceea ce înseamnă că trebuie să gestioneze o mulțime de CPS. Cu toate acestea, chiar și fără nimic desfășurat
0
Răspunde
OpenSource avatar
drapel tr
OpenSource
Pur și simplu va începe să întârzie și să folosească 100% dintr-un nucleu CPU.
0
Răspunde
OpenSource avatar
drapel tr
OpenSource
https://hastebin.com/soneqonivo.apache
0
Răspunde
OpenSource avatar
drapel tr
OpenSource
L-am folosit o singură dată, așa cum l-am testat înainte, dar sper că va fi suficient. Vad 11040 ACCEPT si 746778220 DROP.
0
Răspunde
Doug Smythies avatar
drapel gn
Doug Smythies
Pachetele sunt numerele relevante 186/12488841 ACCEPT/DROP. Aplicația ta este destul de extremă.
0
Răspunde
waltinator avatar
drapel it
waltinator
Cu fir sau fără fir? Este MTU-ul dvs. (`ip l | grep $(ip r | awk '/default/ {print $5}' ) | awk '{print $2, $4, $5}'`) prea mare? MTU fără fir ar trebui să fie 1492 (antet PPPOE de 8 octeți), în caz contrar, obțineți fragmentare și reasamblare a pachetelor, ceea ce poate consuma CPU.
0
Răspunde
Doug Smythies avatar
drapel gn
Doug Smythies
@waltinator: acestea sunt în întregime pachete SYN la 60 de octeți fiecare. Nu cred că fragmentarea este posibilă pentru un pachet SYN.
0
Răspunde
Puncte:2
Doug Smythies avatar Ubuntu
drapel gn
Doug Smythies

Nu cred că problema dvs. este în kernel și nici nu cred că blocajul dvs. de calcul este legat de lucrurile din rețea, în funcție de hardware-ul dvs.

Am facut urmatorul experiment:

Computer server 1: utilizați hping3 pentru a genera pachete SYN la o rată de 28.870 pe secundă (derivat prin experiment și considerat a fi suficient de aproape de ceea ce faceți) la portul 25565 de pe computerul server 2. Comanda utilizată:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 s19

Unde „s19” este computerul server 2, iar „u20” are costuri generale și, de fapt, rezultatele sunt 28.870 de pachete pe secundă în loc de 50.000.

Computer server 2: are regula IPtable DROP. Turbostat a fost, de asemenea, rulat pentru a observa puterea și încărcările CPU. Aceste comenzi au fost executate:

doug@s19:~/tmp$ sudo iptables -xvnL ; somn 10; sudo iptables -xvnL
INTRARE în lanț (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination
 2293479 91739160 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 stare NOU tcp dpt:25565

Lanț FORWARD (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination

Ieșire în lanț (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination
INTRARE în lanț (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination
 2582175 103287000 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 stare NOU tcp dpt:25565

Lanț FORWARD (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination

Ieșire în lanț (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination

Deci 2582175 - 2293479 = 288.696 pachete în 10 secunde sau 28.870/secundă. Notă: am mai puțini octeți pe pachet decât tine, la 40, în timp ce tu se pare că ai 60.

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Ocupat % Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
0,61 4800 196262 38 17,91 17,25 0,00 0,89
0,61 4800 196844 38 17,95 17,29 0,00 0,89
0,60 4800 197409 39 18,01 17,35 0,00 0,89

Utilizare neglijabilă a procesorului, dar cu aproximativ 16 wați mai mult decât inactiv (inactiv = 1,5 wați).

Computer desktop 1: O mașină virtuală qemu/kvm 20.04 care rulează ca invitat pe computerul server 2.

Comanda hping3 pentru computerul server 1 devine:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 192.168.111.19

Iar rezultatele sunt:

doug@desk-ff:~$ sudo iptables -xvnL ; dormi 100; sudo iptables -xvnL
INTRARE în lanț (politica ACCEPTĂ 117 pachete, 9384 octeți)
    pkts bytes target prot opt ​​in out source destination
 2086906 83476240 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 stare NOU tcp dpt:25565

Lanț FORWARD (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination

IEȘIRE în lanț (politica ACCEPTĂ 73 de pachete, 9116 octeți)
    pkts bytes target prot opt ​​in out source destination
INTRARE în lanț (politica ACCEPTĂ 144 de pachete, 12151 de octeți)
    pkts bytes target prot opt ​​in out source destination
 4970267 198810680 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 stare NOU tcp dpt:25565

Lanț FORWARD (politica ACCEPT 0 pachete, 0 octeți)
    pkts bytes target prot opt ​​in out source destination

IEȘIRE în lanț (politica ACCEPTĂ 77 de pachete, 9996 de octeți)
    pkts bytes target prot opt ​​in out source destination

Deci, 4970267 - 2086906 = 288.361 pachete în 100 de secunde sau 28.834/secundă.

și pe computerul gazdă:

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Ocupat % Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
9,61 4800 207685 58 31,19 30,53 0,00 0,89
9,64 4800 211088 58 31,14 30,48 0,00 0,89
9,44 4800 202499 59 30,72 30,07 0,00 0,89

Am 12 procesoare, deci utilizarea este mai mare de 100% a unui procesor. Sau prin partea de sus:

sus - 11:58:16 până 10 zile, 18:57, 2 utilizatori, medie de încărcare: 1,00, 0,99, 0,81
Sarcini: 239 total, 1 alergare, 238 dormit, 0 oprit, 0 zombi
%Cpu0: 0,3 us, 0,0 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu1: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7: 0.0 us, 0.0 sy, 0.0 ni, 100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8: 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu9: 0.0 us, 3.1 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
%Cpu10: 8.3 us, 90.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
%Cpu11: 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st

Deci, da, că faci asta într-o VM pare să consume mult mai multe resurse CPU.O opțiune este să nu faceți acest lucru într-un VM. Sau, atribuiți mai multe VCPU VM-ului. Am reușit să ajung la 118.283 de pachete pe secundă („u1” opțiune de interval hping3), cu o creștere de doar câteva procente a utilizării generale a procesorului pe gazdă.

EDIT: Utilizarea procesorului gazdă în comparație cu pachetele pe secundă către VM este destul de interesantă, cu un răspuns de tip de funcție pas între 5000 și 6000 pps (reamintim că 8,33% este 100% din 1 CPU pentru această gazdă cu 12 CPU):

introduceți descrierea imaginii aici

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.