Kiel pliigi samtempajn ligojn en Apache

Hodiaŭ mi venas por denove paroli al vi pri unu el la plej uzataj retservoj en la mondo: La retservilo Apache2.

Ĝi estas temo pri kiu oni parolis multajn fojojn, sed nun mi venas por rakonti al vi pri alia funkcio konsiderinda kun ĉi tiu servo: La limo de samtempaj konektoj. Ne gravas, ĉu ni havas tre bazajn aŭ kosmoŝipon kun i7-procesoro kaj 32 GB da RAM ...

La limo de samtempaj konektoj ĉiam estos la sama, krom se ni prenas la taŭgajn rimedojn, kio signifas, ke se ni volas havi multajn homojn samtempe konektitajn, ni ne nur postulos bonan aparataron, sed ankaŭ bonan agordon.

Ĉi-kaze ne necesas instali ion ajn, ĉio baziĝas sur simplaj konceptoj, kiujn oni devas konsideri por agordi apache; konceptoj, kiuj devas esti tre klaraj, antaŭ ol voli fari iujn ŝanĝojn.

apache2_logo

La unua afero pripensinda estas: Kiun kapablon havas mia teamo? Kiom da samtempaj konektoj povas subteni mia teamo se mi devigas ĝin laŭeble? Ĉio ĉi dependas de unu faktoro; RAM (Hazarda Alira Memoro).

Ju pli granda estas la RAM, des pli granda estas la nombro de konektoj, kvankam ne ekzistas fiksa valoro (tio estas, X-klientoj por ĉiu X-RAM), tial antaŭ ĉio gravas fari iujn malgrandajn kalkulojn sur nia retservilo, kun la por koni niajn limojn.

La unua afero, kiun vi devas scii, estas kiom da memoro RAM konsumas averaĝe ĉiun ligon al Apache, ĉar ĉiu rilato establita supozas certan konsumon de RAM en la sistemo ... Evidente ne ĉiuj ligoj konsumas la saman RAM, kun kiu vi devus fari amaskomunikilaron ... Ĉio ĉi estas akirebla per la jena komando:

ps -ylC apache2 --sort: rss | awk '{SUM + = $ 8; I + = 1} FINO {print SUM / I / 1024} '

La akirita rezulto estus reprezentita en megabajtoj kaj povas varii laŭ la nombro de aktivaj konektoj, la speco de paĝoj aliritaj ktp ... Tial estas konsilinde plenumi la teston kun malsamaj langetoj malfermitaj; ĉiu el ili montrante malsaman enhavon se eblas. En mia kazo, ekzemple, la rezulto estis 9.5458, kio se ni rondigos ĝin supre estus 10 MB RAM konsumita averaĝe po konekto.

Ankaŭ gravas scii kiom da RAM konsumas la ceteraj procezoj aktivaj en la sistemo, ĉar la retservo ne estas la sola, kiu funkcias en la operaciumo kaj necesas lasi senpagan RAM-memoron sur la servilo por ke ĝi povu plenumi la ceterajn taskojn. Ĉi tio povas esti akirita per la komando montrita sube:

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

La akirita rezulto ankaŭ estus reprezentita en megabajtoj, kaj ĝi montrus al ni sufiĉe precize la kvanton de RAM konsumita de la resto de la procezoj; en mia kazo 800 MB. Per ĉi tiuj informoj ni povus fari ĝeneralan kalkulon de la nombro de samtempaj konektoj, kiujn ni povus havi; Mi kalkulas, ke ni akirus per tre simpla operacio.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

Kun ĉi tiu formulo en la mano, ni imagu, ke ni havas komputilon kun 4 GB-RAM, tio estas 4096 MB kaj ke nia komputilo montris la menciitajn rezultojn; la kalkulo estus:

(4096 - 800) / 10 = 329 samtempaj konektoj

La problemo kun ĉi tiu kalkulo estas, ke unu estas tro ekstrema, ĉar ĝi konsumus la tutan RAM (igante la servilon konsumi interŝanĝon) kaj ankaŭ, en kazo de havi datumbazon, kiel MySQL aŭ iu ajn alia, la ligoj al ĝi ankaŭ konsumus. RAM, do la akirita nombro povus esti kvalifikita kiel utopia nombro. Tial, por liberigi memoron por eblaj aldonaj procezoj kaj ankaŭ pripensi la eblecon lanĉi konektojn al datumbazo, ni reduktus la nombron de ligoj al 250.

Nun, kiam ni havas nian maksimuman nombron de samtempaj konektoj, ni devus prepari Apache por ricevi ĉi tiun numeron, kio estas farita en la agorda dosiero de ĉi tiu alvoko. apache2.conf, kiu estas gastigita en / etc / apache2.

La koncerna dosiero sekvas strukturon bazitan sur moduloj, ĉiu kun sia responda nomo, sed nin interesus nur unu el ili, kies nomo estas  mpm_prefork_module. La koncerna modulo havas la jenajn datumojn defaŭlte:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Ĉi tiu modulo havas serion da tre gravaj parametroj, kvankam ekzistas unu el ili, kiu aparte interesus nin, nomata MaxClients. Ĉi tiu parametro specifas la maksimuman nombron de samtempaj konektoj kaj devas esti modifita al 250.

Memorinda unu detalo estas, ke kiam alia valoro krom la apriora estas specifita en menciita parametro, necesas aldoni alian pli nur ANTA this ĉi tiu. Ĉi tiu parametro nomiĝas ServerLimit kaj starigas la limon de konektoj, kiujn la servilo povus "teni" eĉ kiam ĝi estas ekster la limo.

La parametro ServerLimit ĉiam devas esti iomete pli alta ol la MaxClients kaj ĉi tie, ĉar estas malmulta spaco por manovro, limo de 270. Ĉi tio igus la modulon aspekti tiel:

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

Nun necesus nur rekomenci la Apache-servon per la komando: 

/etc/init.d/apache2 rekomencu

Per ĉi tio ni jam povis ĝui nian optimumigitan retservilon.

Salutojn.


La enhavo de la artikolo aliĝas al niaj principoj de redakcia etiko. Por raporti eraron alklaku Ĉi tie.

21 komentoj, lasu la viajn

Lasu vian komenton

Via retpoŝta adreso ne estos eldonita. Postulita kampojn estas markita per *

*

*

  1. Respondeculo pri la datumoj: Miguel Ángel Gatón
  2. Celo de la datumoj: Kontrola SPAM, administrado de komentoj.
  3. Legitimado: Via konsento
  4. Komunikado de la datumoj: La datumoj ne estos komunikitaj al triaj krom per laŭleĝa devo.
  5. Stokado de datumoj: Datumbazo gastigita de Occentus Networks (EU)
  6. Rajtoj: Iam ajn vi povas limigi, retrovi kaj forigi viajn informojn.

  1.   zetatino diris

    Dankon pro la afiŝo!

    1.    Drassill diris

      Mi ĝojas, ke vi trovis ĝin utila.

      Salutojn.

  2.   Mikelanĝelo diris

    Estas maniero kunigi kun Apache kaj du serviloj, ĉu vi povas klarigi kiel ĝi funkcias?

    1.    Drassill diris

      Kvankam mi legis ian teorion pri ĝi, mi neniam aplikis ĝin al praktiko. Malgraŭ tio, eble ĉi tiu artikolo povas doni al vi ian konsilon ĉi-rilate, kvankam mi ripetas, ke mi ne havis la okazon praktiki ĝin:

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

    2.    Eduardo Jalil diris

      Vi petis delonge, se vi ne solvis; Mi havas ekvilibran skemon kun tria, kiu funkcias kiel dosiersistemo, vi direktas la dosierujojn en var / www / html / (miaokaze) al la dosiersistemo, do ili dividas la samajn informojn, kaj eble vi faros postulas virtualan IP, kiu respondas kaj alidirektas al la IPs de la apache, por tio vi povas okupi haproksion kaj se vi volas ĝin en alta havebleco, vi povas integri keepalive en kazo unu falas, la alia daŭre respondas, aŭ ankaŭ se vi jam havas domajno por la aplikaĵo, vi povas ekvilibrigi kun funto faranta backends al ambaŭ serviloj, por specifaj kazoj kiel moodle aŭ iuj aplikoj, kiuj konektas al datumbazo en mysql, vi devus krei uzanton por app-servilo, kiu montras al la sama datumbazo .

  3.   shamaru diris

    Koran dankon pro la afiŝo, vi tute pravas, la RAM estas la ĉefa kalkulo, kvankam mi imagas, ke ni ankaŭ kalkulas la maksimuman nombron da procezoj, kiujn nia procesoro povas pritrakti (kompreneble, unue farante la kalkulon de la ĉefa memoro) kaj kiel la disko estus disdonata malmole (Ekzemplaj subdiskoj / var = 1TR).

    1.    Drassill diris

      Vi pravas; ĉio gravas, kiel temperaturregado interalie. Evidente potenca procesoro povas plenumi pli multajn taskojn samtempe kun granda efikeco, sed la celo de ĉi tiu afiŝo estis klarigi la gravecon de RAM rilate al la nombro de samtempaj konektoj.

      Bona maniero kontroli ĉiujn ĉi tiujn faktorojn kaj vidi ĉu nia procesoro ne saturas aŭ ĉu ni havas malmultan senpagan RAM, estus uzante bash-skripton. Eble ĉi tiu afiŝo, kiun mi faris antaŭ kelkaj tagoj pri ĝi, estas interesa por vi, kiun mi lasas al vi en la sekva ligilo; Ĝi estas tutmonda monitorado sed ĝi povas esti interesa por unu:

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

      salutoj

  4.   Sergio S. diris

    Tre bona noto, dankegon!

    1.    Drassill diris

      Multaj dankoj! Mi esperas, ke vi povis utiligi ĝin.

  5.   pajaco diris

    Mi ne volas esti stultulo ...
    ... Sed pliigante la nombron de ligoj, vi ne lasas vin pli vundebla al DDoS-atako?

    1.    Drassill diris

      Ĝi ne estas trankvila kretena demando. La vero estas, ke pliigante la samtempajn konektojn, ni parte fortikigas Apache kontraŭ DDOS-atakoj, ĉar vi devas konsideri, ke la nombro de maksimumaj samtempaj konektoj establitaj en la servilo estas la nombro de totalaj maksimumaj konektoj, ne tiuj, kiuj venas de unu sola uzanto. Tiel, dum komence ni povus nur subteni 150 samtempajn konektojn (ĉu ili estas ligoj de legitima fonto aŭ ne) nun ni povas fidi je tiom multe, kiom nia servilo subtenas, postulante pli grandan nombron da ligoj samtempe resti sen servo. Evidente, pliigi la maksimuman nombron de konektoj ne estas maniero protekti vin kontraŭ ĉi tiu tipo de atako, sed prefere fajroŝirmaj politikoj devas esti efektivigitaj. Se ekzemple la retservo, kiun vi volas meti, estos eksponita al interreto, sekureca rimedo efektivigebla estus la aldono de ĉi tiuj linioj al nia fajroŝirmilo:

      iptables -A INPUT -p tcp –syn –port 80 -m connlimit –connlimit-upto 10 -m state –state NEW -j ACCEPT

      iptables -A INPUT -p tcp –port 80 -m state –state STARED, RELATED -j ACCEPT

      iptables -A INPUT -p tcp –dport 80 -j DROP

      1.    klaŭno diris

        Unu el la karakterizaĵoj de DDoS-atakoj estas ke atakanto povas ŝajni sendi pakaĵetojn de pluraj malsamaj indikoj, kio malhelpas la fluon de pakaĵetoj nur veni de unu direkto.

    2.    Drassill diris

      Vi pravas en la senco, ke fajroŝirmilo kiel tiu, kiun mi starigis, ne tre efikas kontraŭ DDOS-atako, ĉar ĝi devenas de diversaj fontoj. Tamen estas pli bone limigi la nombron de konektoj al 10 por ĉiu el ĉi tiuj fontoj anstataŭ ne havi limon, tiel ke ĉiu fonto povas establi cent aŭ pli da ligoj.

      Ĉiukaze la kompleto de la demando estas, ke ju pli samtempaj konektoj subtenas la servilo, des pli malfacile estos renversi ĝin per DDOS-atako, kio pli malfaciligus la atakon de la paĝo de atakanto. .

      Salutojn.

  6.   eliotime3000 diris

    Bone. Nuntempe mi daŭrigas kun NGINX en mia retejo por ne turmenti la VPS, kiun mi havas.

  7.   Bruno cascio diris

    Bona afiŝo @ Drassill!

    Mi volis kontribui per io eble pli statistika ol agordo.
    Kvankam la plej facila kaj rapida maniero kalkuli la konsuman parametron estas kun la meznombro, eble ni povus esti pli rigoraj kaj uzi la "medianon" anstataŭ la "meznombro". Kio savus nin? Ke la nombroj kreskas, se ligo konsumis multan memoron. Ekzemple supozu la jenajn klientojn, kiuj konsumas la jenajn valorojn, en la memora unuo, kiun ili volas (KB, MB, MiB, ktp):

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

    La mezumo donus ĉirkaŭ ~ 30

    Kaj ĉi tio ĉar ni havas tre grandan finpunkton (150), kaj la kalkuloj estas frenezaj. La mediano konsistas el ordigi ĉi tiujn datumojn, dividi la nombron de specimenoj per 2 (nia centro) kaj tiam akiri la nombron de tiu pozicio. Kun ĉi tio ni havus ion similan

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

    Do nia meznombro estus: 8/2 = 4 tio estas ~ 10

    Ĉi tie vi povas vidi, kiom ajn freneza la ekstremo povas esti, ĝi ĉiam donos al ni pli realisman valoron. Se ni aldonos klienton, kiu konsumas 200, nia mezumo estos 11, dum la mezumo eble iros al .......

    Ĝi estas nur kontribuo, kaj ĝi estas tre diskutebla, ĉar kun la ligoj ĝi ne estas ŝraŭbita.

    Hug people linuxera 🙂

  8.   Carlos diris

    Saluton, mi havis problemon en mia dediĉita servilo, kaj estas, ke ĉiufoje kiam la nombro de ĉirkaŭ 250 homoj interrete alproksimiĝas, laŭ google analytics en reala tempo, mia servilo ŝatas ĝin kolapsas kaj la konekto malrapidiĝas ĝis ĝi faligas la konekton. al la retejo kaj neniam alŝutas pli ol tiu nombro da uzantoj interrete, sed kiam mi vidas la rendimenton de la dediĉita servilo, kiu estas 8gb-RAM, ĝi montras 10% de uzo, la cpu: 5% de uzo kaj la malmola disko en: 1.99% de uzo.
    Ĉu vi povas helpi min? Mi ne povas trovi kion fari, ĉu fari ĉi tiujn paŝojn estas la solvo?

    1.    Drassill diris

      Bona Karlo.

      La problemo, kiun vi priskribas, estas tre ofta kiam la servilo ne taŭge preparas. Via servilo probable akceptos multe pli malgrandan nombron de samtempaj konektoj kaj kiam ĝi atingos 250 konektojn, ĝi frakasiĝos. Sekvante la manlibron vi devus povi solvi la problemon, kvankam se vi havas datumbazon en tiu servilo vi ankaŭ devus optimumigi tiun datumbazon.

      Salutojn.

      1.    Carlos diris

        Drassill, mi faris la agordon, kiun vi menciis, kaj ĝi estis kontentiga, hieraŭ mi atingis 280 uzantojn interrete kaj la servilo ne fiaskis, mi estas tre kontenta pri ĉi tiu rezulto, kaj mi ankaŭ volas fari la alian aferon, kiun vi diras al mi, ke mi optimigu la datumbazo, Kiel mi atingas ĉi tion?

    2.    Drassill diris

      La datumbaza koncepto estas sufiĉe malferma; uzi mysql ne samas al postgres (ekzemple). Evidente mi ne konas ĉiujn datumbazojn; Mi provis mysql kaj postgres, kaj la pliigo de la samtempaj konektoj en ĉi tiuj baziĝus sur la parametro maksimumaj ligoj; mysql-optimumigo fariĝus en /etc/my.conf kaj la parametro maksimuma rilato devus esti ŝanĝita (inter aliaj). Por postgresoj anstataŭe, mi havas artikolon en mia blogo, kiu klarigas kiel optimumigi ĝin, kiu povas esti utila al vi aŭ ke vi povas uzi ĝin kiel referencon por via datumbazo:

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

      Salutojn.

  9.   Erickson vasquez diris

    Saluton, kiam mi ĵetas la unuan ordonon, ĝi montras al mi valoron 0. Kio ĝi povus esti?

  10.   Daniel Ojeda diris

    Dankon pro ĉi tiu afiŝo.