У свом извештају, Андреј Бородин ће вам рећи како су узели у обзир искуство скалирања ПгБоунцер-а приликом дизајнирања базена за повезивање , док су га пустили у производњу. Поред тога, разговараћемо о томе које функције извлакача желимо да видимо у новим верзијама: важно нам је не само да задовољимо наше потребе, већ и да развијемо корисничку заједницу .
Видео:
Здраво свима! Зовем се Андрија.
У Иандек-у развијам базе података отвореног кода. А данас имамо тему о повезивању базена веза.
Ако знате како да позовете повезивач везе на руском, онда ми реците. Заиста желим да пронађем добар технички термин који би требало да се успостави у техничкој литератури.
Тема је прилично компликована, јер је у многим базама података уређај за прикупљање конекција уграђен и не морате ни да знате за њега. Наравно, свуда постоје нека подешавања, али у Постгресу то не функционише тако. И паралелно (на ХигхЛоад++ 2019) постоји извештај Николаја Самохвалова о постављању упита у Постгресу. И колико сам разумео, овде су долазили људи који су већ савршено конфигурисали своје упите, а то су људи који се суочавају са ређим системским проблемима у вези са мрежом и коришћењем ресурса. А на неким местима би то могло бити прилично тешко у смислу да проблеми нису очигледни.
Иандек има Постгрес. Многи Иандек сервиси живе у Иандек.Цлоуд. И имамо неколико петабајта података који генеришу најмање милион захтева у секунди у Постгресу.
И пружамо прилично стандардни кластер за све услуге - ово је главни примарни чвор чвора, уобичајене две реплике (синхрона и асинхрона), резервна копија, скалирање захтева за читање на реплици.
Сваки чвор кластера је Постгрес, на коме је, поред Постгреса и система за праћење, инсталиран и пулер конекција. Цоннецтион поолер се користи за ограђивање и за своју главну намену.
Која је главна сврха скупљача веза?
Постгрес усваја модел процеса када ради са базом података. То значи да је једна веза један процес, један Постгрес бацкенд. А у овом бацкенд-у постоји много различитих кеш меморија, који су прилично скупи да би се разликовали за различите везе.
Поред тога, Постгрес код има низ под називом процАрраи. Садржи основне податке о мрежним везама. И скоро сви алгоритми за обраду процАрраи-а имају линеарну сложеност; они се крећу преко читавог низа мрежних веза. То је прилично брз циклус, али са више долазних мрежних веза ствари постају мало скупље. А када ствари постану мало скупље, можете на крају платити веома високу цену за много мрежних веза.
Постоје 3 могућа приступа:
- На страни апликације.
- На страни базе података.
- И између, односно свих врста комбинација.
Нажалост, уграђени поолер је тренутно у развоју. Наши пријатељи у ПостгреСКЛ Профессионал то углавном раде. Када ће се то појавити, тешко је предвидети. И у ствари, имамо два решења за архитекту на избор. То су базен на страни апликације и скуп проксија.
Базен на страни апликације је најлакши начин. И скоро сви управљачки програми клијента вам пружају начин: представите милионе својих веза у коду као неколико десетина веза са базом података.
Проблем који се јавља је да у одређеном тренутку желите да скалирате позадину, желите да га примените на многе виртуелне машине.
Онда схватите да имате још неколико зона доступности, неколико центара података. А приступ обједињавања на страни клијента доводи до већих бројева. Велики су око 10 прикључака. Ово је ивица која може нормално да ради.
Ако говоримо о проки поолерима, онда постоје два поолера који могу да ураде много ствари. Они нису само сакупљачи. Они су поолерс + више цоол функционалности. Ово и .
Али, нажалост, ова додатна функционалност није потребна свима. И то доводи до чињенице да поолери подржавају само обједињавање сесија, односно један долазни клијент, један одлазни клијент у базу података.
Ово није баш погодно за наше сврхе, тако да користимо ПгБоунцер, који имплементира прикупљање трансакција, тј. серверске везе се упарују са клијентским везама само за време трајања трансакције.
И у нашем оптерећењу, то је тачно. Али постоји неколико проблема.
Проблеми почињу када желите да дијагностикујете сесију, јер су све ваше долазне везе локалне. Сви су дошли са лоопбацк-ом и некако постаје тешко пратити сесију.
Наравно, можете користити апплицатион_наме_адд_хост. Ово је начин на страни избацивача да додате ИП адресу апликацији_наме. Али апплицатион_наме је постављено додатном везом.
На овом графикону, где су жута линија стварни захтеви, а где су плава линија захтеви који лете у базу података. А ова разлика је управо у инсталацији апликације_наме, која је потребна само за праћење, али уопште није бесплатна.
Поред тога, у Боунцер-у не можете ограничити један скуп, тј. број веза базе података по одређеном кориснику, по одређеној бази података.
чему ово води? Имате учитану услугу написану на Ц++ и негде у близини мали сервис на чвору који не ради ништа страшно са базом података, али њен драјвер полуди. Отвара 20 веза и све остало ће чекати. Чак је и ваш код нормалан.
Ми смо, наравно, написали малу закрпу за Боунцер која је додала ову поставку, тј. ограничавање клијената у базен.
То би било могуће урадити на страни Постгреса, односно ограничити улоге у бази података бројем конекција.
Али онда губите способност да разумете зашто немате везе са сервером. ПгБоунцер не даје грешку у вези, увек враћа исте информације. И не можете да разумете: можда се ваша лозинка променила, можда се база података једноставно изгубила, можда нешто није у реду. Али нема дијагнозе. Ако сесија не може да се успостави, нећете знати зашто се не може успоставити.
У одређеном тренутку погледате графиконе апликација и видите да апликација не ради.
Погледајте врх и видите да је Боунцер једнонитни. Ово је прекретница у животу службе. Схватате да сте се спремали да скалирате базу података за годину и по дана, и морате да скалирате поолер.
Дошли смо до закључка да нам треба више ПгБоунцера.
Боунцер је мало закрпљен.
И направили су тако да се неколико Боунцерс-а може подићи поновним коришћењем ТЦП порта. А оперативни систем аутоматски преноси долазне ТЦП везе између њих користећи кружни рад.
Ово је транспарентно за клијенте, што значи да изгледа као да имате један Боунцер, али имате фрагментацију неактивних веза између покренутих Боунцер-а.
И у одређеном тренутку можете приметити да ова 3 избацивача поједу своје језгро за 100%. Треба вам доста избацивача. Зашто?
Зато што имате ТЛС. Имате шифровану везу. А ако мерите Постгрес са и без ТЛС-а, открићете да број успостављених веза опада за скоро два реда величине са омогућеном шифровањем, јер ТЛС руковање троши ресурсе процесора.
А на врху можете видети доста криптографских функција које се извршавају када постоји талас долазних веза. Пошто наш примарни може да прелази између зона доступности, талас долазних веза је прилично типична ситуација. То јест, из неког разлога стари примарни је био недоступан, цело оптерећење је послато у други центар података. Сви ће доћи да се поздраве са ТЛС-ом у исто време.
И велики број ТЛС руковања можда више неће поздравити избацивача, већ ће му стиснути грло. Због истека времена, талас долазних веза може постати непригушен. Ако поново покушате са базом без експоненцијалног одустајања, они неће долазити изнова и изнова у кохерентном таласу.
Ево примера 16 ПгБоунцерс-а који учитавају 16 језгара на 100%.
Дошли смо до каскаде ПгБоунцер. Ово је најбоља конфигурација која се може постићи на нашем оптерећењу са Боунцер-ом. Наши екстерни Боунцерс се користе за ТЦП руковање, а унутрашњи Боунцерс се користе за стварно удруживање, како не би превише фрагментирали спољне везе.
У овој конфигурацији могуће је глатко поновно покретање. Можете поново покренути свих ових 18 избацивача један по један. Али одржавање такве конфигурације је прилично тешко. Сисадмини, ДевОпс и људи који су заправо одговорни за овај сервер неће бити баш задовољни овим аранжманом.
Чини се да се сва наша побољшања могу промовисати у отворени код, али Боунцер није баш добро подржан. На пример, могућност покретања неколико ПгБоунцерс-а на једном порту је извршена пре месец дана. Постојао је захтев за повлачење са овом функцијом пре неколико година.
Или још један пример. У Постгресу можете отказати захтев који је у току слањем тајне на другу везу без непотребне аутентификације. Али неки клијенти једноставно пошаљу ресетовање ТЦП-а, односно прекидају мрежну везу. Шта ће Боунцер урадити? Неће ништа да уради. Наставиће да извршава захтев. Ако сте примили велики број конекција које су креирале базу података са малим захтевима, онда једноставно прекидање везе са Боунцер-ом неће бити довољно; такође морате да довршите оне захтеве који се покрећу у бази података.
Ово је закрпљено и овај проблем још није спојен са Боунцер-овим упстреамом.
И тако смо дошли до закључка да нам је потребан сопствени поолер конекција, који ће бити развијен, закрпљен, у којем се проблеми могу брзо исправити и који, наравно, мора бити вишенитни.
Вишенитност смо поставили као главни задатак. Морамо да будемо у стању да се носимо са таласом долазних ТЛС веза.
Да бисмо то урадили, морали смо да развијемо засебну библиотеку под називом Мацхинариум, која је дизајнирана да опише стања машине мрежне везе као секвенцијални код. Ако погледате либпк изворни код, видећете неке прилично сложене позиве који вам могу дати резултат и рећи: „Назови ме касније. Тренутно имам ИО за сада, али када ИО нестане, имаћу оптерећење на процесору.” А ово је шема на више нивоа. Мрежну комуникацију обично описује државни строј. Много правила попут „Ако сам раније примио заглавље пакета величине Н, сада чекам Н бајтова“, „Ако сам послао СИНЦ пакет, сада чекам пакет са метаподацима резултата.“ Резултат је прилично тежак, контраинтуитиван код, као да је лавиринт претворен у линијско скенирање. Направили смо тако да уместо државног строја, програмер описује главни пут интеракције у облику обичног императивног кода. Само у овом императивном коду треба да уметнете места где секвенцу извршавања треба прекинути чекањем података из мреже, проследујући контекст извршавања другој корутини (зелена нит). Овај приступ је сличан чињеници да у низу записујемо најочекивану путању у лавиринту, а затим јој додајемо гране.
Као резултат, имамо једну нит која прихвата ТЦП и кружно преноси ТПЦ везу многим радницима.
У овом случају, свака веза клијента увек ради на једном процесору. А ово вам омогућава да га учините погодним за кеширање.
И поред тога, мало смо побољшали прикупљање малих пакета у један велики пакет како бисмо растеретили системски ТЦП стек.
Поред тога, побољшали смо обједињавање трансакција у смислу да Одиссеи, када је конфигурисан, може послати ОТКАЗ и ПОВРАТАК у случају неуспјеха мрежне везе, тј. ако нико не чека на захтјев, Одиссеи ће рећи бази података да не покушава испунити захтев који може да троши драгоцене ресурсе.
И кад год је то могуће, одржавамо везе са истим клијентом. Ово избегава потребу да поново инсталирате апплицатион_наме_адд_хост. Ако је то могуће, онда не морамо додатно ресетовати параметре који су потребни за дијагностику.
Радимо у интересу Иандек.Цлоуд. А ако користите управљани ПостгреСКЛ и имате инсталиран спремиште везе, можете креирати логичку репликацију напоље, тј. оставите нас, ако желите, користећи логичку репликацију. Боунцер неће ослободити логички ток репликације споља.
Ово је пример подешавања логичке репликације.
Поред тога, имамо подршку за физичку репликацију напоље. У Цлоуд-у је то, наравно, немогуће, јер ће вам тада кластер дати превише информација о себи. Али у вашим инсталацијама, ако вам је потребна физичка репликација преко спремишта веза у Одиссеи-у, то је могуће.
Одиссеи има потпуно компатибилан надзор са ПгБоунцер-ом. Имамо исту конзолу која покреће скоро све исте команде. Ако нешто недостаје, пошаљите захтев за повлачење или барем проблем на ГитХуб-у и ми ћемо извршити потребне команде. Али већ имамо главну функционалност конзоле ПгБоунцер.
И, наравно, имамо прослеђивање грешака. Вратићемо грешку коју је пријавила база података. Добићете информацију зашто нисте укључени у базу података, а не само да нисте укључени у њу.
Ова функција је онемогућена у случају да вам је потребна 100% компатибилност са ПгБоунцер-ом. Можемо се понашати на исти начин као Боунцер, само да будемо сигурни.
Развој
Неколико речи о изворном коду Одисеје.
На пример, постоје команде „Пауза / Настави“. Обично се користе за ажурирање базе података. Ако треба да ажурирате Постгрес, онда га можете паузирати у спремишту веза, урадити пг_упграде, а затим наставити. А са стране клијента ће изгледати као да се база података једноставно успорава. Ову функционалност су нам донели људи из заједнице. Она још није замрзнута, али ускоро ће све бити. (већ замрзнуто)
- већ замрзнуто
Поред тога, једна од нових функција у ПгБоунцер-у је подршка за СЦРАМ Аутхентицатион, коју нам је такође донела особа која не ради у Иандек.Цлоуд. Обе су сложене функционалности и важне.
Зато бих желео да вам кажем од чега је направљена Одисеја, у случају да и ви сада желите да напишете мали код.
Имате изворну базу Одиссеи, која се ослања на две главне библиотеке. Киви библиотека је имплементација Постгрес протокола за поруке. То јест, изворни прото 3 Постгреса су стандардне поруке које фронт-енд и бацк-енд могу да размењују. Имплементирају се у библиотеци Киви.
Библиотека Мацхинариум је библиотека имплементације нити. Мали фрагмент овог Мацхинариум-а написан је асемблерским језиком. Али немојте бити узнемирени, има само 15 редова.
Архитектура Одисеје. Постоји главна машина на којој се покрећу корутине. Ова машина имплементира прихватање долазних ТЦП веза и њихову дистрибуцију међу радницима.
Руковалац за неколико клијената може да ради у оквиру једног радника. Главна нит такође покреће конзолу и обраду цроне задатака за брисање веза које више нису потребне у групи.
Одиссеи је тестиран коришћењем стандардног Постгрес тест пакета. Само покрећемо проверу инсталације кроз Боунцер и кроз Одиссеи, добијамо нулл див. Постоји неколико тестова везаних за форматирање датума који не пролазе потпуно исто у Боунцер и Одиссеи.
Поред тога, постоји много возача који имају сопствено тестирање. А ми користимо њихове тестове да тестирамо Одисеју.
Поред тога, због наше каскадне конфигурације, морамо да тестирамо различите пакете: Постгрес + Одиссеи, ПгБоунцер + Одиссеи, Одиссеи + Одиссеи да бисмо били сигурни да ако Одиссеи заврши у неком од делова каскаде, такође и даље ради као што очекујемо.
Раке
У производњи користимо Одисеј. И не би било фер ако бих рекао да све функционише. Не, односно да, али не увек. На пример, у производњи је све функционисало, а онда су наши пријатељи из ПостгреСКЛ Профессионал дошли и рекли да имамо цурење меморије. Заиста јесу, исправили смо их. Али било је једноставно.
Затим смо открили да спремиште везе има долазне ТЛС везе и одлазне ТЛС везе. А за везе су потребни клијентски сертификати и сертификати сервера.
Сертификати Боунцер и Одиссеи сервера се поново читају њиховим пцацхе-ом, али клијентски сертификати не морају бити поново читани из пцацхе-а, јер наш скалабилни Одиссеи на крају наилази на системске перформансе читања овог сертификата. Ово нас је изненадило, јер му није требало дуго да се одупре. У почетку се линеарно скалирао, али након 20 долазних истовремених веза овај проблем се показао.
Плуггабле Аутхентицатион Метход је могућност аутентификације помоћу уграђених Лунук алата. У ПгБоунцер-у је имплементиран на такав начин да постоји посебна нит која чека одговор од ПАМ-а и постоји главна ПгБоунцер нит која сервисира тренутну везу и може од њих тражити да живе у ПАМ нити.
Ово нисмо спровели из једног једноставног разлога. Имамо много нити. Зашто нам је ово потребно?
Ово на крају може створити проблеме у томе што ако имате ПАМ аутентификацију и не-ПАМ аутентификацију, онда велики талас ПАМ аутентикације може значајно одложити не-ПАМ аутентификацију. Ово је једна од оних ствари које нисмо поправили. Али ако желите да то поправите, можете то учинити.
Други рак је био да имамо једну нит која прихвата све долазне везе. А затим се пребацују у радничку групу, где ће се одржати ТЛС руковање.
Закључак, ако имате кохерентан талас од 20 мрежних веза, све ће бити прихваћене. А на страни клијента либпк ће почети да извештава о временским ограничењима. Подразумевано изгледа да је 000 секунде.
Ако сви не могу да уђу у базу података у исто време, онда не могу да уђу у базу података, јер се све ово може покрити неекспоненцијалним поновним покушајем.
Дошли смо до закључка да смо ову шему копирали из ПгБоунцер-а са чињеницом да имамо смањење броја ТЦП веза на које прихватамо.
Ако видимо да прихватамо везе, али они на крају немају времена за руковање, стављамо их у ред да не троше ЦПУ ресурсе. То доводи до чињенице да се истовремено руковање можда неће извршити за све пристигле везе. Али ће бар неко ући у базу података, чак и ако је оптерећење прилично велико.
putokaz
Шта бисте волели да видите у будућности у Одисеји? Шта смо спремни да сами развијамо и шта очекујемо од заједнице?
Од августа 2019.
Овако је изгледала мапа пута Одисеје у августу:
- Желели смо СЦРАМ и ПАМ аутентификацију.
- Хтели смо да проследимо захтеве за читање у стање приправности.
- Желео бих поновно покретање на мрежи.
- И могућност паузе на серверу.
Половина ове мапе пута је завршена, а не ми. И ово је добро. Хајде да разговарамо о томе шта је остало и додајмо још.
? Имамо реплике које ће једноставно загрејати ваздух без извршавања захтева. Потребни су нам да обезбеде прелазак на грешку и пребацивање. У случају проблема у неком од дата центара, желео бих да их заокупим неким корисним послом. Зато што не можемо да конфигуришемо исте централне процесоре, исту меморију другачије, јер у супротном репликација неће радити.
У принципу, у Постгресу, почевши од 10, могуће је навести сессион_аттрс приликом повезивања. Можете навести све хостове базе података у вези и рећи зашто идете у базу података: само за писање или читање. И сам возач ће изабрати првог домаћина на листи који му се највише допада, који испуњава захтеве сессион_аттрс-а.
Али проблем са овим приступом је што не контролише кашњење у репликацији. Можда имате неку реплику која је заостајала за неприхватљиво време за вашу услугу. Да бисмо омогућили потпуно функционално извршавање упита за читање на реплици, у суштини морамо да подржимо Одиссеи-ову способност да се не покреће када се не може прочитати.
Одисеј мора с времена на време да иде у базу података и тражи удаљеност репликације од примарног. А ако је достигао граничну вредност, не дозволите нове захтеве у бази података, реците клијенту да треба поново да покрене везе и, евентуално, да изабере други хост за извршавање захтева. Ово ће омогућити бази података да брзо врати кашњење репликације и поново се врати да одговори са захтевом.
Тешко је дати временски оквир за имплементацију, јер је отвореног кода. Али, надам се, не 2,5 године као моје колеге из ПгБоунцера. Ово је карактеристика коју бих волео да видим у Одисеји.
. Сада можете креирати припремљену изјаву на два начина. Прво, можете извршити СКЛ команду, односно "припремљено". Да бисмо разумели ову СКЛ команду, морамо да научимо да разумемо СКЛ на страни избацивача. Ово би било претерано, јер је превише, пошто нам је потребан цео парсер. Не можемо рашчланити сваку СКЛ команду.
Али постоји припремљена изјава на нивоу протокола поруке на прото3. И то је место када информација да се припрема припремљена изјава долази у структурираном облику. И могли бисмо да подржимо схватање да је на некој серверској вези клијент тражио да направи припремљене изјаве. Чак и ако је трансакција затворена, и даље морамо да одржавамо повезаност између сервера и клијента.
Али овде долази до неслагања у дијалогу, јер неко каже да треба да разумете какве је припремљене изјаве клијент креирао и поделите серверску везу између свих клијената који су креирали ову серверску везу, односно који су креирали тако припремљену изјаву.
Андрес Фројнд је рекао да ако вам дође клијент који је већ направио тако припремљену изјаву у другој серверској вези, онда је креирајте за њега. Али изгледа да је мало погрешно извршавати упите у бази података уместо клијента, али са становишта програмера који пише протокол за интеракцију са базом података, било би згодно да му се једноставно да мрежна веза у којој постоји тако припремљен упит.
И још једна карактеристика коју треба да применимо. Сада имамо праћење компатибилно са ПгБоунцер-ом. Можемо да вратимо просечно време извршења упита. Али просечно време је просечна температура у болници: неко је хладно, неко топло - у просеку су сви здрави. То није тачно.
Морамо да имплементирамо подршку за перцентиле, што би указивало да постоје спори упити који троше ресурсе и који би праћење учинили прихватљивијим.
Најважније је да желим верзију 1.0 (верзија 1.1 је већ објављена). Чињеница је да је Одиссеи сада у верзији 1.0рц, односно кандидат за издавање. И сви проблеми које сам навео су решени потпуно истом верзијом, осим цурења меморије.
Шта ће верзија 1.0 значити за нас? Ми преносимо Одисеју у наше базе. Већ ради на нашим базама података, али када достигне тачку од 1 захтева у секунди, онда можемо рећи да је ово издана верзија и да је ово верзија која се може назвати 000.
Неколико људи у заједници је тражило да верзија 1.0 укључује паузу и СЦРАМ. Али то ће значити да ћемо морати да пустимо следећу верзију у производњу, јер ни СЦРАМ ни пауза још нису уништени. Али, највероватније, ово питање ће бити решено прилично брзо.
Чекам твој захтев за повлачење. Такође бих волео да чујем које проблеме имате са Боунцер-ом. Хајде да разговарамо о њима. Можда можемо да имплементирамо неке функције које су вам потребне.
Ово је крај мог дела, желео бих да вас саслушам. Хвала вам!
pitanja
Ако поставим сопствено име_апликације, да ли ће бити исправно прослеђено, укључујући и обједињавање трансакција у Одисеји?
Одисеја или избацивач?
У Одисеји. У Боунцер-у се баца.
Направићемо сет.
А ако моја права веза скочи на друге везе, да ли ће бити пренета?
Направићемо скуп свих параметара који су наведени на листи. Не могу да кажем да ли је име_апликације на овој листи. Мислим да сам га видео тамо. Поставићемо све исте параметре. Са једним захтевом, сет ће урадити све што је клијент инсталирао приликом покретања.
Хвала, Андреј, на извештају! Добар извештај! Драго ми је што се Одисеја сваким минутом развија све брже. Желим да наставим овако. Већ смо вас замолили да имате везу са више извора података тако да Одиссеи може истовремено да се повеже са различитим базама података, тј. на главни славе, а затим се аутоматски повезује са новим мастером након грешке.
Да, изгледа да се сећам ове расправе. Сада постоји неколико складишта. Али између њих нема пребацивања. Са наше стране, морамо испитати сервер да ли је још увек жив и разумети да је дошло до грешке, ко ће позвати пг_рецовери. Имам стандардан начин разумевања да нисмо дошли код мајстора. И треба ли се некако разумети из грешака или шта? Односно, идеја је занимљива, о њој се расправља. Напишите још коментара. Ако имате раднике који знају Ц, онда је то сјајно.
Питање скалирања преко реплика нас такође занима, јер желимо да усвајање реплицираних кластера учинимо што једноставнијим за програмере апликација. Али овде бих желео више коментара, односно тачно како то учинити, како то учинити добро.
Питање је и о репликама. Испоставило се да имате мајстора и неколико реплика. И јасно је да ређе иду у реплику него код мајстора за везе, јер могу имати разлике. Рекли сте да разлика у подацима може бити таква да неће задовољити ваше пословање и да нећете ићи тамо док се не реплицирају. Истовремено, ако нисте отишли тамо дуго времена, а затим почели да идете, онда подаци који су вам потребни неће бити одмах доступни. То јест, ако стално идемо до мастера, онда се кеш меморија тамо загрева, али у реплици кеш мало заостаје.
Да то је истина. Пцацхе неће имати блокове података које желите, прави кеш неће имати информације о табелама које желите, планови неће имати рашчлањене упите, неће бити ништа.
А кад имаш неку врсту кластера, па ту додаш нову реплику, онда док се покрене све је лоше у њему, односно повећава свој кеш.
Имам идеју. Исправан приступ би био да се прво покрене мали проценат упита на реплици, што би загрејало кеш меморију. Грубо речено, имамо услов да за мајстором не смемо да заостајемо више од 10 секунди. И овај услов није укључен у један талас, већ глатко за неке клијенте.
Да, повећајте тежину.
Ово је добра идеја. Али прво морамо да спроведемо ово гашење. Прво морамо да искључимо, а затим ћемо размислити како да упалимо. Ово је одлична функција за несметано омогућавање.
Нгинк има ову опцију slowly start у кластеру за сервер. И он постепено повећава оптерећење.
Да, одлична идеја, пробаћемо је када стигнемо до ње.
Извор: ввв.хабр.цом