Vandaag kom ik nog een keer met je praten over een van de meest gebruikte webservices ter wereld: de webserver Apache2.
Het is een onderwerp waar al vaak over is gesproken, maar nu kom ik je vertellen over een andere functie waarmee je rekening moet houden bij deze service: De limiet van gelijktijdige verbindingen. Het maakt niet uit of we heel basic hebben of een ruimteschip met een i7 processor en 32 GB werkgeheugen ...
De limiet van gelijktijdige verbindingen zal altijd hetzelfde zijn, tenzij we de juiste maatregelen nemen, wat betekent dat als we veel mensen tegelijkertijd aangesloten willen hebben, we niet alleen goede hardware nodig hebben, maar ook een goede configuratie.
In dit geval is het niet nodig om iets te installeren, alles is gebaseerd op eenvoudige concepten waarmee rekening moet worden gehouden om apache te configureren; concepten die heel duidelijk moeten zijn voordat u wijzigingen wilt aanbrengen.
Het eerste waar u aan moet denken is: welke capaciteit heeft mijn team? Hoeveel gelijktijdige verbindingen kan mijn apparatuur ondersteunen als ik het zo veel mogelijk forceer? Dit alles hangt af van een enkele factor; RAM (Random Access Memory).
Hoe groter het RAM-geheugen, hoe groter het aantal verbindingen, hoewel er geen vaste waarde is (dat wil zeggen, X-clients voor elke X-ram), daarom is het allereerst belangrijk om wat kleine berekeningen uit te voeren op onze webserver, met de om onze grenzen te kennen.
Het eerste dat u moet weten, is hoeveel RAM gemiddeld elke verbinding met Apache verbruikt, aangezien elke tot stand gebrachte verbinding een bepaald RAM-verbruik in het systeem veronderstelt ... Het is duidelijk dat niet alle verbindingen dezelfde ram verbruiken, waarmee men een media ... Dit alles kan worden verkregen met het volgende commando:
ps -ylC apache2 --sort: rss | awk '{SUM + = $ 8; I + = 1} END {print SUM / I / 1024} '
Het verkregen resultaat wordt weergegeven in megabytes en kan variëren afhankelijk van het aantal actieve verbindingen, het type pagina's dat wordt geopend, enz. Daarom is het raadzaam om de test uit te voeren met verschillende geopende tabbladen; elk van hen toont indien mogelijk verschillende inhoud. In mijn geval was het resultaat bijvoorbeeld 9.5458, wat als we het naar boven zouden afronden, zou zijn 10 MB RAM verbruikt gemiddeld per verbinding.
Het is ook belangrijk om te weten hoeveel RAM wordt verbruikt door de rest van de processen die actief zijn in het systeem, aangezien de webservice niet de enige is die in het besturingssysteem wordt uitgevoerd en het noodzakelijk is om RAM-geheugen vrij te laten op de server zodat deze kan worden uitgevoerd de rest van de taken. Dit kan worden verkregen met het onderstaande commando:
ps -N -ylC apache2 - sorteren: rss | awk '{SUM + = $ 8} END {print SUM / 1024}'
Het verkregen resultaat zou ook worden weergegeven in megabytes, en het zou ons heel precies de hoeveelheid RAM laten zien die door de rest van de processen wordt verbruikt; in mijn geval 800 MB. Met deze informatie konden we een algemene berekening maken van het aantal gelijktijdige verbindingen dat we zouden kunnen hebben; Ik bereken dat we zouden verkrijgen door middel van een heel eenvoudige operatie.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Laten we met deze formule in de hand stellen dat we een computer hebben met 4 GB RAM, dat wil zeggen 4096 MB en dat onze computer de bovengenoemde resultaten heeft laten zien; de berekening zou zijn:
(4096 - 800) / 10 = 329 gelijktijdige verbindingen
Het probleem met deze berekening is dat deze te extreem is, omdat het alle RAM zou verbruiken (waardoor de server swap verbruikt) en ook, in het geval van een database, zoals MySQL of een andere, zouden de verbindingen ermee ook RAM verbruiken , dus het verkregen nummer kan worden gekwalificeerd als een utopisch nummer. Om geheugen vrij te maken voor mogelijke aanvullende processen en ook om de mogelijkheid te overwegen om verbindingen met een database uit te voeren, zouden we het aantal verbindingen met 250.
Nu we ons maximale aantal gelijktijdige verbindingen hebben, zouden we Apache moeten voorbereiden om dit nummer te kunnen ontvangen, wat wordt gedaan in het configuratiebestand van deze oproep apache2.conf, die wordt gehost in / etc / apache2.
Het betreffende bestand volgt een structuur op basis van modules, elk met zijn bijbehorende naam, maar we zouden alleen geïnteresseerd zijn in een van hen, wiens naam is mpm_prefork_module. De betreffende module heeft standaard de volgende gegevens:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Deze module heeft een reeks zeer belangrijke parameters, hoewel er een is die ons bijzonder zou interesseren, genaamd maxClients. Deze parameter specificeert het maximale aantal gelijktijdige verbindingen en moet worden gewijzigd in 250.
Een detail waarmee rekening moet worden gehouden, is dat wanneer een andere waarde dan de standaardwaarde in de genoemde parameter wordt gespecificeerd, het nodig is om er nog een toe te voegen net VOOR deze. Deze parameter wordt genoemd ServerLimit en stelt de limiet van verbindingen in die de server zou kunnen "vasthouden", zelfs als deze buiten de limiet valt.
De parameter ServerLimit moet altijd iets hoger zijn dan MaxClients en hier, omdat er weinig manoeuvreerruimte is, een limiet van 270. Dit zou de module er als volgt uit laten zien:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Nu zou het alleen nodig zijn om de Apache-service opnieuw te starten met de volgende opdracht:
/etc/init.d/apache2 opnieuw opstarten
Hiermee konden we al genieten van onze geoptimaliseerde webserver.
Groeten.
Bedankt voor de post!
Ik ben blij dat je het nuttig vond.
Groeten.
Er is een manier om Apache en twee servers te clusteren, kun je uitleggen hoe het werkt?
Hoewel ik er enige theorie over heb gelezen, heb ik die nooit in de praktijk toegepast. Toch kan dit artikel je in dit verband misschien wat houvast geven, hoewel ik herhaal dat ik niet de gelegenheid heb gehad om het in praktijk te brengen:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
Je hebt lang gevraagd, als je het niet hebt opgelost; Ik heb een evenwichtsschema met een derde partij die als een bestandssysteem fungeert, je wijst de mappen in var / www / html / (in mijn geval) naar het bestandssysteem, zodat ze dezelfde informatie delen, en je hebt mogelijk een virtueel ip nodig dat reageert en omleiden naar de ips van de apaches, hiervoor kun je een haproxy bezetten en als je het in hoge beschikbaarheid wilt, kun je keepalive integreren voor het geval de ene valt, de andere blijft reageren, of als je al een domein voor de applicatie hebt, kun je balanceren met pond het doen van backends naar beide servers, voor specifieke gevallen zoals moodle of bepaalde applicaties die verbinding maken met een database in mysql, zou je een gebruiker per app-server moeten aanmaken die naar dezelfde database verwijst.
Heel erg bedankt voor de post, je hebt helemaal gelijk, de ram is de primaire berekening, hoewel ik me voorstel dat we ook het maximale aantal processen berekenen dat onze processor aankan (natuurlijk eerst de berekening van het hoofdgeheugen) en hoe de schijf zou worden verdeeld hard (Voorbeeld partities / var = 1TR).
Je hebt gelijk; alles is belangrijk, zoals onder andere temperatuurregeling. Het is duidelijk dat een krachtige processor een groter aantal taken tegelijkertijd met grote efficiëntie kan uitvoeren, maar het doel van dit bericht was om het belang van RAM uit te leggen met betrekking tot het aantal gelijktijdige verbindingen.
Een goede manier om al deze factoren onder controle te houden en te zien of onze processor niet verzadigd is of dat we weinig vrij RAM hebben, is door een bash-script te gebruiken. Misschien is dit bericht dat ik er een paar dagen geleden over heb gemaakt interessant voor je, wat ik achterlaat in de volgende link; Het is een globale monitoring, maar het kan interessant zijn voor iemand:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
groeten
Zeer goede opmerking, heel erg bedankt!
Heel erg bedankt! Ik hoop dat je er gebruik van hebt kunnen maken.
Ik wil geen eikel zijn ...
… Maar door het aantal verbindingen te verhogen, laat je je niet kwetsbaarder voor een DDoS-aanval?
Het is geen stille cretin-vraag. De waarheid is dat door het aantal gelijktijdige verbindingen te vergroten, we Apache gedeeltelijk versterken tegen DDOS-aanvallen, aangezien u in gedachten moet houden dat het aantal maximale gelijktijdige verbindingen dat op de server tot stand wordt gebracht, het aantal totale maximale verbindingen is, niet die afkomstig van een enkele gebruiker. Dus terwijl we in het begin slechts 150 gelijktijdige verbindingen konden ondersteunen (of het nu verbindingen zijn van een legitieme bron of niet), kunnen we nu rekenen op zoveel als onze server ondersteunt, waardoor een groter aantal verbindingen tegelijkertijd nodig is om zonder service te zijn. Het is duidelijk dat het verhogen van het maximale aantal verbindingen geen manier is om uzelf tegen dit soort aanvallen te beschermen, maar u zou eerder een firewallbeleid moeten implementeren. Als bijvoorbeeld de webservice die u wilt plaatsen, wordt blootgesteld aan internet, kan een beveiligingsmaatregel worden geïmplementeerd door de volgende regels aan onze firewall toe te voegen:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-tot 10 -m state –state NIEUW -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -m state –state GEVESTIGD, GERELATEERD -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j DROP
Een van de kenmerken van DDoS-aanvallen is dat het lijkt alsof een aanvaller pakketten vanuit verschillende richtingen verzendt, waardoor de stroom pakketten niet uit één richting komt.
Je hebt gelijk in de zin dat een firewall zoals die ik heb opgezet niet erg efficiënt is tegen een DDOS-aanval, omdat deze uit verschillende bronnen komt. Toch is het beter om het aantal verbindingen te beperken tot 10 voor elk van deze bronnen in plaats van geen limiet te hebben, zodat elke bron honderd verbindingen of meer kan maken.
De kit van de vraag is in ieder geval dat hoe meer gelijktijdige verbindingen de server ondersteunt, hoe moeilijker het zal zijn om hem omver te werpen met een DDOS-aanval, waardoor het moeilijker zou worden voor de pagina om door een aanvaller te worden uitgeschakeld.
Groeten.
Mooi zo. Voorlopig ga ik verder met NGINX op mijn site om de VPS die ik heb niet te martelen.
Leuke post @Drassill!
Ik wilde bijdragen met iets dat misschien meer statistisch was dan configuratie.
Hoewel de gemakkelijkste en snelste manier om de verbruiksparameter te berekenen is met het gemiddelde, kunnen we misschien strenger zijn en de "mediaan" gebruiken in plaats van het "gemiddelde". Wat zou ons redden? Dat de cijfers omhoog schieten als een verbinding veel geheugen heeft verbruikt. Stel dat de volgende clients de volgende waarden verbruiken, in de geheugeneenheid die ze willen (KB, MB, MiB, enz.):
10, 15, 150, 5, 7, 10, 11, 12
Het gemiddelde zou ongeveer ~ 30 opleveren
En dit omdat we een heel groot einde hebben (150), en de berekeningen zijn gek. De mediaan bestaat uit het ordenen van deze gegevens, het aantal steekproeven delen door 2 (ons midden) en vervolgens het aantal van die positie verkrijgen. Hiermee zouden we zoiets hebben
5, 7, 10, 10, 11, 12, 15, 150
Dus ons gemiddelde zou zijn: 8/2 = 4 dat is ~ 10
Hier kun je zien dat hoe gek het extreme ook is, het ons altijd een meer realistische waarde zal geven. Als we een klant toevoegen die 200 verbruikt, is onze mediaan 11, terwijl het gemiddelde kan gaan naar …….
Het is slechts een bijdrage, en het is zeer discutabel, want met de aansluitingen wordt het niet geschroefd.
Knuffel mensen linuxera 🙂
Hallo, ik heb een probleem gehad met mijn dedicated server, en het is dat elke keer dat het aantal van ongeveer 250 mensen online benadert, volgens Google Analytics in realtime, mijn server alsof hij instort en de verbinding traag wordt totdat hij wegvalt de verbinding met de website en upload nooit meer dan dat aantal gebruikers online, maar als ik de prestaties van de dedicated server zie die 8GB RAM is, laat dat 10% van het gebruik zien, de cpu: 5% van het gebruik en de harde schijf in: 1.99 % bruikbaar.
Kun je me helpen? Ik kan niet vinden wat ik moet doen. Is het uitvoeren van deze stappen de oplossing?
Goede Carlos.
Het probleem dat u beschrijft, komt veel voor als de server niet goed is voorbereid. Uw server zal waarschijnlijk een veel kleiner aantal gelijktijdige verbindingen accepteren en wanneer hij 250 verbindingen bereikt, zal hij crashen. Als je de handleiding volgt, zou je het probleem moeten kunnen oplossen, maar als je een database op die server hebt, zou je die database ook moeten optimaliseren.
Groeten.
Drassill, ik heb de configuratie gedaan die je noemde en het was bevredigend, gisteren bereikte ik 280 gebruikers online en de server bleef niet hangen, ik ben erg blij met dit resultaat en ik wil ook het andere doen dat je me vertelt om de database te optimaliseren, ¿ Hoe bereik ik dit?
Het databaseconcept is vrij open; het gebruik van mysql is niet hetzelfde als postgres (bijvoorbeeld). Ik ken natuurlijk niet alle databases; Ik heb mysql en postgres geprobeerd, en de toename van het aantal gelijktijdige verbindingen hierin zou gebaseerd zijn op de parameter max verbindingen; mysql-optimalisatie zou worden gedaan in /etc/my.conf en de parameter max connections zou moeten worden gewijzigd (onder andere). Voor postgres heb ik in plaats daarvan een artikel op mijn blog waarin wordt uitgelegd hoe u het kunt optimaliseren dat nuttig voor u kan zijn of dat u het kunt gebruiken als referentie voor uw database:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Groeten.
Hallo, als ik het eerste commando gooi, wordt de waarde 0 weergegeven. Wat zou het kunnen zijn?
Bedankt voor dit bericht.
Wat een goede handleiding, die informatie is onderdeel van wat ik zoek... bedankt!
Maar als ik nu wil dat wanneer die 250 bezoekers zijn overschreden, bezoeker 251 naar een wachtpagina of virtuele wachtrij gaat, kan ik dat dan vanuit dezelfde configuratie doen?
Groeten en bedankt!