Kuinka lisätä samanaikaisia ​​yhteyksiä Apachessa

Tänään tulin taas puhumaan kanssasi vielä kerran yhdestä maailman eniten käytetyistä verkkopalveluista: verkkopalvelimesta Apache2.

Se on aihe, josta on puhuttu monta kertaa, mutta nyt kerron sinulle toisesta ominaisuudesta, joka on otettava huomioon tässä palvelussa: Samanaikaisten yhteyksien raja. Ei ole väliä onko meillä perus- tai avaruusalus, jossa on i7-prosessori ja 32 Gt RAM-muistia ...

Samanaikaisten yhteyksien raja on aina sama, ellemme toteuta asianmukaisia ​​toimenpiteitä, mikä tarkoittaa, että jos haluamme, että monet ihmiset ovat yhteydessä samaan aikaan, emme vaadi vain hyvää laitteistoa, mutta myös hyvää kokoonpanoa.

Tässä tapauksessa ei ole tarpeen asentaa mitään, kaikki perustuu yksinkertaisiin käsitteisiin, jotka on otettava huomioon apache-asetusten määrittämisessä; käsitteitä, joiden on oltava hyvin selkeitä ennen muutosten tekemistä.

apache2_logo

Ensimmäinen ajateltava asia on: Mikä kapasiteetti joukkueellani on? Kuinka monta samanaikaista yhteyttä laitteeni voi tukea, jos pakotan sen niin paljon kuin mahdollista? Kaikki tämä riippuu yhdestä tekijästä; RAM (Random Access Memory).

Mitä suurempi RAM-muisti, sitä suurempi yhteyksien määrä, vaikka kiinteää arvoa ei ole (eli X-asiakasta jokaiselle X-RAM-muistille), siksi ensinnäkin on tärkeää tehdä pieniä laskelmia verkkopalvelimellamme, tuntemaan rajojamme.

Ensinnäkin on tiedettävä, kuinka paljon RAM-muistia kuluttaa keskimäärin jokaista yhteyttä Apache-verkkoon, koska jokainen muodostettu yhteys edellyttää tiettyä RAM-muistin kulutusta järjestelmässä ... Ilmeisesti kaikki yhteydet eivät kuluta samaa RAM-muistia, jonka kanssa hänen pitäisi muodostaa media ... Kaikki tämä saadaan seuraavalla komennolla:

ps -ylC apache2 - lajittelu: rss | awk '{SUM + = 8 dollaria; I + = 1} LOPPU {tulosta summa / I / 1024} '

Saatu tulos edustettaisiin megatavuina ja se voi vaihdella riippuen aktiivisten yhteyksien määrästä, käytetyistä sivuista jne. Siksi on suositeltavaa suorittaa testi eri välilehtien ollessa auki; kukin niistä näyttää erilaisen sisällön, jos mahdollista. Esimerkiksi minun tapauksessani tulos on ollut 9.5458, mikä olisi, jos pyöristämme sen ylöspäin 10 MB RAM-muistin kulutus keskimäärin yhteyttä kohti.

On myös tärkeää tietää, kuinka paljon RAM-muistia kulutetaan muissa järjestelmässä aktiivisissa prosesseissa, koska verkkopalvelu ei ole ainoa, joka toimii käyttöjärjestelmässä, ja on välttämätöntä jättää vapaata RAM-muistia palvelimelle, jotta se voi suorittaa muut tehtävät. Tämä voidaan saada alla esitetyllä komennolla:

ps -N -ylC apache2 - lajittelu: rss | awk '{SUM + = $ 8} END {tulosta SUM / 1024}'

Saatu tulos olisi myös esitetty megatavuina, ja se osoittaisi meille tarkalleen muiden prosessien kuluttaman RAM-muistin määrän; minun tapauksessani 800 MB. Tämän tiedon avulla voimme tehdä yleisen laskennan mahdollisista samanaikaisista yhteyksistä; Lasken, että saisimme hyvin yksinkertaisella toiminnolla.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

Kuvitelkaamme tämän kaavan avulla, että meillä on tietokone, jossa on 4 Gt RAM-muistia, eli 4096 Mt, ja että tietokoneemme on osoittanut edellä mainitut tulokset; laskelma olisi:

(4096-800) / 10 = 329 samanaikaista yhteyttä

Tämän laskennan ongelmana on, että yksi on liian äärimmäinen, koska se kuluttaa kaiken RAM-muistin (jolloin palvelin kuluttaa vaihdon) ja myös jos sinulla on tietokanta, kuten MySQL tai jokin muu, myös yhteydet siihen kuluttavat RAM-muistia, joten saatu määrä voidaan luokitella utopistiseksi numeroksi. Siksi muistin vapauttamiseksi mahdollisia lisäprosesseja varten ja mahdollisuuksien mukaan, että yhteydet tietokantaan suoritetaan, vähentäisimme yhteyksien määrää 250.

Nyt kun meillä on enimmäismäärä samanaikaisia ​​yhteyksiä, meidän on valmistauduttava Apache vastaanottamaan tämä numero, mikä tehdään tämän puhelun määritystiedostossa apache2.conf, jota isännöidään / etc / apache2.

Kyseinen tiedosto noudattaa rakennetta, joka perustuu moduulit, jokaisella on vastaava nimi, mutta meitä kiinnostaa vain yksi heistä, jonka nimi on  mpm_prefork_module. Kyseisellä moduulilla on oletusarvoisesti seuraavat tiedot:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Tässä moduulissa on joukko erittäin tärkeitä parametreja, vaikka onkin yksi niistä, joka kiinnostaa meitä erityisesti, nimeltään Maxclients. Tämä parametri määrittää samanaikaisten yhteyksien enimmäismäärän, ja se tulisi muuttaa 250.

Yksi mielessä pidettävä yksityiskohta on se, että kun mainitussa parametrissa määritetään jokin muu arvo kuin oletusarvo, on välttämätöntä lisätä toinen arvo juuri ennen tätä. Tätä parametria kutsutaan ServerLimit ja asettaa yhteyksien rajan, jota palvelin voi "pitää" myös silloin, kun se on rajan ulkopuolella.

ServerLimit-parametrin on aina oltava hieman korkeampi kuin MaxClients, ja koska tässä on vähän liikkumavaraa, 270. Tämä tekisi moduulista seuraavanlaisen:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0

Nyt Apache-palvelu olisi käynnistettävä uudelleen vain komennolla: 

/etc/init.d/apache2 uudelleenkäynnistys

Tämän avulla voimme jo nauttia optimoidusta verkkopalvelimestamme.

Tervehdys.


Artikkelin sisältö noudattaa periaatteita toimituksellinen etiikka. Ilmoita virheestä napsauttamalla täällä.

21 kommenttia, jätä omasi

Jätä kommentti

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

*

*

  1. Vastuussa tiedoista: Miguel Ángel Gatón
  2. Tietojen tarkoitus: Roskapostin hallinta, kommenttien hallinta.
  3. Laillistaminen: Suostumuksesi
  4. Tietojen välittäminen: Tietoja ei luovuteta kolmansille osapuolille muutoin kuin lain nojalla.
  5. Tietojen varastointi: Occentus Networks (EU) isännöi tietokantaa
  6. Oikeudet: Voit milloin tahansa rajoittaa, palauttaa ja poistaa tietojasi.

  1.   zetatiini dijo

    Kiitos viestistä!

    1.    Drassill dijo

      Olen iloinen, että pidit siitä hyödyllisenä.

      Tervehdys.

  2.   Miguel Angel dijo

    Apache ja kaksi palvelinta voidaan klusteroida, voitko selittää miten se toimii?

    1.    Drassill dijo

      Vaikka olen lukenut siitä jonkin teorian, en ole koskaan soveltanut sitä käytäntöön. Silti ehkä tämä artikkeli voi antaa sinulle joitain ohjeita tältä osin, vaikka toistan, ettei minulla ole ollut mahdollisuutta soveltaa sitä käytännössä:

      http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/

    2.    Edward Khalil dijo

      olet pyytänyt jonkin aikaa, jos et ratkaissut; Minulla on tasapainotusjärjestelmä kolmannen osapuolen kanssa, joka toimii tiedostojärjestelmänä, osoitat kansiot, jotka ovat var / www / html / (minun tapauksessani) tiedostojärjestelmään, joten ne jakavat samat tiedot, ja tarvitset mahdollisesti virtuaalisen ip: n, joka vastaa ja ohjaa apachejen ips: ään, tätä varten voit miehittää haproksin ja jos haluat sen korkealla saatavuudella, voit integroida keepalive-toiminnon, jos toinen putoaa, toinen jatkaa vastaamista, tai myös jos sinulla on jo toimialueen sovellukselle, voit tasapainottaa punnan kanssa tekemällä taustatietoja molemmille palvelimille, erityistapauksissa, kuten moodle tai tietyt sovellukset, jotka muodostavat yhteyden mysql-tietokantaan, sinun on luotava käyttäjä sovelluspalvelinta kohti, joka osoittaa samaan tietokantaan.

  3.   shamaru dijo

    Paljon kiitoksia viestistä, olet täysin oikeassa, ram on ensisijainen laskelma, vaikka kuvittelen, että laskemme myös prosessoreiden enimmäismäärän, jota prosessorimme pystyy käsittelemään (tietysti ensin laskemalla päämuisti) ja kuinka levy jaetaan kovasti (esimerkki osioista / var = 1TR).

    1.    Drassill dijo

      Olet oikeassa; kaikki on tärkeää, kuten lämpötilan säätö muun muassa. Tehokas prosessori voi tietysti suorittaa suuremman määrän tehtäviä samanaikaisesti erittäin tehokkaasti, mutta tämän viestin tarkoituksena oli selittää RAM-muistin merkitys samanaikaisten yhteyksien määrään nähden.

      Hyvä tapa hallita kaikkia näitä tekijöitä ja nähdä, onko prosessorimme ole kylläinen tai onko meillä vähän vapaata RAM-muistia, käyttämällä bash-komentosarjaa. Ehkä tämä muutama päivä sitten tekemäni viesti on mielenkiintoinen sinulle, jonka jätän sinulle seuraavaan linkkiin; Se on maailmanlaajuinen seuranta, mutta se voi olla mielenkiintoista jollekin:

      http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html

      terveiset

  4.   Sergio S. dijo

    Erittäin hyvä huomautus, kiitos paljon!

    1.    Drassill dijo

      Kiitos paljon! Toivon, että olet pystynyt hyödyntämään sitä.

  5.   pelle dijo

    En halua olla ääliö ...
    … Mutta lisäämällä yhteyksien määrää et jätä haavoittuvampaa DDoS-hyökkäykselle?

    1.    Drassill dijo

      Se ei ole hiljainen kretiinikysymys. Totuus on, että lisäämällä samanaikaisten yhteyksien määrää vahvistamme Apachea osittain DDOS-hyökkäyksiä vastaan, koska sinun on otettava huomioon, että palvelimelle muodostettujen samanaikaisten yhteyksien enimmäismäärä on yhteyksien enimmäismäärä, ei niistä, jotka tulevat yksi käyttäjä. Joten vaikka alussa pystyimme tukemaan vain 150 samanaikaista yhteyttä (olivatpa ne sitten laillisista lähteistä vai ei), voimme nyt luottaa niin moniin kuin palvelimemme tukee, mikä vaatii samanaikaisesti suuremman määrän yhteyksiä olematta palvelu. Yhteyksien enimmäismäärän lisääminen ei tietenkään ole tapa suojautua tällaisilta hyökkäyksiltä, ​​vaan sinun on pikemminkin pantava täytäntöön palomuurikäytännöt. Jos esimerkiksi haluamasi verkkopalvelu altistuu Internetille, toteutettava turvatoimenpide olisi näiden rivien lisääminen palomuuriin:

      iptables -A SYÖTTÖ ​​-p tcp –syn –tuki 80 -m connlimit –connlimit-upto 10 -m tila – state UUSI -j HYVÄKSY

      iptables -A SYÖTTÖ ​​-p tcp –portti 80 -m tila –tila ESTABLISHED, RELATED -j HYVÄKSY

      iptables -A SYÖTTÖ ​​-p tcp –tuki 80 -j DROP

      1.    pelle dijo

        Yksi DDoS-hyökkäysten ominaisuuksista on, että hyökkääjä voi näyttää lähettävän paketteja useista eri suunnista, mikä estää pakettien kulkua vain yhdestä suunnasta.

    2.    Drassill dijo

      Olet oikeassa siinä mielessä, että asettamani palomuuri ei ole kovin tehokas DDOS-hyökkäystä vastaan, koska se tulee eri lähteistä. Silti on parempi rajoittaa yhteyksien määrä 10: een kullekin näistä lähteistä sen sijaan, että sillä olisi rajoitusta, jolloin kukin lähde pystyy muodostamaan sata tai enemmän yhteyksiä.

      Joka tapauksessa kysymyspaketti on, että mitä enemmän samanaikaisia ​​yhteyksiä palvelin tukee, sitä vaikeampaa on pudottaa se DDOS-hyökkäyksellä, mikä vaikeuttaisi hyökkääjän kaatamista sivulle. .

      Tervehdys.

  6.   eliotime3000 dijo

    Hyvä. Toistaiseksi jatkan sivullani NGINX: n kanssa, jotta en kiduttaisi minulla olevaa VPS: ää.

  7.   Bruno cascio dijo

    Hieno viesti @Drassill!

    Halusin osallistua jollakin ehkä tilastollisemmalla kuin kokoonpanolla.
    Vaikka helpoin ja nopein tapa laskea kulutusparametri on keskiarvo, voisimme ehkä olla tiukempia ja käyttää "mediaania" keskimääräisen sijasta. Mikä pelastaa meidät? Numerot nousevat, jos yhteys on kuluttanut paljon muistia. Oletetaan esimerkiksi, että seuraavat asiakkaat kuluttavat seuraavia arvoja haluamansa muistin yksikössä (KB, MB, MiB jne.):

    10, 15, 150, 5, 7, 10, 11, 12

    Keskiarvo antaisi noin ~ 30

    Ja tämä johtuu siitä, että meillä on hyvin suuri loppu (150), ja laskelmat ovat hulluja. Mediaani koostuu näiden tietojen järjestämisestä, näytteiden lukumäärän jakamisesta 2: lla (keskuksemme) ja sitten kyseisen sijainnin numeron saamisesta. Tämän avulla meillä olisi jotain

    5, 7, 10, 10, 11, 12, 15, 150

    Joten keskiarvo olisi: 8/2 = 4 eli ~ 10

    Täällä voit nähdä, että kuinka hullu ääri tahansa onkin, se antaa meille aina realistisemman arvon. Jos lisätään asiakas, joka kuluttaa 200, mediaanimme on 11, kun taas keskiarvo voi mennä …….

    Se on vain panos, ja se on hyvin kiistanalainen, koska liitäntöjen kanssa sitä ei ole ruuvattu.

    Halata ihmisiä linuxera 🙂

  8.   Carlos dijo

    Hei, minulla on ollut ongelma omalla palvelimellani, ja se on, että joka kerta kun noin 250 online-käyttäjää lähestyy, google analytiikan mukaan reaaliajassa palvelimeni romahtaa ja yhteys hidastuu, kunnes yhteys katkeaa verkkosivustolle enkä koskaan lataa enempää kuin tämä määrä käyttäjiä online-tilassa, mutta kun näen 8 gigatavun erillisen palvelimen suorituskyvyn, se näyttää 10% käytöstä, prosessori: 5% käytöstä ja kiintolevy: 1.99% käytön.
    Voitko auttaa minua? En löydä mitä tehdä, onko näiden vaiheiden tekeminen ratkaisu?

    1.    Drassill dijo

      Hyvä Carlos.

      Kuvaamasi ongelma on hyvin yleinen, kun palvelinta ei ole valmisteltu kunnolla. Palvelimesi todennäköisesti hyväksyy paljon pienemmän määrän samanaikaisia ​​yhteyksiä, ja kun se saavuttaa 250 yhteyttä, se kaatuu. Käsikirjan mukaan sinun pitäisi pystyä ratkaisemaan ongelma, vaikka jos sinulla on tietokanta palvelimella, sinun on myös optimoitava kyseinen tietokanta.

      Tervehdys.

      1.    Carlos dijo

        Drassill, olen suorittanut mainitsemasi kokoonpanon ja se on ollut tyydyttävä, eilen tavoittelin 280 käyttäjää verkossa ja palvelin ei roikkunut, olen erittäin tyytyväinen tulokseen, ja haluan myös tehdä toisen asian, jonka käskit optimoida tietokanta, ¿ Kuinka saavutan tämän?

    2.    Drassill dijo

      Tietokantakonsepti on melko avoin; mysql: n käyttö ei ole sama kuin esimerkiksi postgres. Ilmeisesti en tiedä kaikkia tietokantoja; Olen kokeillut mysql- ja postgres-tiedostoja, ja samanaikaisten yhteyksien kasvu näissä perustuisi parametri max yhteyksiin; mysql: n optimointi suoritettaisiin tiedostossa /etc/my.conf ja parametrien max yhteyksiä olisi muutettava (mm.). Sen sijaan blogissani on postgres-artikkeli, joka selittää kuinka optimoida se voi olla hyödyllinen sinulle tai jota voit käyttää viitteenä tietokantaan:

      http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html

      Tervehdys.

  9.   Erickson Vasquez dijo

    Hei, kun heitän ensimmäisen komennon, se näyttää minulle arvon 0. Mikä se voisi olla?

  10.   Daniel Ojeda dijo

    Kiitos tästä viestistä.