Danas dolazim s vama još jednom razgovarati o jednoj od najčešće korištenih web usluga na svijetu: Web poslužitelju Apache2.
To je tema o kojoj se već puno puta govorilo, ali sada vam dolazim reći o još jednoj značajci koju treba uzeti u obzir s ovom uslugom: Granica istodobnih veza. Nije važno imamo li vrlo osnovni ili svemirski brod s i7 procesorom i 32 GB RAM-a ...
Ograničenje istodobnih veza uvijek će biti isto ukoliko ne poduzmemo odgovarajuće mjere, što znači da ako želimo istovremeno povezati više ljudi, neće nam trebati 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 neke 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 to ovisi o jednom faktoru; RAM (Random Access Memory).
Što je veći RAM, 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 izračune na našem web poslužitelju, s da bismo znali svoje 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 sustavu ... Očito nisu sve veze koje troše isti ram, s kojim bi se trebalo uspostaviti medij ... Sve se to može dobiti pomoću sljedeće naredbe:
ps -ylC apache2 --sort: rss | awk '{SUM + = 8 USD; I + = 1} END {print SUM / I / 1024} '
Dobiveni rezultat predstavit će se u megabajtima i može se razlikovati ovisno o broju aktivnih veza, vrsti stranica kojima se pristupa itd. Iz tog razloga preporučljivo je provesti test s otvorenim različitim karticama; svaki od njih po mogućnosti prikazuje drugačiji sadržaj. U mom slučaju, na primjer, rezultat je bio 9.5458, što bi bilo ako ga zaokružimo 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 operacijskom sustavu i potrebno je na računalu ostaviti slobodnu RAM memoriju poslužitelju kako bi mogao izvršiti ostatak zadataka. 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 napraviti opći izračun broja istodobnih 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 s 4 GB RAM-a, odnosno 4096 MB i da je naše računalo pokazalo gore spomenute rezultate; izračun bi bio:
(4096 - 800) / 10 = 329 simultanih veza
Problem s ovim izračunom je taj što je jedan previše ekstreman, jer bi potrošio sav RAM (što poslužitelju zamjenjuje zamjenu), a također bi, u slučaju postojanja baze podataka, poput MySQL ili bilo koje druge, veze s njom također trebale RAM-a, tako da bi se dobiveni broj mogao kvalificirati kao utopijski broj. Stoga bismo, kako bismo oslobodili memoriju za moguće dodatne procese i također razmotrili mogućnost pokretanja veza s bazom podataka, smanjili bismo broj veza na 250.
Sada kada imamo maksimalan broj istodobnih 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 koja se temelji na moduli, svaki sa svojim odgovarajućim imenom, ali zanimao bi nas samo jedan od njih, čije je ime mpm_prefork_modul. 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 istodobnih 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. Taj se parametar naziva 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 MaxClientsa, a ovdje, budući da je malo manevarskog prostora, ograničenje 270. Zbog toga bi modul izgledao ovako:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Sada bi bilo potrebno ponovno pokrenuti uslugu Apache pomoću naredbe:
/etc/init.d/apache2 ponovno pokretanje
S ovim bismo već mogli uživati u našem optimiziranom web poslužitelju.
Pozdrav.
Hvala na postu!
Drago mi je da vam je bilo korisno.
Pozdrav.
Postoji način grupiranja s Apacheom i dva poslužitelja, možete li objasniti kako to radi?
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/
Dugo ste tražili, ako niste riješili; Imam shemu uravnoteženja s trećom stranom koja djeluje kao datotečni sustav, a mape koje su u var / www / html / (u mom slučaju) usmjerite na datotečni sustav, tako da dijele iste podatke, a možda ćete i vi potreban vam je virtualni ip koji odgovara i preusmjerava na ipove apachea, 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 reagirati ili također ako već imate domenu za aplikaciju, možete balansirati s funtama radeći backende na oba poslužitelja, 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 poslužitelju aplikacije koji upućuje na istu bazu podataka .
Puno vam hvala na postu, potpuno ste u pravu, ram je primarni izračun, iako pretpostavljam da izračunavamo i maksimalan broj procesa s kojima naš procesor može rukovati (naravno, prvo izvrši izračun glavne memorije) i kako bi se disk teško distribuirao (Primjer particija / var = 1TR).
U pravu si; sve je važno, poput kontrole temperature između ostalog. Očito snažni procesor može istodobno s velikom učinkovitošću izvoditi veći broj zadataka, ali cilj ovog posta bio je objasniti važnost RAM-a s obzirom na broj istodobnih veza.
Dobar način za kontrolu svih ovih čimbenika i provjeru nije li naš procesor zasićen ili imamo malo slobodnog RAM-a bio bi korištenje bash skripte. Možda će vam biti zanimljiv ovaj post koji sam o njemu objavio prije nekoliko dana, a koji vam ostavljam na sljedećem linku; To je globalno praćenje, ali nekome može biti zanimljivo:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
pozdravi
Vrlo dobra napomena, puno hvala!
Hvala puno! Nadam se da ste to uspjeli iskoristiti.
Ne želim biti kreten ...
... Ali povećanjem broja veza ne ostavljate ranjivije na DDoS napad?
To nije tiho kretensko pitanje. Istina je da povećanjem broja istodobnih veza djelomično učvršćujemo Apache protiv DDOS napada, jer morate uzeti u obzir da je broj maksimalnih istodobnih veza uspostavljenih na poslužitelju broj ukupnih maksimalnih veza, a ne onih koje dolaze iz jedan korisnik. Dakle, dok smo na početku mogli podržavati samo 150 istodobnih veza (bilo da se radi o vezama iz legitimnog izvora ili ne), sada možemo računati na onoliko koliko podržava naš poslužitelj, što zahtijeva veći broj veza u isto vrijeme bez servis. 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 staviti biti izložena internetu, sigurnosna mjera koja bi se mogla primijeniti bilo 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 –dport 80 -j DROP
Jedna od karakteristika DDoS napada je da se napadaču može činiti da šalje pakete iz nekoliko različitih smjerova, što sprječava protok paketa iz samo jednog smjera.
U pravu ste u smislu da vatrozid poput ovog koji sam postavio nije vrlo učinkovit 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 simultanih veza poslužitelj podržava, to će ga biti teže srušiti DDOS napadom, što bi otežalo napadanje stranice na 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čuna parametra potrošnje sa srednjom vrijednosti, možda bismo mogli biti rigorozniji i umjesto "srednje vrijednosti" upotrijebiti "medijan". Što bi nas spasilo? Da se brojevi pojačaju u slučaju da je veza oduzela puno memorije. Na primjer, pretpostavimo da sljedeći klijenti koji 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 velik kraj (150), a kalkulacije su lude. Medijana se sastoji od redoslijeda tih podataka, dijeljenja broja uzoraka s 2 (naše središte) i dobivanja broja tog položaja. S ovim bismo imali nešto poput
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, medijan će nam biti 11, dok prosjek može ići na …….
To je samo doprinos i vrlo je diskutabilno, jer s vezama nije zajebano.
Zagrlite ljude linuxera 🙂
Pozdrav, imao sam problem na svom namjenskom poslužitelju, a to je da mi se svaki put kada se približi broj od približno 250 ljudi na mreži, prema Googleovoj analitici u stvarnom vremenu, moj poslužitelj sruši i veza postane spora dok ne prekine vezu na web stranicu i nikad ne prebacuje više od tog broja korisnika na mreži, ali kad vidim izvedbu namjenskog poslužitelja koji radi na 8 GB RAM-a, to pokazuje 10% upotrebe, CPU: 5% upotrebe i tvrdog diska: 1.99% korištenja.
Možeš li mi pomoći? Ne mogu pronaći što učiniti, jesu li ovi koraci rješenje?
Dobri Carlos.
Problem koji opisujete vrlo je čest kada poslužitelj nije pravilno pripremljen. Vaš će poslužitelj vjerojatno prihvatiti mnogo manji broj istodobnih veza i kad dosegne 250 veza, srušit će se. Slijedeći upute trebali biste biti u mogućnosti riješiti problem, iako ako imate bazu podataka na tom poslužitelju, morat ćete je i optimizirati.
Pozdrav.
Drassill, obavio sam konfiguraciju koju ste spomenuli i bila je zadovoljavajuća, jučer sam dosegnuo 280 korisnika na mreži i poslužitelj se nije objesio, vrlo sam zadovoljan ovim rezultatom, a želim učiniti i drugu stvar koju mi kažete za optimizaciju baza podataka, ¿Kako to postići?
Koncept baze podataka prilično je otvoren; korištenje mysqla nije isto što i postgres (na primjer). Očito 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 izvršila bi se u /etc/my.conf, a parametar max connections trebao bi se promijeniti (između ostalog). Umjesto toga, za postgres na svom blogu imam članak koji objašnjava kako ga optimizirati koji vam može biti koristan ili ga možete koristiti kao referencu za svoju bazu podataka:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Pozdrav.
Pozdrav, kad bacim prvu naredbu, prikazuje mi vrijednost 0. Što bi to moglo biti?
Hvala vam na ovom postu.
Kako dobar priručnik, te su informacije dio onoga što tražim... hvala!
Ali sada, ako želim da kada se premaši tih 250 posjetitelja, posjetitelj 251 ode na stranicu čekanja ili virtualni red čekanja, mogu li to učiniti iz ove iste konfiguracije?
Pozdrav i hvala!