Ma még egyszer beszélek veled a világ egyik leggyakrabban használt webszolgáltatásáról: a webszerverről Apache2.
Ez egy olyan téma, amelyről már sokszor szó esett, de most eljutottam egy másik szolgáltatáshoz, amelyet figyelembe kell venni a szolgáltatással: Az egyidejű kapcsolatok határa. Nem számít, hogy van egy nagyon egyszerű vagy egy űrhajónk i7 processzorral és 32 GB RAM-mal ...
Az egyidejű kapcsolatok korlátja mindig ugyanaz lesz, hacsak nem teszünk megfelelő intézkedéseket, ami azt jelenti, hogy ha azt akarjuk, hogy egyszerre sok ember csatlakozzon, akkor nemcsak jó hardverre, hanem jó konfigurációra is szükségünk lesz.
Ebben az esetben nem szükséges semmit telepíteni, minden egyszerű koncepciókon alapul, amelyeket figyelembe kell venni az apache konfigurálásakor; olyan fogalmak, amelyeknek nagyon világosaknak kell lenniük, mielőtt bármilyen változtatást meg akarnak tenni.
Az első dolog, amin gondolkodni kell: Milyen kapacitással rendelkezik a csapatom? Hány egyidejű kapcsolatot tud támogatni a berendezésem, ha a lehető legnagyobb mértékben kényszerítem? Mindez egyetlen tényezőtől függ; RAM (Random Access Memory).
Minél nagyobb a RAM, annál nagyobb a kapcsolatok száma, bár nincs fix érték (vagyis X kliens minden X ram számára), ezért először is fontos néhány apró számítást végezni a webszerverünkön, a korlátok megismerése érdekében.
Az első dolog, amit tudnia kell, hogy átlagosan mennyi RAM-ot fogyaszt az Apache-hoz való minden egyes kapcsolat, mivel minden létrehozott kapcsolat feltételez bizonyos RAM-fogyasztást a rendszerben ... Nyilvánvaló, hogy nem minden kapcsolat fogyasztja ugyanazt a RAM-ot, amellyel létre kellene hozni média ... Mindezt a következő paranccsal lehet megszerezni:
ps -ylC apache2 --rendezés: rss | awk '{SUM + = 8 USD; I + = 1} VÉGE {SUM nyomtatása / I / 1024} "
A kapott eredmény megabájtban jelenik meg, és változhat az aktív kapcsolatok számától, az elérett oldalak típusától stb. Függően. Ezért tanácsos a tesztet különféle fülek nyitva végrehajtani; mindegyikük eltérő tartalmat mutat, ha lehetséges. Az én esetemben például 9.5458 lett az eredmény, ami ha felfelé kerekítenénk, az lenne 10 MB Csatlakozásonként átlagosan fogyasztott RAM.
Fontos tudni azt is, hogy mennyi RAM-ot emészt fel a rendszer többi aktív folyamata, mivel az operációs rendszerben nem csak a webszolgáltatás fut, és szabad RAM-ot kell hagyni a szerveren hogy a többi feladatot végrehajthassa. Ez az alábbi paranccsal érhető el:
ps -N -ylC apache2 --rendezés: rss | awk '{SUM + = $ 8} END {SUM nyomtatás / 1024}'
A kapott eredmény megabájtban is megjelenik, és pontosan megmutatja a többi folyamat által elfogyasztott RAM mennyiségét; esetemben 800 MB. Ezzel az információval általános számításokat végezhetnénk a lehetséges szimultán kapcsolatok számáról; Számításom szerint egy nagyon egyszerű művelettel kapnánk meg.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Ezzel a képlettel a kezünkben képzeljük el, hogy van egy számítógépünk 4 GB RAM-mal, azaz 4096 MB-mal, és hogy a számítógépünk megmutatta a fent említett eredményeket; a számítás a következő lenne:
(4096 - 800) / 10 = 329 egyidejű kapcsolat
A probléma ezzel a számítással az, hogy az egyik túlságosan szélsőséges, mivel az összes RAM-ot elfogyasztaná (a szervert fogyasztási csere elé téve), és ha van olyan adatbázisa, mint a MySQL vagy bármely más, akkor az ahhoz való kapcsolatok is felemésztenek RAM, amellyel a kapott szám utópikus számnak minősíthető. Ezért annak érdekében, hogy felszabadítsuk a memóriát az esetleges további folyamatok számára, és figyelembe vegyük annak lehetőségét is, hogy az adatbázishoz való kapcsolatok végrehajtódjanak, csökkentenénk 250.
Most, hogy elérjük a maximális számú egyidejű kapcsolatot, fel kell készítenünk az Apache-ot a szám fogadására, ami a hívás konfigurációs fájljában történik apache2.conf, amelynek házigazdája / etc / apache2.
A szóban forgó fájl a következőkre épülő struktúrát követi modulok, mindegyik a maga nevével, de minket csak az egyik érdekelne, akinek a neve mpm_prefork_module. A szóban forgó modul alapértelmezés szerint a következő adatokkal rendelkezik:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Ennek a modulnak nagyon fontos paraméterei vannak, bár van olyan, amely különösen érdekelne minket, az úgynevezett Maxclients. Ez a paraméter meghatározza az egyidejű kapcsolatok maximális számát, és módosítani kell a következőre: 250.
Az egyik figyelembe veendő részlet az, hogy ha az említett paraméterben az alapértelmezettől eltérő érték van megadva, akkor még ezt megelőzően hozzá kell adni még egy értéket. Ezt a paramétert hívjuk ServerLimit és meghatározza azoknak a kapcsolatoknak a határát, amelyeket a szerver akkor is "tarthat", ha túl van a határon.
A ServerLimit paraméternek mindig valamivel magasabbnak kell lennie, mint a MaxClients, és itt, mivel kevés mozgástér van, a 270. Ettől a modul így nézne ki:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Most csak az Apache szolgáltatást kell újraindítania a következő paranccsal:
/etc/init.d/apache2 újraindítás
Ezzel már élvezhettük optimalizált webszerverünket.
Üdvözlet.
22 hozzászólás, hagyd a tiedet
Köszönöm a bejegyzést!
Örülök, hogy hasznosnak találta.
Üdvözlet.
Van egy mód az Apache és két szerver klaszterezésére, meg tudnád magyarázni, hogyan működik?
Bár olvastam róla néhány elméletet, soha nem alkalmaztam a gyakorlatban. Ennek ellenére talán ez a cikk adhat némi útmutatást ebben a tekintetben, bár megismétlem, hogy nem volt alkalmam a gyakorlatba átültetni:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
kértél egy ideig, ha nem oldottad meg; Van egy kiegyenlítő sémám egy harmadik féllel, amely fájlrendszerként működik. Ön a var / www / html / (esetemben) mappákat a fájlrendszerre irányítja, így ugyanazok az információk vannak megosztva, és akkor valószínűleg szükség van egy virtuális ip-re, amely válaszol és átirányítja az apache-ok ips-jeit, ehhez elfoglalhat egy haproxiát, és ha nagy rendelkezésre állás esetén szeretné, akkor integrálhatja a keepalive-ot arra az esetre, ha az egyik elesik, a másik tovább reagálna, vagy ha már az alkalmazás tartománya, akkor egyensúlyozhat a fontok háttér-visszafejtésével mindkét kiszolgálón. Különleges esetekben, például a moodle vagy bizonyos alkalmazások esetén, amelyek a mysql-ben csatlakoznak egy adatbázishoz, alkalmazáskiszolgálónként létre kell hoznia egy felhasználót, amely ugyanarra az adatbázisra mutat .
Köszönöm szépen a bejegyzést, teljesen igazad van, a ram az elsődleges számítás, bár úgy képzelem, hogy kiszámoljuk a processzorok által kezelhető folyamatok maximális számát is (természetesen először a fő memória kiszámítását végezzük el) és a lemez merev elosztása (példa partíciók / var = 1TR).
Igazad van; minden fontos, mint például a hőmérséklet-szabályozás. Nyilvánvaló, hogy egy nagy teljesítményű processzor nagyobb számú feladatot képes egyszerre, nagy hatékonysággal végrehajtani, de ennek a bejegyzésnek az volt a célja, hogy elmagyarázza a RAM jelentőségét az egyidejű kapcsolatok számához képest.
A bash szkript használatával jó módja annak, hogy ellenőrizzük ezeket a tényezőket, és megnézzük, hogy a processzorunk nem telített-e, vagy kevés a szabad memóriánk. Érdekesnek találhatja ezt a néhány nappal ezelőtti bejegyzést, amelyet a következő linken hagyok; Globális megfigyelés, de érdekes lehet az egyik számára:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
Üdvözlet
Nagyon jó megjegyzés, köszönöm szépen!
Nagyon köszönöm! Remélem, hogy ki tudta használni.
Nem akarok bunkó lenni ...
... De ha növeli a kapcsolatok számát, akkor nem hagy kiszolgáltatottabbá a DDoS támadással szemben?
Nem csendes kretén kérdés. Az igazság az, hogy az egyidejű kapcsolatok számának növelésével részben megerősítjük az Apache-ot a DDOS-támadásokkal szemben, mivel figyelembe kell venni, hogy a szerveren létrehozott maximális egyidejű kapcsolatok száma a teljes maximális kapcsolat száma, nem pedig a egyetlen felhasználó. Így míg az elején csak 150 egyidejű kapcsolatot tudtunk támogatni (függetlenül attól, hogy azok legitim forrásból származnak-e vagy sem), most annyi számíthatunk, amennyire a szerverünk támogatja, ugyanakkor nagyobb számú kapcsolatra van szükség egyszerre. szolgáltatás. Nyilvánvaló, hogy a kapcsolatok maximális számának növelése nem jelent védelmet az ilyen típusú támadások ellen, hanem inkább tűzfal irányelveket kell végrehajtani. Ha például a telepíteni kívánt webszolgáltatás az internetnek lesz kitéve, egy megvalósítható biztonsági intézkedés a következő sorok hozzáadása a tűzfalunkhoz:
iptables -A BEMENET -p tcp –syn –port 80 -m connlimit –connlimit-up -10 -m állapot – state ÚJ -j ACCEPT
iptables -A BEMENET -p tcp –port 80 -m állapot –állapot LÉTREHOZOTT, KAPCSOLÓDÓ -j ACCEPT
iptables -A BEMENET -p tcp –port 80 -j DROP
A DDoS támadások egyik jellemzője, hogy a támadó többféle irányból küldhet csomagokat, ami megakadályozza, hogy a csomagok áramlása csak egy irányból érkezzen.
Abban az értelemben igazad van, hogy az általam beállított tűzfal nem túl hatékony egy DDOS támadással szemben, mivel különböző forrásokból származik. Mégis jobb, ha ezeknek a forrásoknak a száma 10-re korlátozódik, ahelyett, hogy lenne korlátja, hogy minden forrás száz vagy több kapcsolatot tudjon létrehozni.
Mindenesetre a kérdés készlete az, hogy minél több egyidejű kapcsolatot támogat a szerver, annál nehezebb lesz lebontani egy DDOS-támadással, ami megnehezítené az oldal leütését egy támadó által .
Üdvözlet.
Jó. Egyelőre az NGINX-szel folytatom az oldalamon, hogy ne kínozzam a nálam lévő VPS-t.
Jó post @Drassill!
Szerettem volna valamivel talán statisztikásabb, mint konfigurációval hozzájárulni.
Bár a fogyasztási paraméter kiszámításának legegyszerűbb és leggyorsabb módja az átlag, talán szigorúbbak lehetnénk, és az „átlag” helyett a „mediánt” használnánk. Mitől mentene meg minket? Hogy a számok kialudnak, ha egy kapcsolat sok memóriát emészt fel. Tegyük fel például, hogy a következő ügyfelek a következő értékeket fogyasztják a kívánt memóriaegységben (KB, MB, MiB stb.):
10, 15, 150, 5, 7, 10, 11, 12
Az átlag kb. 30-at adna
És ez azért van, mert nagyon nagy a végünk (150), és a számítások őrültek. A medián abból áll, hogy megrendeljük ezeket az adatokat, elosztjuk a minták számát 2-vel (középpontunk), majd megszerezzük az adott pozíció számát. Ezzel lenne valami hasonló
5., 7., 10., 10., 11., 12., 15., 150
Tehát az átlagunk a következő lenne: 8/2 = 4, azaz ~ 10
Itt láthatja, hogy bármennyire is őrült a szélsőség, ez mindig reálisabb értéket ad számunkra. Ha hozzáadunk egy olyan ügyfelet, aki 200-at fogyaszt, akkor a mediánunk 11 lesz, míg az átlag…
Ez csak egy hozzájárulás, és nagyon vitatható, mert a csatlakozásokkal nincs csavarozva.
Ölelj embereket linuxera 🙂
Helló, problémám volt a dedikált szerveremen, és ez az, hogy valahányszor megközelíti a körülbelül 250 online ember száma, a Google Analytics valós idejű adatai szerint a szerverem összeomlik, és a kapcsolat lassúvá válik, amíg meg nem szakítja a kapcsolatot a a webhelyet, és soha nem tölt fel többet annál a felhasználóknál, de amikor látom a dedikált szerver teljesítményét, amely 8 GB RAM, akkor a használat 10% -át, a cpu-t: a használat 5% -át és a merevlemezt: a használat.
Tudsz segíteni nekem? Nem találok mit tegyek, ezek a lépések megteszik a megoldást?
Jó Carlos.
Az általad leírt probléma nagyon gyakori, ha a szerver nincs megfelelően felkészülve. A kiszolgáló valószínűleg sokkal kisebb számú egyidejű kapcsolatot fog elfogadni, és amikor eléri a 250 kapcsolatot, összeomlik. A kézikönyv követésével képesnek kell lennie a probléma megoldására, bár ha van adatbázisa a szerveren, akkor azt is optimalizálnia kell.
Üdvözlet.
Drassill, elvégeztem az Ön által említett konfigurációt, és kielégítő volt, tegnap 280 felhasználót értem el az interneten, és a szerver nem zuhant össze, nagyon örülök ennek az eredménynek, és szeretném megcsinálni a másik dolgot is, amit optimalizáláshoz mond az adatbázis, ¿Hogyan érhetem el ezt?
Az adatbázis fogalma meglehetősen nyitott; a mysql használata nem ugyanaz, mint a postgres (például). Nyilvánvalóan nem ismerem az összes adatbázist; Kipróbáltam a mysql-t és a postgres-t, és ezekben az egyidejű kapcsolatok növekedése a max kapcsolatok paraméteren alapulna; A mysql optimalizálása az /etc/my.conf fájlban történik, és meg kell változtatni a max kapcsolók paraméterét (többek között). A postgres-ek helyett a blogomban van egy cikk, amely elmagyarázza az optimalizálást, amely hasznos lehet az Ön számára, vagy amelyet referenciaként használhat az adatbázisához:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Üdvözlet.
Helló, amikor eldobom az első parancsot, az 0. értéket mutat. Mi lehet ez?
Köszönöm ezt a bejegyzést.
Milyen jó kézikönyv, ez az információ része annak, amit keresek... köszönöm!
De most, ha azt akarom, hogy a 250 látogató túllépése után a 251. látogató egy váróoldalra vagy virtuális sorba kerüljön, megtehetem-e ugyanezt a konfigurációt?
Üdvözlet és köszönet!