I dag kommer jeg igen for at tale med dig om en af de mest anvendte webservices i verden: webserveren Apache2.
Det er et emne, der er blevet talt om mange gange, men nu kommer jeg for at fortælle dig om en anden funktion, der skal tages i betragtning med denne service: Grænsen for samtidige forbindelser. Det betyder ikke noget, om vi har meget grundlæggende eller et rumskib med en i7-processor og 32 GB ram ...
Grænsen for samtidige forbindelser vil altid være den samme, medmindre vi træffer de relevante foranstaltninger, hvilket betyder, at hvis vi vil have mange mennesker tilsluttet på samme tid, vil vi ikke kun kræve god hardware, men også en god konfiguration.
I dette tilfælde er det ikke nødvendigt at installere noget, alt er baseret på enkle begreber, der skal tages i betragtning for at konfigurere apache; begreber, der skal være meget klare, inden der ønskes ændringer.
Den første ting at tænke på er: Hvilken kapacitet har mit team? Hvor mange samtidige forbindelser kan mit udstyr understøtte, hvis jeg tvinger det så meget som muligt? Alt dette afhænger af en enkelt faktor; RAM (Random Access Memory).
Jo større RAM, jo større antal forbindelser, selvom der ikke er nogen fast værdi (det vil sige X-klienter for hver X-ram), er det først og fremmest vigtigt at lave nogle små beregninger på vores webserver med for at kende vores grænser.
Den første ting, du skal vide, er, hvor meget RAM i gennemsnit hver forbindelse til Apache bruger, da hver oprettet forbindelse antager et bestemt RAM-forbrug i systemet ... Det er klart, at ikke alle forbindelser bruger den samme RAM, som man bliver nødt til at lave en media ... Alt dette kan opnås med følgende kommando:
ps -ylC apache2 - sort: rss | awk '{SUM + = $ 8; I + = 1} SLUT {udskriv SUM / I / 1024} '
Det opnåede resultat vil blive repræsenteret i megabyte og kan variere afhængigt af antallet af aktive forbindelser, typen af sider, der er adgang til osv ... Derfor anbefales det at udføre testen med forskellige åbne faner; hver af dem viser om muligt forskelligt indhold. I mit tilfælde har for eksempel resultatet været 9.5458, som hvis vi afrunder det op til toppen ville være 10 MB RAM forbruges i gennemsnit pr. Forbindelse.
Det er også vigtigt at vide, hvor meget RAM der forbruges af resten af de processer, der er aktive i systemet, da webservicen ikke er den eneste, der kører i operativsystemet, og det er nødvendigt at efterlade ledig RAM-hukommelse på serveren, så den kan udføre resten af opgaverne. Dette kan opnås med kommandoen vist nedenfor:
ps -N -ylC apache2 - sort: rss | awk '{SUM + = $ 8} SLUT {print SUM / 1024}'
Det opnåede resultat ville også blive repræsenteret i megabyte, og det ville vise os ganske nøjagtigt mængden af RAM, der forbruges af resten af processerne; i mit tilfælde 800 MB. Med denne information kunne vi foretage en generel beregning af antallet af samtidige forbindelser, vi kunne have; Jeg beregner, at vi ville opnå ved hjælp af en meget enkel operation.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Med denne formel i hånden, lad os forestille os, at vi har en computer med 4 GB RAM, det vil sige 4096 MB, og at vores computer har vist de førnævnte resultater; beregningen ville være:
(4096 - 800) / 10 = 329 samtidige forbindelser
Problemet med denne beregning er, at man er for ekstrem, da den vil forbruge alt RAM (hvilket gør serveren til at forbruge swap), og i tilfælde af at have en database, såsom MySQL eller andre, vil forbindelserne til den også forbruge RAM , så det opnåede antal kunne kvalificeres som et utopisk nummer. Derfor, for at frigøre hukommelsen til mulige yderligere processer og også overveje muligheden for, at forbindelser til en database udføres, reducerer vi antallet af forbindelser til 250.
Nu hvor vi har vores maksimale antal samtidige forbindelser, bliver vi nødt til at forberede Apache til at kunne modtage dette nummer, hvilket gøres i konfigurationsfilen til dette opkald apache2.conf, som er vært i / etc / apache2.
Den pågældende fil følger en struktur baseret på moduler, hver med sit tilsvarende navn, men vi ville kun være interesserede i en af dem, hvis navn er mpm_prefork_module. Det pågældende modul har som standard følgende data:
StartServere 5 MinSpareServere 5 MaxSpareServers 10 Maks Klienter 150 Maks AnmodningerPerBarn 0
Dette modul har en række meget vigtige parametre, selvom der er en af dem, der især vil interessere os, kaldet Maxclients. Denne parameter angiver det maksimale antal samtidige forbindelser og skal ændres til 250.
En detalje at huske på er, at når en anden værdi end standard er specificeret i den nævnte parameter, er det nødvendigt at tilføje en mere lige FØR denne. Denne parameter kaldes ServerLimit og indstiller grænsen for forbindelser, som serveren kunne "holde", selv når den er uden for grænsen.
ServerLimit-parameteren skal altid være lidt højere end MaxClients og her, da der ikke er plads til at manøvrere, er der en grænse på 270. Dette ville få modulet til at se sådan ud:
StartServere 5 MinSpareServere 5 MaxSpareServere 10 ServerLimit 270 MaxKlienter 250 MaxForespørgslerPerChild 0
Nu ville det kun være nødvendigt at genstarte Apache-tjenesten ved hjælp af kommandoen:
/etc/init.d/apache2 genstart
Med dette kunne vi allerede nyde vores optimerede webserver.
Greetings.
Tak for indlægget!
Jeg er glad for, at du fandt det nyttigt.
Greetings.
Der er en måde at klynge Apache og to servere på. Kan du forklare, hvordan det fungerer?
Selvom jeg har læst nogle teorier om det, har jeg aldrig anvendt det til praksis. Alligevel kan denne artikel måske give dig en vis vejledning i denne henseende, selvom jeg gentager, at jeg ikke har haft mulighed for at omsætte den til praksis:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
Du har bedt i lang tid, hvis du ikke løste det; Jeg har en afbalanceringsordning med en tredjepart, der fungerer som et filsystem, du peger på mapperne, der er i var / www / html / (i mit tilfælde) til filsystemet, så de deler de samme oplysninger, og du vil muligvis kræve en virtuel ip, der reagerer og omdirigere til apaches ips, for dette kan du besætte en haproxy, og hvis du vil have det i høj tilgængelighed, kan du integrere keepalive, hvis den ene falder, den anden fortsætter med at svare, eller også hvis du allerede har et domæne til applikationen, kan du balancere med pund gør backends til begge servere, for specifikke tilfælde som moodle eller bestemte applikationer, der opretter forbindelse til en database i mysql, skal du oprette en bruger pr. app-server, der peger på den samme database.
Mange tak for indlægget, du har helt ret, vædderen er den primære beregning, selvom jeg forestiller mig, at vi også beregner det maksimale antal processer, som vores processor kan håndtere (selvfølgelig først at beregne hovedhukommelsen) og hvordan disken ville blive distribueret hårdt (Eksempel på partitioner / var = 1TR).
Du har ret; alt er vigtigt, som temperaturregulering blandt andet. Det er klart, at en kraftig processor kan udføre et større antal opgaver samtidigt med stor effektivitet, men formålet med dette indlæg var at forklare vigtigheden af RAM med hensyn til antallet af samtidige forbindelser.
En god måde at kontrollere alle disse faktorer på og se, om vores processor ikke er mættet, eller hvis vi har lidt ledig RAM, ville være ved at bruge et bash-script. Måske vil dette indlæg, jeg lavede for et par dage siden om det, være interessant for dig, som jeg efterlader dig i følgende link; Det er en global overvågning, men det kan være interessant for nogen:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
hilsen
Meget god note, mange tak!
Mange tak! Jeg håber, du har været i stand til at drage fordel af det.
Jeg vil ikke være en skør ...
... Men ved at øge antallet af forbindelser efterlader du ikke mere sårbar over for et DDoS-angreb?
Det er ikke noget stille cretin-spørgsmål. Sandheden er, at ved at øge antallet af samtidige forbindelser styrker vi delvist Apache mod DDOS-angreb, fordi du skal tage højde for, at antallet af maksimale samtidige forbindelser, der er etableret på serveren, er antallet af samlede maksimale forbindelser, ikke dem, der kommer fra en enkelt bruger. Selvom vi i starten kun kunne understøtte 150 samtidige forbindelser (uanset om de er forbindelser fra en legitim kilde eller ej), kan vi nu stole på så mange som vores server understøtter, hvilket kræver et større antal forbindelser på samme tid for at være uden service. Det er klart, at øge det maksimale antal forbindelser ikke er en måde at beskytte dig mod denne type angreb, men snarere bliver du nødt til at implementere firewall-politikker. Hvis for eksempel den webservice, du vil sætte, bliver eksponeret for internettet, ville en sikkerhedsforanstaltning, der kunne implementeres, være tilføjelsen af disse linjer til vores firewall:
iptables -A INPUT -p tcp –syn –port 80 -m connlimit –connlimit-op til 10 -m state –state NY -j ACCEPT
iptables -A INPUT -p tcp –port 80 -m state –state ESTABLISHED, RELATED -j ACCEPT
iptables -A INPUT -p tcp –port 80 -j DROP
Et af kendetegnene ved DDoS-angreb er, at en angriber kan synes at sende pakker fra flere forskellige retninger, hvilket forhindrer, at strømmen af pakker kun kommer fra en retning.
Du har ret i den forstand, at en firewall som den, jeg har oprettet, ikke er særlig effektiv mod et DDOS-angreb, da den kommer fra forskellige kilder. Alligevel er det bedre at begrænse antallet af forbindelser til 10 for hver af disse kilder i stedet for ikke at have en grænse, så hver kilde kan oprette hundrede eller flere forbindelser.
Under alle omstændigheder er spørgsmålet om spørgsmålet, at jo flere samtidige forbindelser serveren understøtter, jo sværere bliver det at slå det ned med et DDOS-angreb, hvilket vil gøre det vanskeligere for siden at blive slået ned af en angriber.
Greetings.
Godt. For nu fortsætter jeg med NGINX på mit websted for ikke at torturere den VPS, jeg har.
Dejligt indlæg @Drassill!
Jeg ønskede at bidrage med noget måske mere statistisk end konfiguration.
Selvom den nemmeste og hurtigste måde at beregne forbrugsparameteren er med middelværdien, kunne vi måske være mere stringente og bruge "medianen" i stedet for "gennemsnittet". Hvad ville redde os? At tallene skyder op, hvis en forbindelse har brugt meget hukommelse. Antag for eksempel følgende klienter, der bruger følgende værdier, i den hukommelsesenhed, de ønsker (KB, MB, MiB osv.):
10, 15, 150, 5, 7, 10, 11, 12
Gennemsnittet ville give ca. ~ 30
Og dette fordi vi har en meget stor ende (150), og beregningerne er skøre. Medianen består i at bestille disse data, dividere antallet af prøver med 2 (vores center) og derefter opnå antallet af denne position. Med dette ville vi have noget lignende
5, 7, 10, 10, 11, 12, 15, 150
Så vores gennemsnit ville være: 8/2 = 4, det vil sige ~ 10
Her kan du se, at uanset hvor skør ekstremet måtte være, vil det altid give os en mere realistisk værdi. Hvis vi tilføjer en kunde, der bruger 200, er vores median 11, mens gennemsnittet muligvis går til …….
Det er kun et bidrag, og det er meget diskutabelt, for med forbindelserne skruer det ikke.
Knus folk linuxera 🙂
Hej, jeg har haft et problem på min dedikerede server, og det er, at hver gang antallet af cirka 250 personer online nærmer sig, ifølge google analytics i realtid, kollapser min server ligesom den, og forbindelsen bliver langsom, indtil den falder forbindelsen til hjemmesiden og uploader aldrig mere end det antal brugere online, men når jeg ser ydelsen til den dedikerede server, der er 8 GB RAM, viser den 10% af brugen, CPU'en: 5% af brugen og harddisken i: 1.99 % af brugen.
Kan du hjælpe mig? Jeg kan ikke finde hvad jeg skal gøre. Er løsningen at gøre disse trin?
God Carlos.
Det problem, du beskriver, er meget almindeligt, når serveren ikke er ordentligt klargjort. Din server accepterer sandsynligvis et meget mindre antal samtidige forbindelser, og når den når 250 forbindelser, går den ned. Efter manualen skal du være i stand til at løse problemet, men hvis du har en database på den server, skal du også optimere den database.
Greetings.
Drassill, jeg har foretaget den konfiguration, du nævnte, og den har været tilfredsstillende, i går nåede jeg 280 brugere online, og serveren hang ikke, jeg er meget tilfreds med dette resultat, og jeg vil også gøre den anden ting, du fortæller mig for at optimere databasen, ¿ Hvordan opnår jeg dette?
Databasekonceptet er ret åbent; brug af mysql er ikke det samme som postgres (for eksempel). Jeg kender åbenbart ikke alle databaser; Jeg har prøvet mysql og postgres, og stigningen af de samtidige forbindelser i disse vil være baseret på parameteren max forbindelser; optimering af mysql vil blive udført i /etc/my.conf, og parameteren max. forbindelser skal ændres (blandt andre). For postgres i stedet har jeg en artikel på min blog, der forklarer, hvordan man optimerer den, der kan være nyttig for dig, eller som du kan bruge som reference til din database:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Greetings.
Hej, når jeg kaster den første kommando, viser den mig værdi 0. Hvad kan det være?
Tak for dette indlæg.
Hvilken god manual, den information er en del af det, jeg leder efter... tak!
Men nu, hvis jeg ønsker, at når disse 250 besøgende overskrides, går besøgende 251 til en venteside eller virtuel kø, kan jeg så gøre det fra den samme konfiguration?
Hilsner og tak!