Astăzi vin să vă vorbesc încă o dată despre unul dintre cele mai utilizate servicii web din lume: serverul web Apache2.
Este un subiect despre care s-a vorbit de multe ori, dar acum vin să vă povestesc despre o altă caracteristică de care să ții cont cu acest serviciu: Limita conexiunilor simultane. Nu contează dacă avem o bază sau o navă spațială cu un procesor i7 și 32 GB de ram ...
Limita conexiunilor simultane va fi întotdeauna aceeași, cu excepția cazului în care luăm măsurile adecvate, ceea ce înseamnă că, dacă vrem să avem mulți oameni conectați în același timp, nu vom solicita doar hardware bun, ci și o configurație bună.
În acest caz, nu este necesar să instalați nimic, totul se bazează pe concepte simple care trebuie luate în considerare pentru a configura apache; concepte care trebuie să fie foarte clare înainte de a dori să facă modificări.
Primul lucru la care trebuie să ne gândim este: Ce capacitate are echipa mea? Câte conexiuni simultane pot suporta echipamentul meu dacă îl forțez cât mai mult posibil? Toate acestea depind de un singur factor; RAM (Random Access Memory).
Cu cât RAM-ul este mai mare, cu atât este mai mare numărul de conexiuni, deși nu există o valoare fixă (adică X clienți pentru fiecare X RAM), de aceea, în primul rând, este important să facem câteva calcule mici pe serverul nostru web, cu pentru a ne cunoaște limitele.
Primul lucru pe care trebuie să-l știți este cât de multă memorie RAM consumă în medie fiecare conexiune la Apache, deoarece fiecare conexiune stabilită presupune un anumit consum de memorie RAM în sistem ... Evident, nu toate conexiunile consumă același RAM, cu care ar trebui să faceți un media ... Toate acestea pot fi obținute cu următoarea comandă:
ps -ylC apache2 --sort: rss | awk '{SUM + = 8 $; I + = 1} END {print SUM / I / 1024} '
Rezultatul obținut ar fi reprezentat în megaocteți și poate varia în funcție de numărul de conexiuni active, de tipul de pagini accesate etc ... Prin urmare, este recomandabil să efectuați testul cu diferite file deschise; fiecare dintre ele prezentând conținut diferit, dacă este posibil. În cazul meu, de exemplu, rezultatul a fost 9.5458, care, dacă îl rotunjim în sus, ar fi 10 MB RAM consumat în medie pe conexiune.
De asemenea, este important să știți câtă memorie RAM este consumată de restul proceselor active în sistem, deoarece serviciul web nu este singurul care rulează în sistemul de operare și este necesar să lăsați memorie RAM gratuită pe server, astfel încât acesta să poată executa restul sarcinilor. Acest lucru poate fi obținut cu comanda prezentată mai jos:
ps -N -ylC apache2 --sort: rss | awk „{SUM + = 8 $} END {print SUM / 1024}”
Rezultatul obținut ar fi reprezentat și în megaocteți și ne-ar arăta destul de precis cantitatea de RAM consumată de restul proceselor; În cazul meu 800 MB. Cu aceste informații am putea face un calcul general al numărului de conexiuni simultane pe care le-am putea avea; Calculez că am obține printr-o operație foarte simplă.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Cu această formulă în mână, să ne imaginăm că avem un computer cu 4 GB RAM, adică 4096 MB și că computerul nostru a arătat rezultatele menționate anterior; calculul ar fi:
(4096 - 800) / 10 = 329 conexiuni simultane
Problema cu acest calcul este că una este prea extremă, deoarece ar consuma toată memoria RAM (făcând serverul să consume swap) și, de asemenea, în caz de a avea o bază de date, cum ar fi MySQL sau orice altul, conexiunile la aceasta ar consuma și RAM , deci numărul obținut ar putea fi calificat ca număr utopic. Prin urmare, pentru a elibera memoria pentru eventuale procese suplimentare și pentru a lua în considerare posibilitatea executării conexiunilor la o bază de date, am reduce numărul de conexiuni la 250.
Acum că avem numărul maxim de conexiuni simultane, ar trebui să pregătim Apache pentru a primi acest număr, lucru care se face în fișierul de configurare al acestui apel apache2.conf, care este găzduit în / etc / apache2.
Fișierul în cauză urmează o structură bazată pe module, fiecare cu numele său corespunzător, dar ne-ar interesa doar unul dintre ei, al cărui nume este mpm_prefork_module. Modulul în cauză are următoarele date în mod implicit:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Acest modul are o serie de parametri foarte importanți, deși există unul dintre ei care ne-ar interesa în mod special, numit MaxClients. Acest parametru specifică numărul maxim de conexiuni simultane și trebuie modificat în 250.
Un detaliu de reținut este că, atunci când o valoare diferită de cea implicită este specificată în parametrul menționat, este necesar să adăugați altul doar înainte de acesta. Acest parametru se numește ServerLimit și stabilește limita conexiunilor pe care serverul le-ar putea „reține” chiar și atunci când este în afara limitei.
Parametrul ServerLimit trebuie să fie întotdeauna puțin mai mare decât MaxClients și aici, deoarece există puțin spațiu de manevră, o limită de 270. Acest lucru ar face modulul să arate astfel:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Acum ar fi necesar să reporniți serviciul Apache folosind comanda:
/etc/init.d/apache2 reporniți
Cu aceasta ne-am putea bucura deja de serverul nostru web optimizat.
Salutări.
Mulțumesc pentru postare!
Mă bucur că ți s-a părut util.
Salutări.
Există o modalitate de a grupa cu Apache și două servere, puteți explica cum funcționează?
Deși am citit o teorie despre asta, nu am aplicat-o niciodată în practică. Chiar și așa, poate acest articol vă poate oferi câteva îndrumări în acest sens, deși repet că nu am avut ocazia să-l pun în practică:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
ai cerut o vreme, dacă nu ai rezolvat; Am o schemă de echilibrare cu o terță parte care acționează ca un sistem de fișiere, îndreptați folderele care sunt în var / www / html / (în cazul meu) către sistemul de fișiere, astfel încât acestea să împărtășească aceleași informații și, eventual, veți avea nevoie de un ip virtual care să răspundă și redirecționați către IPs-urile apache, pentru aceasta puteți ocupa un haproxy și, dacă doriți în disponibilitate ridicată, puteți integra keepalive în cazul în care unul cade, celălalt continuă să răspundă sau, de asemenea, dacă aveți deja un domeniu pentru aplicație, puteți echilibra cu lira efectuând backend-uri către ambele servere, pentru cazuri specifice, cum ar fi moodle sau anumite aplicații care se conectează la o bază de date în mysql, va trebui să creați un utilizator pe fiecare server de aplicație care să indice aceeași bază de date.
Vă mulțumesc foarte mult pentru postare, aveți perfectă dreptate, RAM este calculul principal, deși îmi imaginez că calculăm și numărul maxim de procese pe care procesorul nostru le poate gestiona (desigur, făcând mai întâi calculul memoriei principale) și modul în care ar fi distribuit discul hard (Exemplu de partiții / var = 1TR).
Ai dreptate; totul este important, precum controlul temperaturii, printre altele. Evident, un procesor puternic poate executa un număr mai mare de sarcini simultan cu o eficiență mare, dar obiectivul acestui post a fost de a explica importanța RAM în ceea ce privește numărul de conexiuni simultane.
O modalitate bună de a controla toți acești factori și de a vedea dacă procesorul nostru nu este saturat sau dacă avem puțină memorie RAM gratuită, ar fi prin utilizarea unui script bash. Poate că această postare pe care am făcut-o acum câteva zile despre ea va fi interesantă pentru dvs., pe care o las în linkul următor; Este o monitorizare globală, dar poate fi interesant pentru cineva:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
În ceea ce priveşte
Notă foarte bună, mulțumesc foarte mult!
Mulțumesc mult! Sper că ai reușit să profiți de ea.
Nu vreau să fiu un tâmpit ...
… Dar, prin creșterea numărului de conexiuni, nu rămâneți mai vulnerabili la un atac DDoS?
Nu este o întrebare liniștită despre cretin. Adevărul este că, prin creșterea numărului de conexiuni simultane, fortificăm parțial Apache împotriva atacurilor DDOS, deoarece trebuie să țineți cont de faptul că numărul de conexiuni simultane maxime stabilite pe server este numărul de conexiuni maxime totale, nu cele care provin de la un singur utilizator. Astfel, în timp ce la început am putut suporta doar 150 de conexiuni simultane (indiferent dacă sunt conexiuni dintr-o sursă legitimă sau nu), acum putem conta pe cât de multe suportă serverul nostru, necesitând un număr mai mare de conexiuni în același timp pentru a rămâne fără service. Evident, creșterea numărului maxim de conexiuni nu este o modalitate de a vă proteja de acest tip de atac, ci mai degrabă ar trebui implementate politici de firewall. Dacă, de exemplu, serviciul web pe care doriți să îl puneți va fi expus la internet, o măsură de securitate care ar putea fi implementată ar fi adăugarea acestor linii la firewall-ul nostru:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-până la 10 -m stare –state NOU -j ACCEPT
iptables -A INPUT -p tcp –port 80 -m state –stat STABILIT, AFILIAT -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j DROP
Una dintre caracteristicile atacurilor DDoS este că un atacator poate părea să trimită pachete din mai multe direcții diferite, ceea ce împiedică fluxul de pachete să vină doar dintr-o singură direcție.
Ai dreptate în sensul că un firewall ca cel pe care l-am configurat nu este foarte eficient împotriva unui atac DDOS, deoarece provine din diferite surse. Totuși, este mai bine să limitați numărul de conexiuni la 10 pentru fiecare dintre aceste surse, mai degrabă decât să nu aveți o limită, astfel încât fiecare sursă să poată stabili o sută sau mai multe conexiuni.
În orice caz, trusa întrebării este că, cu cât serverul acceptă mai multe conexiuni simultane, cu atât va fi mai dificil să îl doborâți cu un atac DDOS, ceea ce ar face mai dificilă ca pagina să fie doborâtă de un atacator.
Salutări.
Bun. Deocamdată continui cu NGINX pe site-ul meu pentru a nu tortura VPS-ul pe care îl am.
Post bun @ Drassill!
Am vrut să contribui cu ceva probabil mai mult statistic decât configurație.
Deși cel mai simplu și mai rapid mod de a calcula parametrul de consum este cu media, poate am putea fi mai riguroși și să folosim „mediana” în loc de „medie”. De ce ne-ar salva? Că numerele dispar în cazul în care o conexiune a consumat multă memorie. De exemplu, să presupunem că următorii clienți care consumă următoarele valori, în unitatea de memorie dorită (KB, MB, MiB etc.):
10, 15, 150, 5, 7, 10, 11, 12
Media ar da aproximativ 30
Și asta pentru că avem o extremă foarte mare (150), iar calculele sunt nebunești. Mediana constă în ordonarea acestor date, împărțirea numărului de probe la 2 (centrul nostru) și apoi obținerea numărului poziției respective. Cu asta am avea ceva de genul
5, 7, 10, 10, 11, 12, 15, 150
Deci, media noastră ar fi: 8/2 = 4, adică ~ 10
Aici puteți vedea că, oricât de nebună ar fi extrema, ne va oferi întotdeauna o valoare mai realistă. Dacă adăugăm un client care consumă 200, mediana noastră va fi de 11, în timp ce media poate merge la …….
Este doar o contribuție și este foarte discutabilă, deoarece cu conexiunile nu este înșurubat.
Îmbrățișează oamenii linuxera 🙂
Bună ziua, am avut o problemă pe serverul meu dedicat, și anume că de fiecare dată când se apropie numărul de aproximativ 250 de persoane online, conform Google Analytics în timp real, serverul meu se prăbușește și conexiunea devine lentă până când cade conexiunea la site-ul web și nu încarcă niciodată mai mult decât acel număr de utilizatori online, dar când văd performanța serverului dedicat care este de 8 gb ram arată 10% din utilizare, cpu: 5% din utilizare și hard diskul în: 1.99 % util.
Ma poti ajuta? Nu găsesc ce să fac, realizarea acestor pași este soluția?
Bun Carlos.
Problema pe care o descrieți este foarte frecventă atunci când serverul nu este pregătit corespunzător. Serverul dvs. va accepta probabil un număr mult mai mic de conexiuni simultane și atunci când va ajunge la 250 de conexiuni se va bloca. Urmând manualul, ar trebui să puteți rezolva problema, deși dacă aveți o bază de date pe acel server, ar trebui să optimizați acea bază de date.
Salutări.
Drassill, am făcut configurația pe care ați menționat-o și a fost satisfăcătoare, ieri am ajuns la 280 de utilizatori online și serverul nu s-a prăbușit, sunt foarte mulțumit de acest rezultat și vreau să fac și celălalt lucru pe care mi-l spuneți pentru a optimiza baza de date, ¿ Cum pot realiza acest lucru?
Conceptul bazei de date este destul de deschis; utilizarea mysql nu este la fel ca postgres (de exemplu). Evident, nu cunosc toate bazele de date; Am încercat mysql și postgres, iar creșterea conexiunilor simultane în acestea s-ar baza pe parametrul max conexiuni; optimizarea mysql se va face în /etc/my.conf și parametrul maxim conexiuni ar trebui modificat (printre altele). În schimb, pentru postgres, am un articol pe blogul meu care explică cum să-l optimizez, care vă poate fi util sau pe care îl puteți folosi ca referință pentru baza de date:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Salutări.
Bună, când arunc prima comandă, îmi arată valoarea 0. Ce ar putea fi?
Mulțumesc pentru această postare.
Ce manual bun, aceste informații fac parte din ceea ce caut... mulțumesc!
Dar acum, dacă vreau ca atunci când acei 250 de vizitatori sunt depășiți, vizitatorul 251 să meargă la o pagină de așteptare sau la o coadă virtuală, pot să o fac din aceeași configurație?
Salutări și mulțumiri!