Данас долазим да вам још једном разговарам о једној од најчешће коришћених веб услуга на свету: Веб серверу АпацхеКСНУМКС.
То је тема о којој се много пута говорило, али сада вам долазим да вам кажем још једну карактеристику коју треба узети у обзир код ове услуге: Граница истовремених веза. Није битно да ли имамо врло основни или свемирски брод са и7 процесором и 32 ГБ РАМ-а ...
Граница истовремених веза увек ће бити иста уколико не предузмемо одговарајуће мере, што значи да ако желимо да истовремено буде повезано много људи, неће нам бити потребан само добар хардвер, већ и добра конфигурација.
У овом случају није потребно ништа инсталирати, све се заснива на једноставним концептима који се морају узети у обзир за конфигурисање апацхе-а; концепти који морају бити врло јасни пре него што се желе извршити било какве промене.
Прво о чему треба размислити је: Који капацитет има мој тим? Колико симултаних веза може да подржи моја опрема ако је присилим што је више могуће? Све ово зависи од једног фактора; РАМ (Рандом Аццесс Мемори).
Што је већа РАМ меморија, то је већи број веза, иако не постоји фиксна вредност (то јест, Кс клијенти за сваки Кс рам), зато је пре свега важно да на нашем веб серверу направимо неке мале прорачуне, са да бисмо знали наше границе.
Прво што треба да знате је колико РАМ-а у просеку троши свака веза са Апацхеом, јер свака успостављена веза претпоставља одређену потрошњу РАМ-а у систему ... Очигледно нису све везе које троше исти РАМ, са којим би се требало успоставити медиј ... Све се то може добити следећом командом:
пс -илЦ апацхе2 --сорт: рсс | авк '{СУМ + = 8 УСД; И + = 1} ЕНД {принт СУМ / И / 1024} '
Добијени резултат би био представљен у мегабајтима и може се разликовати у зависности од броја активних веза, врсте страница којима се приступа итд. Стога је препоручљиво да се тест изврши са отвореним различитим картицама; сваки од њих приказује различите садржаје ако је могуће. У мом случају, на пример, резултат је био 9.5458, што би било ако бисмо га заокружили на врх КСНУМКС мб РАМ се троши у просеку по вези.
Такође је важно знати колико РАМ-а троши остатак процеса који су активни у систему, јер веб услуга није једина која се покреће у оперативном систему и неопходно је оставити слободну РАМ меморију на сервер тако да може извршити остатак задатака. То се може добити помоћу наредбе приказане доле:
пс -Н -илЦ апацхе2 --сорт: рсс | авк '{СУМ + = 8 УСД} ЕНД {принт СУМ / 1024}'
Добијени резултат такође би био представљен у мегабајтима и показао би нам прилично прецизно количину РАМ-а коју су потрошили остатак процеса; у мом случају КСНУМКС мб. Помоћу ових података могли бисмо да направимо општу калкулацију броја истовремених веза које бисмо могли да имамо; Рачунам да бисмо то добили врло једноставном операцијом.
(РАМТОТАЛ - РАМ_РЕСТОПРОЦЕСОС) / РАМ_ПОР_ЦОННЕКСИОН
С овом формулом у руци, замислимо да имамо рачунар са 4 ГБ РАМ-а, односно 4096 МБ и да је наш рачунар показао горе поменуте резултате; прорачун би био:
(4096 - 800) / 10 = 329 истовремених веза
Проблем са овим прорачуном је тај што је један превише екстреман, јер би потрошио сву РАМ меморију (чинећи да сервер троши замену), а такође би, у случају постојања базе података, као што је МиСКЛ или било која друга, везе са њом такође трошиле РАМ-а, тако да се добијени број могао квалификовати као утопијски број. Према томе, да бисмо ослободили меморију за могуће додатне процесе и такође размотрили могућност покретања веза са базом података, смањили бисмо број веза на 250.
Сада када имамо максималан број истовремених веза, морали бисмо да припремимо Апацхе да би могао да прими овај број, што је урађено у конфигурационој датотеци овог позива апацхеКСНУМКС.цонф, који је домаћин у / етц / апацхе2.
Дотична датотека следи структуру засновану на модула, сваки са одговарајућим именом, али нас би занимао само један од њих, чије је име мпм_префорк_модуле. Предметни модул подразумевано има следеће податке:
СтартСерверс 5 МинСпареСерверс 5 МакСпареСерверс 10 МакЦлиентс 150 МакРекуестсПерЦхилд 0
Овај модул има низ веома важних параметара, мада постоји један од њих који би нас посебно занимао, тзв Макцлиентс. Овај параметар одређује максималан број истовремених веза и треба га променити у 250.
Један детаљ који треба имати на уму је да када је у наведеном параметру наведена вредност која није задата, потребно је додати још једну само ПРИЈЕ ове. Овај параметар је позван СерверЛимит и поставља ограничење веза које би сервер могао да „држи“ чак и када је ван ограничења.
Параметар СерверЛимит увек мора бити мало већи од МакЦлиентс-а и овде, с обзиром да постоји мали маневарски простор, ограничење 270. Ово би модул изгледало овако:
СтартСерверс 5 МинСпареСерверс 5 МакСпареСерверс 10 СерверЛимит 270 МакЦлиентс 250 МакРекуестсПерЦхилд 0
Сада би било потребно само поново покренути услугу Апацхе помоћу команде:
/етц/инит.д/апацхе2 рестарт
Са овим бисмо већ могли уживати у нашем оптимизованом веб серверу.
Поздрав.
Хвала на посту!
Драго ми је што вам је било корисно.
Поздрав.
Постоји начин да се групишу Апацхе и два сервера, можете ли да објасните како то функционише?
Иако сам прочитао неку теорију о томе, никада је нисам применио у пракси. Ипак, можда вам овај чланак може дати неке смернице у том погледу, мада понављам да нисам имао прилику да то спроведем у дело:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
Дуго сте тражили, ако нисте решили; Имам схему балансирања са трећом страном која делује као систем датотека, а директоријуме који се налазе у вар / ввв / хтмл / (у мом случају) усмерите на систем датотека, тако да они деле исте информације и вероватно ћете захтевају виртуелни ип који одговара и преусмерава на ипс апацхе-а, за то можете заузети хапроки, а ако га желите у великој доступности, можете интегрисати кеепаливе у случају да један падне, други настави да реагује или такође ако већ имате домена за апликацију, можете балансирати са фунтом на оба сервера, за специфичне случајеве као што су моодле или одређене апликације које се повезују са базом података у мискл-у, морали бисте створити корисника по серверу апликације који упућује на исту базу .
Пуно вам хвала на посту, потпуно сте у праву, рам је примарни прорачун, мада претпостављам да израчунавамо и максималан број процеса са којима наш процесор може да се носи (наравно, прво изврши прорачун главне меморије) и како би се диск тешко дистрибуирао (Пример партиција / вар = 1ТР).
У праву си; све је важно, попут контроле температуре између осталог. Очигледно је да моћни процесор може истовремено да извршава већи број задатака са великом ефикасношћу, али циљ овог поста био је објаснити значај РАМ-а с обзиром на број истовремених веза.
Добар начин за контролу свих ових фактора и утврђивање да ли наш процесор није засићен или имамо мало слободне РАМ меморије био би коришћењем басх скрипте. Можда ће вам бити занимљив овај пост који сам о њему објавио пре неколико дана, а који вам остављам на следећем линку; То је глобални мониторинг, али некоме може бити занимљив:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
поздрави
Врло добра нота, пуно вам хвала!
Хвала пуно! Надам се да сте успели да то искористите.
Не желим бити кретен ...
... Али повећањем броја веза не остављате рањивије на ДДоС напад?
То није тихо кретенско питање. Истина је да повећањем броја истовремених веза делимично ојачавамо Апацхе против ДДОС напада, јер морате узети у обзир да је број максималних истовремених веза успостављених на серверу број укупних максималних веза, а не оних које долазе са један корисник. Дакле, док смо на почетку могли подржавати само 150 истовремених веза (било да се ради о везама из легитимног извора или не), сада можемо рачунати на онолико колико подржава наш сервер, захтевајући већи број веза истовремено да буду без услуга. Очигледно је да повећање максималног броја веза није начин да се заштитите од ове врсте напада, већ бисте морали да примените политике заштитног зида. Ако ће, на пример, веб услуга коју желите да буде изложена интернету, безбедносна мера која би се могла применити било би додавање ових линија у наш заштитни зид:
иптаблес -А ИНПУТ -п тцп –син –дпорт 80 -м цоннлимит –цоннлимит-уп то 10 -м стате –стате НЕВ -ј АЦЦЕПТ
иптаблес -А УЛАЗ -п тцп -порт 80 -м стање -држава ОСНОВАНА, ПОВЕЗАНА -ј ПРИХВАТИ
иптаблес -А ИНПУТ -п тцп –дпорт 80 -ј ДРОП
Једна од карактеристика ДДоС напада је да се нападачу може чинити да шаље пакете из неколико различитих праваца, што спречава проток пакета из само једног смера.
У праву сте у смислу да заштитни зид попут овог који сам ја поставио није баш ефикасан против ДДОС напада, јер долази из различитих извора. Ипак, боље је ограничити број веза на 10 за сваки од ових извора, а не имати ограничење, тако да сваки извор може успоставити стотину веза или више.
У сваком случају, комплет питања је да што више истовремених веза сервер подржава, то ће га теже срушити ДДОС нападом, што ће отежати срушење странице од стране нападача .
Поздрав.
Добро. За сада настављам са НГИНКС-ом на својој веб локацији како не бих мучио ВПС који имам.
Леп пост @Драссилл!
Желео сам да допринесем нечим можда више статистичким него конфигурацијом.
Иако је најлакши и најбржи начин израчунавања параметра потрошње средњи, можда бисмо могли бити ригорознији и користити „медијану“ уместо „средњу вредност“. Шта би нас спасило? Да се бројеви појачају у случају да је веза одузела пуно меморије. На пример, претпоставимо да следећи клијенти који троше следеће вредности у јединици меморије коју желе (КБ, МБ, МиБ итд.):
10, 15, 150, 5, 7, 10, 11, 12
Просек би дао око ~ 30
И то зато што имамо врло велики крај (150), а калкулације су луде. Медијана се састоји од редоследа ових података, дељења броја узорака са 2 (наш центар) и добијања броја тог положаја. Са овим бисмо имали нешто слично
5, 7, 10, 10, 11, 12, 15, 150
Дакле, наша средња вредност била би: 8/2 = 4 што је ~ 10
Овде можете видети да, колико год екстремни луди били, увек ће нам дати реалнију вредност. Ако додамо купца који потроши 200, наша средња вредност биће 11, док просек може ићи на …….
То је само допринос и врло је дискутабилно, јер са везама није зајебано.
Загрлите људе линукера 🙂
Здраво, имао сам проблем на свом наменском серверу и то је да сваки пут када се приближи број од приближно 250 људи на мрежи, према Гоогле аналитици у стварном времену, мој сервер се сруши и веза постаје спора док не прекине везу на веб локацију и никада не отпрема више од тог броја корисника на мрежи, али када видим перформансе наменског сервера који је 8 ГБ рам, то показује 10% употребе, процесор: 5% употребе и чврсти диск: 1.99% употребе.
Можеш ли да ми помогнеш? Не могу да пронађем шта да радим, да ли су ови кораци решење?
Добри Царлос.
Проблем који описујете врло је чест када сервер није правилно припремљен. Ваш сервер ће вероватно прихватити много мањи број истовремених веза и када достигне 250 веза срушиће се. Пратећи приручник, могли бисте да решите проблем, мада ако имате базу података на том серверу, морали бисте је и оптимизирати.
Поздрав.
Драссилл, урадио сам конфигурацију коју сте споменули и она је била задовољавајућа, јуче сам досегао 280 корисника на мрежи и сервер се није обуставио, веома сам задовољан овим резултатом, а такође желим да урадим и другу ствар коју ми кажете да оптимизирам база података, ¿Како то постићи?
Концепт базе података је прилично отворен; коришћење мискл-а није исто што и постгрес (на пример). Очигледно да не знам све базе података; Испробао сам мискл и постгрес, а повећање истовремених веза у њима би се заснивало на параметру мак везе; оптимизација мискл-а би се урадила у /етц/ми.цонф и параметар мак везе би морао да се промени (између осталог). Уместо тога, за постгрес, на свом блогу имам чланак који објашњава како да га оптимизирате и који вам може бити користан или који можете користити као референцу за своју базу података:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Поздрав.
Здраво, када бацим прву команду, показује ми вредност 0. Шта би то могло бити?
Хвала вам на овом посту.
Како добар приручник, те информације су део онога што тражим... хвала!
Али сада, ако желим да када тих 250 посетилаца премаши, посетилац 251 оде на страницу за чекање или виртуелни ред, могу ли то да урадим из ове исте конфигурације?
Поздрав и хвала!