Danas dolazim s vama još jednom razgovarati o jednoj od najčešće korištenih web usluga na svijetu: Web serveru Apache2.
To je tema o kojoj se razgovaralo mnogo puta, ali sada vam dolazim reći o još jednoj osobini koju treba uzeti u obzir kod ove usluge: Granica istovremenih veza. Nije bitno imamo li vrlo osnovni ili svemirski brod s i7 procesorom i 32 GB RAM-a ...
Ograničenje istovremenih veza uvijek će biti isto ukoliko ne poduzmemo odgovarajuće mjere, što znači da će nam, ako želimo istovremeno povezati mnogo ljudi, biti potreban ne samo dobar hardver, već i dobra konfiguracija.
U ovom slučaju nije potrebno ništa instalirati, sve se temelji na jednostavnim konceptima koji se moraju uzeti u obzir za konfiguriranje apachea; koncepti koji moraju biti vrlo jasni prije nego što se žele napraviti bilo kakve promjene.
Prvo o čemu treba razmisliti je: Koji kapacitet ima moj tim? Koliko simultanih veza može podržati moja oprema ako je prisilim što je više moguće? Sve ovo ovisi o jednom faktoru; RAM (Random Access Memory).
Što je veća RAM memorija, to je veći broj veza, iako nema fiksne vrijednosti (odnosno X klijenata za svaki X ram), zato je prije svega važno napraviti neke male proračune na našem web serveru, s da bismo znali naše granice.
Prvo što biste trebali znati je koliko RAM-a u prosjeku troši svaka veza s Apacheom, jer svaka uspostavljena veza pretpostavlja određenu potrošnju RAM-a u sistemu ... Očito nisu sve veze koje troše isti RAM, s kojim bi se moralo uspostaviti medij ... Sve se to može dobiti pomoću sljedeće naredbe:
ps -ylC apache2 --sort: rss | awk '{SUM + = 8 USD; I + = 1} KRAJ {ispis SUM / I / 1024} '
Dobiveni rezultat bio bi predstavljen u megabajtima i mogao bi varirati ovisno o broju aktivnih veza, vrsti stranica kojima se pristupa itd. ... Stoga je poželjno provesti test s otvorenim različitim karticama; ako je moguće, svaki od njih prikazuje različite sadržaje. U mom slučaju, na primjer, rezultat je bio 9.5458, što bi bilo ako bismo ga zaokružili na vrh 10 MB RAM se troši u prosjeku po vezi.
Također je važno znati koliko RAM-a troši ostatak procesa koji su aktivni u sustavu, jer web usluga nije jedina koja se pokreće u operativnom sistemu i potrebno je ostaviti besplatnu RAM memoriju na serveru tako da može izvršiti ostale zadatke. To se može dobiti naredbom prikazanom dolje:
ps -N -ylC apache2 --sort: rss | awk '{SUM + = 8 USD} END {print SUM / 1024}'
Dobiveni rezultat također bi bio predstavljen u megabajtima i pokazao bi nam prilično precizno količinu RAM-a koju su potrošili ostatak procesa; u mom slučaju 800 MB. Pomoću ovih podataka mogli bismo izvršiti opći proračun broja istovremenih veza koje bismo mogli imati; Računam da bismo to dobili vrlo jednostavnom operacijom.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
S ovom formulom u ruci, zamislimo da imamo računalo sa 4 GB RAM-a, odnosno 4096 MB i da je naše računalo pokazalo gore navedene rezultate; izračun bi bio:
(4096 - 800) / 10 = 329 istovremenih veza
Problem s ovim proračunom je taj što je jedan previše ekstreman, jer bi potrošio svu RAM memoriju (što poslužitelju zamjenjuje zamjenu), a također bi, u slučaju postojanja baze podataka, kao što je MySQL ili bilo koja druga, veze s njom također trošile RAM, s kojim bi se dobiveni broj mogao kvalificirati kao utopijski broj. Stoga bismo, kako bismo oslobodili memoriju za moguće dodatne procese i uzeli u obzir mogućnost izvođenja veza na bazu podataka, smanjili broj veza na 250.
Sada kada imamo maksimalan broj istovremenih veza, morali bismo pripremiti Apache za primanje ovog broja, što je učinjeno u konfiguracijskoj datoteci ovog poziva apache2.conf, koji je domaćin u / etc / apache2.
Dotična datoteka slijedi strukturu zasnovanu na modula, svaki sa svojim odgovarajućim imenom, ali nas bi zanimao samo jedan od njih, čije je ime mpm_prefork_module. Predmetni modul ima sljedeće podatke prema zadanim postavkama:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Ovaj modul ima niz vrlo važnih parametara, iako postoji jedan od njih koji bi nas posebno zanimao, tzv MaxClients. Ovaj parametar određuje maksimalan broj istovremenih veza i treba ga izmijeniti u 250.
Jedan detalj koji treba uzeti u obzir je da kada je u navedenom parametru navedena vrijednost koja nije zadana, potrebno je dodati još jednu samo PRIJE ove. Ovaj parametar se zove ServerLimit i postavlja ograničenje veza koje bi poslužitelj mogao "držati" čak i kada je izvan ograničenja.
Parametar ServerLimit uvijek mora biti malo viši od MaxClients-a i ovdje, budući da ima malo manevarskog prostora, ograničenje 270. Ovo bi modul izgledalo ovako:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Sada bi bilo potrebno samo ponovo pokrenuti uslugu Apache pomoću naredbe:
/etc/init.d/apache2 ponovno pokrenite
Sa ovim bismo već mogli uživati u našem optimizovanom web serveru.
Pozdrav.
Hvala na postu!
Drago mi je što vam je bilo korisno.
Pozdrav.
Postoji način grupiranja sa Apacheom i dva servera, možete li objasniti kako to funkcionira?
Iako sam pročitao neku teoriju o tome, nikada je nisam primijenio u praksi. Unatoč tome, možda vam ovaj članak može dati neke smjernice u tom pogledu, iako ponavljam da to nisam imao priliku primijeniti u praksi:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
tražili ste neko vrijeme, ako niste riješili; Imam shemu balansiranja s trećom stranom koja djeluje kao sistem datoteka, mape koje su u var / www / html / (u mom slučaju) usmjerite na sistem datoteka, tako da dijele iste informacije, a vi ćete možda potreban vam je virtualni ip koji odgovara i preusmjerava na ips apache-a, za to možete zauzeti haproxy, a ako ga želite u velikoj dostupnosti, možete integrirati keepalive u slučaju da jedan padne, drugi nastavi odgovarati ili također ako već imate domenu za aplikaciju, možete balansirati s funtom radeći pozadinske podatke na oba servera, za specifične slučajeve kao što su moodle ili određene aplikacije koje se povezuju s bazom podataka u mysqlu, trebali biste stvoriti korisnika po serveru aplikacije koji upućuje na istu bazu podataka .
Puno vam hvala na postu, potpuno ste u pravu, ram je primarni proračun, iako pretpostavljam da izračunavamo i maksimalan broj procesa koje naš procesor može obraditi (naravno, prvo izvrši proračun glavne memorije) i kako bi se disk teško distribuirao (Primjer particija / var = 1TR).
Upravu si; sve je važno, poput kontrole temperature, između ostalog. Očito je da moćni procesor može izvršavati veći broj zadataka istovremeno s velikom efikasnošću, ali cilj ovog posta bio je objasniti važnost RAM-a s obzirom na broj istovremenih veza.
Dobar način za kontrolu svih ovih čimbenika i provjeru nije li naš procesor zasićen ili imamo malo slobodne RAM memorije bio bi korištenje bash skripte. Ovaj post koji sam učinio prije nekoliko dana možda će vam biti zanimljiv i ostavljam vas na sljedećem linku; To je globalni monitoring, ali može biti zanimljiv za jednog:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
Saludos
Vrlo dobra napomena, puno hvala!
Hvala puno! Nadam se da ste to mogli iskoristiti.
Ne želim biti kreten ...
... Ali povećanjem broja veza ne ostavljate ranjivije na DDoS napad?
To nije tiho pitanje kretena. Istina je da povećanjem broja istovremenih veza djelomično ojačavamo Apache protiv DDOS napada, jer morate uzeti u obzir da je broj maksimalnih istovremenih veza uspostavljenih na serveru broj ukupnih maksimalnih veza, a ne onih koje dolaze iz jedan korisnik. Dakle, dok smo na početku mogli podržavati samo 150 istovremenih veza (bilo da se radi o vezama iz legitimnog izvora ili ne), sada možemo računati na onoliko koliko podržava naš server, zahtijevajući da veći broj veza istovremeno bude bez usluga. Očito je da povećanje maksimalnog broja veza nije način zaštite od ove vrste napada, već bi trebalo provoditi politike vatrozida. Ako će, na primjer, web usluga koju želite postaviti biti izložena internetu, sigurnosna mjera koja bi se mogla primijeniti bila bi dodavanje ovih redaka našem vatrozidu:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-up to 10 -m state –state NEW -j ACCEPT
iptables -A ULAZ -p tcp -port 80 -m stanje -država OSNOVANA, POVEZANA -j PRIHVAĆA
iptables -A ULAZ -p tcp -port 80 -j DROP
Jedna od karakteristika DDoS napada je da se napadaču može činiti da šalje pakete iz nekoliko različitih pravaca, što sprečava protok paketa da dolazi samo iz jednog smjera.
U pravu ste u smislu da vatrozid poput ovog koji sam ja postavio nije baš efikasan protiv DDOS napada, jer dolazi iz različitih izvora. Ipak, bolje je ograničiti broj veza na 10 za svaki od ovih izvora, umjesto da nemate ograničenje, tako da svaki izvor može uspostaviti stotinu veza ili više.
U svakom slučaju, komplet pitanja je da što više istovremenih veza poslužitelj podržava, to će ga biti teže srušiti DDOS napadom, što će otežati srušenje stranice od strane napadača .
Pozdrav.
Dobro. Za sada nastavljam s NGINX-om na svojoj web stranici kako ne bih mučio VPS koji imam.
Dobar post @Drassill!
Htio sam doprinijeti nečim možda više statističkim od konfiguracije.
Iako je najlakši i najbrži način izračunavanja parametra potrošnje sa srednjom vrijednosti, možda bismo mogli biti rigorozniji i umjesto "srednje vrijednosti" upotrijebiti "medijanu". Od čega bi nas to spasilo? Da se brojevi isključe u slučaju da je veza zauzela puno memorije. Na primjer, pretpostavimo da sljedeći klijenti troše sljedeće vrijednosti u jedinici memorije koju žele (KB, MB, MiB itd.):
10, 15, 150, 5, 7, 10, 11, 12
Prosjek bi dao otprilike ~ 30
I to zato što imamo vrlo veliki kraj (150), a kalkulacije su lude. Medijana se sastoji od redoslijeda ovih podataka, dijeljenja broja uzoraka sa 2 (naš centar) i dobivanja broja tog položaja. Sa ovim bismo imali nešto slično
5, 7, 10, 10, 11, 12, 15, 150
Dakle, naša srednja vrijednost bila bi: 8/2 = 4 što je ~ 10
Ovdje možete vidjeti da, koliko god ekstremni ludi bili, uvijek će nam dati realniju vrijednost. Ako dodamo kupca koji potroši 200, naša srednja vrijednost bit će 11, dok prosjek može ići na …….
To je samo doprinos i vrlo je diskutabilno, jer s vezama ne zajebava.
Zagrlite ljude linuxera 🙂
Pozdrav, imao sam problem na svom namjenskom serveru, a to je da svaki put kada se približi broj od približno 250 ljudi na mreži, prema Google analitici u stvarnom vremenu, moj server se sruši i veza postaje spora dok ne prekine vezu sa web stranicu i nikad ne učitava više od tog broja korisnika na mreži, ali kad vidim performanse namjenskog servera koji je 8 GB ram, to pokazuje 10% upotrebe, cpu: 5% upotrebe i tvrdog diska: 1.99% od koristiti.
Mozes li mi pomoci? Ne mogu pronaći što da radim, jesu li ovi koraci rješenje?
Dobar Carlos.
Problem koji opisujete vrlo je čest kada poslužitelj nije pravilno pripremljen. Vaš će poslužitelj vjerojatno prihvatiti mnogo manji broj istovremenih veza i kad dosegne 250 veza, srušit će se. Slijedeći priručnik trebali biste biti u mogućnosti riješiti problem, iako ako imate bazu podataka na tom poslužitelju, morali biste je i optimizirati.
Pozdrav.
Drassill, obavio sam konfiguraciju koju ste spomenuli i bila je zadovoljavajuća, jučer sam dosegao 280 korisnika na mreži i server se nije srušio, vrlo sam zadovoljan ovim rezultatom, a želim učiniti i drugu stvar koju mi kažete da optimiziram baza podataka, ¿Kako to postići?
Koncept baze podataka je prilično otvoren; upotreba mysqla nije isto što i postgres (na primjer). Očigledno da ne znam sve baze podataka; Isprobao sam mysql i postgres, a povećanje istovremenih veza u njima temeljilo bi se na parametru max veze; mysql optimizacija bi se izvršila u /etc/my.conf i parametar max konekcije morao bi se promijeniti (između ostalog). Umjesto toga, za postgres imam članak na svom blogu koji objašnjava kako ga optimizirati koji vam može biti koristan ili koji možete koristiti kao referencu za svoju bazu podataka:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Pozdrav.
Pozdrav, kada bacim prvu naredbu, prikazuje mi vrijednost 0. Šta bi to moglo biti?
Hvala vam na ovom postu.
Kako dobar priručnik, te informacije su dio onoga što tražim... hvala!
Ali sada, ako želim da kada tih 250 posjetitelja premaši, posjetitelj 251 ode na stranicu za čekanje ili virtualni red, mogu li to učiniti iz iste konfiguracije?
Pozdrav i hvala!