Kā palielināt vienlaicīgos savienojumus Apache

Šodien es vēlreiz ierunājos ar jums vēlreiz parunāt par vienu no visbiežāk izmantotajiem tīmekļa pakalpojumiem pasaulē: tīmekļa serveri Apache2.

Tā ir tēma, par kuru ir runāts daudzkārt, bet tagad es jums pastāstīšu par vēl vienu funkciju, kas jāņem vērā šajā pakalpojumā: Vienlaicīgu savienojumu robeža. Nav svarīgi, vai mums ir ļoti vienkāršs vai kosmosa kuģis ar i7 procesoru un 32 GB RAM ...

Vienlaicīgo savienojumu limits vienmēr būs vienāds, ja vien neveiksim atbilstošus pasākumus, kas nozīmē, ka, ja mēs vēlamies, lai vienlaikus būtu savienoti daudzi cilvēki, mums būs nepieciešama ne tikai laba aparatūra, bet arī laba konfigurācija.

Šajā gadījumā nekas nav jāinstalē, viss ir balstīts uz vienkāršiem jēdzieniem, kas jāņem vērā, lai konfigurētu apache; koncepcijas, kurām jābūt ļoti skaidrām, pirms vēlaties veikt izmaiņas.

apache2_logo

Vispirms ir jādomā: kāda ir mana komandas kapacitāte? Cik vienlaicīgu savienojumu mans aprīkojums var atbalstīt, ja es to pēc iespējas vairāk piespiestu? Tas viss ir atkarīgs no viena faktora; RAM (brīvpiekļuves atmiņa).

Jo lielāka RAM, jo lielāks ir savienojumu skaits, kaut arī nav fiksētas vērtības (tas ir, X klienti katram X ram), tāpēc vispirms ir svarīgi veikt nelielus aprēķinus mūsu tīmekļa serverī ar lai uzzinātu mūsu robežas.

Pirmā lieta, kas jums jāzina, ir tas, cik daudz RAM vidēji patērē katrs savienojums ar Apache, jo katrs izveidotais savienojums paredz noteiktu RAM patēriņu sistēmā ... Acīmredzot ne visi savienojumi patērē to pašu RAM, ar kuru būtu jāizveido multivide ... To visu var iegūt ar šādu komandu:

ps -ylC apache2 - kārtot: rss | awk '{SUM + = 8 USD; I + = 1} END {drukāt SUM / I / 1024} '

Iegūtais rezultāts būtu attēlots megabaitos un var atšķirties atkarībā no aktīvo savienojumu skaita, piekļūto lapu veida utt. Tāpēc testu ieteicams veikt, atverot dažādas cilnes; katrs no tiem, ja iespējams, parāda atšķirīgu saturu. Piemēram, manā gadījumā rezultāts ir 9.5458, kas būtu, ja mēs to noapaļotu uz augšu 10 MB Vidēji vienā savienojumā patērēta RAM.

Ir arī svarīgi zināt, cik daudz RAM patērē pārējie procesi, kas ir aktīvi sistēmā, jo tīmekļa pakalpojums nav vienīgais, kas darbojas operētājsistēmā, un ir nepieciešams atstāt brīvu RAM atmiņu operētājsistēmā serveri, lai tas varētu izpildīt pārējos uzdevumus. To var iegūt ar komandu, kas parādīta zemāk:

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

Iegūtais rezultāts būtu attēlots arī megabaitos, un tas mums diezgan precīzi parādītu RAM apjomu, ko patērē pārējie procesi; manā gadījumā 800 MB. Izmantojot šo informāciju, mēs varētu veikt vispārēju aprēķinu par iespējamo vienlaicīgo savienojumu skaitu; Es aprēķinu, ka mēs to iegūtu, izmantojot ļoti vienkāršu darbību.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

Ar šo formulu rokās iedomāsimies, ka mums ir dators ar 4 GB RAM, tas ir, 4096 MB, un ka mūsu dators ir uzrādījis iepriekš minētos rezultātus; aprēķins būtu:

(4096 - 800) / 10 = 329 vienlaicīgi savienojumi

Šī aprēķina problēma ir tā, ka viens ir pārāk ekstrēms, jo tas patērētu visu operatīvo atmiņu (liekot serverim patērēt mijmaiņu), kā arī, ja ir datu bāze, piemēram, MySQL vai jebkura cita, arī savienojumi ar to patērētu RAM, tāpēc iegūto numuru varēja kvalificēt kā utopisku numuru. Tāpēc, lai atbrīvotu atmiņu iespējamiem papildu procesiem un apsvērtu arī iespēju, ka tiek veikti savienojumi ar datu bāzi, mēs samazinātu savienojumu skaitu ar 250.

Tagad, kad mums ir maksimālais vienlaicīgo savienojumu skaits, mums būs jāsagatavo Apache šī numura saņemšanai, kas tiek darīts šī zvana konfigurācijas failā apache2.conf, kas tiek mitināts / etc / apache2.

Attiecīgais fails atbilst struktūrai, kuras pamatā ir moduļiem, katrs ar savu atbilstošo vārdu, bet mūs interesētu tikai viens no viņiem, kura vārds ir  mpm_prefork_module. Attiecīgajam modulim pēc noklusējuma ir šādi dati:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Šim modulim ir virkne ļoti svarīgu parametru, lai gan ir viens no tiem, kas mūs īpaši interesētu, saukts Maxclients. Šis parametrs norāda maksimālo vienlaicīgo savienojumu skaitu, un tas ir jāpārveido uz 250.

Viena detaļa, kas jāpatur prātā, ir tāda, ka, ja minētajā parametrā ir norādīta cita vērtība, nevis noklusējuma vērtība, pirms šīs vērtības ir jāpievieno vēl viena vērtība. Šo parametru sauc ServerLimit un nosaka savienojumu limitu, kuru serveris varētu "turēt" pat tad, ja tas ir ārpus ierobežojuma.

ServerLimit parametram vienmēr jābūt nedaudz augstākam par MaxClients, un šeit, tā kā manevrēšanai ir maz vietas, 270. Tādējādi modulis izskatīsies šādi:

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

Tagad būs nepieciešams tikai restartēt Apache pakalpojumu, izmantojot komandu: 

/etc/init.d/apache2 restartējiet

Ar to mēs jau varētu izbaudīt mūsu optimizēto tīmekļa serveri.

Sveicieni.


Raksta saturs atbilst mūsu principiem redakcijas ētika. Lai ziņotu par kļūdu, noklikšķiniet uz šeit.

21 komentāri, atstājiet savus

Atstājiet savu komentāru

Jūsu e-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti ar *

*

*

  1. Atbildīgais par datiem: Migels Ángels Gatóns
  2. Datu mērķis: SPAM kontrole, komentāru pārvaldība.
  3. Legitimācija: jūsu piekrišana
  4. Datu paziņošana: Dati netiks paziņoti trešām personām, izņemot juridiskus pienākumus.
  5. Datu glabāšana: datu bāze, ko mitina Occentus Networks (ES)
  6. Tiesības: jebkurā laikā varat ierobežot, atjaunot un dzēst savu informāciju.

  1.   zetatino teica

    Paldies par ierakstu!

    1.    Drassill teica

      Es priecājos, ka jums tas likās noderīgs.

      Sveicieni.

  2.   Miguel Angel teica

    Ir veids, kā apvienot Apache un divus serverus, vai varat paskaidrot, kā tas darbojas?

    1.    Drassill teica

      Lai gan esmu lasījis kādu teoriju par to, nekad neesmu to pielietojis praksē. Pat ja tā, varbūt šis raksts var sniegt jums zināmas norādes šajā sakarā, lai gan es atkārtoju, ka man nav bijusi iespēja to īstenot praksē:

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

    2.    Eduardo Jalils teica

      Jūs ilgi prasījāt, ja neatrisinājāt; Man ir līdzsvarošanas shēma ar trešo personu, kas darbojas kā failu sistēma. Jūs mapēs var / www / html / (manā gadījumā) esošās mapes novirzāt uz failu sistēmu, tāpēc tām ir tāda pati informācija, un jūs, iespējams, nepieciešama virtuāla ip, kas reaģē un novirza uz apache ips, lai to izdarītu, jūs varat aizņemt haproksi un, ja vēlaties, lai tā būtu ļoti pieejama, jūs varat integrēt keepalive gadījumā, ja viens nokrīt, otrs turpina reaģēt vai arī, ja jums jau ir lietojumprogrammas domēns, jūs varat līdzsvarot ar mārciņu, veicot aizmugures abos serveros, īpašos gadījumos, piemēram, moodle vai noteiktām lietojumprogrammām, kas izveido savienojumu ar datu bāzi mysql, jums katram lietotnes serverim jāizveido lietotājs, kas norāda uz to pašu datu bāzi .

  3.   šamaru teica

    Liels paldies par ziņu, jums ir pilnīga taisnība, primārais aprēķins ir ram, lai gan es iedomājos, ka mēs aprēķinām arī maksimālo procesu skaitu, ko mūsu procesors var apstrādāt (protams, vispirms veicot galvenās atmiņas aprēķinu) un kā disks tiks sadalīts cietā veidā (Partition example / var = 1TR)

    1.    Drassill teica

      Tev taisnība; viss ir svarīgi, piemēram, temperatūras kontrole, cita starpā. Acīmredzot jaudīgs procesors var vienlaikus izpildīt lielāku skaitu uzdevumu ar lielu efektivitāti, taču šī ziņojuma mērķis bija izskaidrot RAM nozīmi attiecībā uz vienlaicīgu savienojumu skaitu.

      Labs veids, kā kontrolēt visus šos faktorus un pārbaudīt, vai mūsu procesors nav piesātināts vai vai mums ir maz brīvas RAM, būtu, izmantojot bash skriptu. Varbūt šī ziņa, kuru es pirms dažām dienām izveidoju par to, ir jums interesanta, kuru es jums atstāju šajā saitē; Tas ir globāls monitorings, bet kādam tas var būt interesants:

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

      Sveicieni

  4.   Serhio S teica

    Ļoti laba piezīme, liels paldies!

    1.    Drassill teica

      Liels paldies! Es ceru, ka jūs varējāt to izmantot.

  5.   klauns teica

    Es negribu būt parauts ...
    ... Bet, palielinot savienojumu skaitu, jūs neatstājat neaizsargātāku pret DDoS uzbrukumu?

    1.    Drassill teica

      Tas nav kluss kretīna jautājums. Patiesība ir tāda, ka, palielinot vienlaicīgo savienojumu skaitu, mēs daļēji nostiprinām Apache pret DDOS uzbrukumiem, jo ​​jums jāņem vērā, ka serverī izveidoto maksimālo vienlaicīgo savienojumu skaits ir kopējo maksimālo savienojumu skaits, nevis no tiem, kas nāk no viens lietotājs. Tādējādi, lai gan sākumā mēs varējām atbalstīt tikai 150 vienlaicīgus savienojumus (neatkarīgi no tā, vai tie ir savienojumi no likumīga avota vai nē), tagad mēs varam paļauties uz tik daudz, cik mūsu serveris atbalsta, vienlaicīgi pieprasot lielāku savienojumu skaitu, lai nebūtu apkalpošana. Acīmredzot maksimālā savienojumu skaita palielināšana nav veids, kā aizsargāties pret šāda veida uzbrukumiem, bet drīzāk būtu jāievieš ugunsmūra politikas. Piemēram, ja tīmekļa pakalpojums, kuru vēlaties ievietot, tiks pakļauts internetam, drošības līdzeklis, ko varētu ieviest, būtu šo līniju pievienošana mūsu ugunsmūrim:

      iptables -A INPUT -p tcp –syn –port 80 -m connlimit –connlimit-up to 10 -m state –state JAUNS -j ACCEPT

      iptables -A INPUT -p tcp –port 80 -m state – state Dibināts, SAISTĪTS -j ACCEPT

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

      1.    klauns teica

        Viena no DDoS uzbrukumu pazīmēm ir tā, ka uzbrucējs var sūtīt paketes no vairākiem dažādiem virzieniem, kas novērš pakešu plūsmu tikai no viena virziena.

    2.    Drassill teica

      Jums ir taisnība tādā ziņā, ka tāds ugunsmūris, kādu esmu izveidojis, nav ļoti efektīvs pret DDOS uzbrukumu, jo tas nāk no dažādiem avotiem. Tomēr labāk ir ierobežot savienojumu skaitu līdz 10 katram no šiem avotiem, nevis noteikt ierobežojumu, lai katrs avots varētu izveidot simtu vai vairāk savienojumu.

      Jebkurā gadījumā jautājuma komplekts ir tāds, ka jo vairāk vienlaicīgu savienojumu serveris atbalsta, jo grūtāk būs to notriekt ar DDOS uzbrukumu, kas apgrūtinātu uzbrucēja notriekšanu lapā. .

      Sveicieni.

  6.   3000 teica

    Labi. Pagaidām es turpinu lietot NGINX savā vietnē, lai nemocītu VPS, kas man ir.

  7.   Bruno Kasio teica

    Jauks ieraksts @Drassill!

    Es gribēju sniegt kaut ko varbūt statistiskāku par konfigurāciju.
    Lai gan vienkāršākais un ātrākais veids, kā aprēķināt patēriņa parametru, ir vidējais, varbūt mēs varētu būt stingrāki un “vidējā” vietā izmantot “vidējo”. Kas mūs glābtu? Ka skaitļi uzšaujas, ja savienojums ir patērējis daudz atmiņas. Piemēram, pieņemsim, ka šie klienti vēlamās atmiņas vienībā (KB, MB, MiB utt.) Patērē šādas vērtības:

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

    Vidējais rezultāts būtu aptuveni ~ 30

    Un tas tāpēc, ka mums ir ļoti liels galējība (150), un aprēķini ir traki. Vidējais sastāv no šo datu pasūtīšanas, paraugu skaita dalīšanas ar 2 (mūsu centrs) un pēc tam šīs pozīcijas skaita iegūšanas. Ar šo mums būtu kaut kas līdzīgs

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

    Tātad mūsu vidējais lielums būtu: 8/2 = 4, kas ir ~ 10

    Šeit jūs varat redzēt, ka neatkarīgi no tā, cik ekstrēms ir ekstrēms, tas vienmēr mums piešķirs reālāku vērtību. Ja pievienosim klientu, kurš patērē 200, mūsu mediāna būs 11, bet vidējais rādītājs var nonākt līdz….

    Tas ir tikai ieguldījums, un tas ir ļoti apspriežams, jo ar savienojumiem tas nav pieskrūvēts.

    Apskāvi cilvēkus linuxera 🙂

  8.   Carlos teica

    Labdien, man ir radušās problēmas manā veltītajā serverī, un tas ir, ka katru reizi, kad tuvojas aptuveni 250 cilvēku tiešsaistē, saskaņā ar reāllaika google analytics datiem, mans serveris, piemēram, tas sabrūk un savienojums kļūst lēns, līdz tas pārtrauc savienojumu uz vietni un nekad tiešsaistē augšupielādējat ne vairāk kā šo lietotāju skaitu, bet, kad redzu veltītā servera veiktspēju, kas ir 8 GB RAM, tas parāda 10% izmantošanas, procesors: 5% izmantošanas un cietais disks: 1.99% lietošanas.
    Vai jūs varat man palīdzēt? Es nevaru atrast, ko darīt, vai šo darbību veikšana ir risinājums?

    1.    Drassill teica

      Labais Karloss.

      Jūsu aprakstītā problēma ir ļoti izplatīta, ja serveris nav pareizi sagatavots. Jūsu serveris, iespējams, pieņems daudz mazāku vienlaicīgu savienojumu skaitu, un, sasniedzot 250 savienojumus, tas avarēs. Ievērojot rokasgrāmatu, jums vajadzētu būt iespējai atrisināt problēmu, lai gan, ja jums šajā serverī ir datu bāze, jums tā arī būs jāoptimizē.

      Sveicieni.

      1.    Carlos teica

        Drassill, es esmu izdarījis jūsu pieminēto konfigurāciju, un tā ir bijusi apmierinoša, vakar es tiešsaistē sasniedzu 280 lietotājus un serveris neaizkarējās, es esmu ļoti apmierināta ar šo rezultātu, un es arī vēlos darīt citu, ko jūs man sakāt, lai optimizētu datu bāze, ¿kā es to panākšu?

    2.    Drassill teica

      Datu bāzes koncepcija ir diezgan atvērta; mysql izmantošana nav tas pats, kas postgres (piemēram). Acīmredzot es nezinu visas datubāzes; Esmu izmēģinājis mysql un postgres, un vienlaicīgo savienojumu palielināšanās šajos veidos balstās uz parametru max savienojumi; mysql optimizācija tiktu veikta mapē /etc/my.conf un būtu jāmaina parametrs max savienojumi (cita starpā). Par postgres tā vietā manā emuārā ir raksts, kurā paskaidrots, kā to optimizēt, kas jums var būt noderīgs vai kuru varat izmantot kā atsauci savai datu bāzei:

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

      Sveicieni.

  9.   Ēriksons Vaskess teica

    Sveiki, kad es iemetu pirmo komandu, tā man parāda vērtību 0. Kas tas varētu būt?

  10.   Daniels Ojeda teica

    Paldies par šo ziņu.