Бәріңе сәлем! Менің атым Дмитрий Самсонов, мен Одноклассники сайтында жетекші жүйелік әкімші болып жұмыс істеймін. Бізде 7 мыңнан астам физикалық серверлер, бұлтта 11 мың контейнер және әртүрлі конфигурацияларда 200 түрлі кластерді құрайтын 700 қолданбалар бар. Серверлердің басым көпшілігінде CentOS 7 жұмыс істейді.
14 жылдың 2018 тамызында FragmentSmack осалдығы туралы ақпарат жарияланды.
() және SegmentSmack (). Бұл желілік шабуыл векторы және жеткілікті жоғары балл (7.5) бар осалдықтар, бұл ресурстардың таусылуына (CPU) байланысты қызмет көрсетуден бас тартуға (DoS) қауіп төндіреді. Ол кезде FragmentSmack үшін ядроны түзету ұсынылмады, оның үстіне ол осалдық туралы ақпарат жарияланғаннан кейінірек пайда болды. SegmentSmack жою үшін ядроны жаңарту ұсынылды. Жаңарту пакетінің өзі сол күні шығарылды, оны орнату ғана қалды.
Жоқ, біз ядроны жаңартуға мүлдем қарсы емеспіз! Дегенмен, нюанстар бар ...
Өндірістегі ядроны қалай жаңартамыз
Жалпы, күрделі ештеңе жоқ:
- Пакеттерді жүктеп алу;
- Оларды бірқатар серверлерге орнатыңыз (оның ішінде біздің бұлтты орналастыратын серверлер);
- Еш нәрсе бұзылмағанына көз жеткізіңіз;
- Барлық стандартты ядро параметрлері қатесіз қолданылғанына көз жеткізіңіз;
- Бірнеше күн күтіңіз;
- Сервер жұмысын тексеру;
- Жаңа серверлерді орналастыруды жаңа ядроға ауыстыру;
- Барлық серверлерді деректер орталығы бойынша жаңарту (мәселелер туындаған жағдайда пайдаланушыларға әсерін азайту үшін бір уақытта бір деректер орталығы);
- Барлық серверлерді қайта жүктеңіз.
Бізде бар ядролардың барлық тармақтары үшін қайталаңыз. Қазіргі уақытта ол:
- Stock CentOS 7 3.10 - қарапайым серверлердің көпшілігі үшін;
- Ваниль 4.19 - біздікі , өйткені бізге BFQ, BBR және т.б. қажет;
- Elrepo ядросы-мл 5.2 - үшін , өйткені 4.19 бұрын өзін тұрақсыз ұстайтын, бірақ бірдей мүмкіндіктер қажет.
Сіз болжағандай, мыңдаған серверлерді қайта жүктеу ең ұзақ уақытты алады. Барлық осалдықтар барлық серверлер үшін маңызды емес болғандықтан, біз тек Интернеттен тікелей қол жеткізуге болатындарды ғана қайта жүктейміз. Бұлтта икемділікті шектемеу үшін біз сыртқы қол жетімді контейнерлерді жаңа ядросы бар жеке серверлерге байланыстырмаймыз, бірақ барлық хосттарды ерекшеліксіз қайта жүктейміз. Бақытымызға орай, бұл жерде процедура қарапайым серверлерге қарағанда қарапайым. Мысалы, азаматтығы жоқ контейнерлер қайта жүктеу кезінде жай ғана басқа серверге ауыса алады.
Дегенмен, әлі де көп жұмыс бар және ол бірнеше аптаға созылуы мүмкін, ал жаңа нұсқада қандай да бір ақаулар болса, бірнеше айға дейін созылуы мүмкін. Шабуылшылар мұны өте жақсы түсінеді, сондықтан оларға В жоспары қажет.
FragmentSmack/SegmentSmack. Шешім
Бақытымызға орай, кейбір осалдықтар үшін мұндай В жоспары бар және ол уақытша шешім деп аталады. Көбінесе бұл ықтимал әсерді азайтуға немесе осалдықтарды пайдалануды толығымен жоюға болатын ядро/қолданба параметрлерін өзгерту.
FragmentSmack/SegmentSmack жағдайында бұл уақытша шешім:
«Net.ipv4.ipfrag_high_thresh және net.ipv3.ipfrag_low_thresh (және олардың ipv4 net.ipv4.ipfrag_high_thresh және net.ipv6.ipfrag_low_thresh үшін ұқсастары) ішіндегі 6МБ және 6МБ әдепкі мәндерін тиісінше 256 кБ немесе 192 кБ етіп өзгертуге болады. төмен. Сынақтар аппараттық құралға, параметрлерге және шарттарға байланысты шабуыл кезінде процессорды пайдаланудың аз немесе айтарлықтай төмендеуін көрсетеді. Дегенмен, ipfrag_high_thresh=262144 байтқа байланысты кейбір өнімділікке әсер етуі мүмкін, себебі бір уақытта қайта құрастыру кезегіне тек екі 64K фрагмент сыя алады. Мысалы, үлкен UDP пакеттерімен жұмыс істейтін қолданбалардың бұзылу қаупі бар«.
Параметрлердің өздері былай сипатталады:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Бізде өндірістік қызметтерде үлкен UDP жоқ. LAN желісінде фрагменттелген трафик жоқ, WAN желісінде бөлшектелген трафик бар, бірақ маңызды емес. Ешқандай белгілер жоқ - сіз уақытша шешім шығара аласыз!
FragmentSmack/SegmentSmack. Бірінші қан
Біз кездестірген бірінші мәселе, бұлттық контейнерлер кейде жаңа параметрлерді ішінара ғана қолданды (тек ipfrag_low_thresh), ал кейде мүлде қолданбады - олар бастапқыда жай ғана бұзылды. Мәселені тұрақты түрде шығару мүмкін болмады (барлық параметрлер еш қиындықсыз қолмен қолданылды). Контейнердің неліктен басында апатқа ұшырағанын түсіну оңай емес: қателер табылмады. Бір нәрсе анық болды: параметрлерді кері қайтару контейнер апаттарымен байланысты мәселені шешеді.
Неліктен хостта Sysctl қолдану жеткіліксіз? Контейнер өзінің арнайы желілік атау кеңістігінде тұрады, сондықтан кем дегенде контейнердегі деректер хосттан өзгеше болуы мүмкін.
Sysctl параметрлері контейнерде нақты қалай қолданылады? Біздің контейнерлеріміз артықшылықсыз болғандықтан, контейнердің өзіне кіру арқылы кез келген Sysctl параметрін өзгерте алмайсыз - сізде жай ғана құқықтарыңыз жоқ. Контейнерлерді іске қосу үшін сол кезде бұлт Docker (қазір ). Жаңа контейнердің параметрлері Docker-ке API арқылы, соның ішінде қажетті Sysctl параметрлері арқылы жіберілді.
Нұсқаларды іздеу кезінде Docker API барлық қателерді қайтармағаны анықталды (кем дегенде 1.10 нұсқасында). Контейнерді «докерлік іске қосу» арқылы іске қосуға тырысқанда, біз ең болмағанда бір нәрсені көрдік:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
Параметр мәні жарамсыз. Бірақ неге? Неліктен ол кейде жарамсыз? Docker Sysctl параметрлерінің қолданылу тәртібіне кепілдік бермейтіні анықталды (соңғы тексерілген нұсқасы - 1.13.1), сондықтан кейде ipfrag_low_thresh әлі 256М болғанда ipfrag_high_thresh 3K мәніне орнатуға тырысады, яғни жоғарғы шегі төмен болды. қатеге әкелетін төменгі шекке қарағанда.
Ол кезде біз контейнерді іске қосқаннан кейін қайта конфигурациялаудың өз механизмін қолдандық (контейнерді кейін мұздату). арқылы контейнердің аттар кеңістігіндегі пәрмендерді орындау ), сонымен қатар біз бұл бөлікке Sysctl жазу параметрлерін қостық. Мәселе шешілді.
FragmentSmack/SegmentSmack. Бірінші қан 2
Бұлтта уақытша шешімді пайдалануды түсінуге үлгермей тұрып, пайдаланушылардан алғашқы сирек шағымдар түсе бастады. Сол кезде алғашқы серверлерде Workaround қолданыла бастағаннан бері бірнеше апта өткен болатын. Бастапқы тексеру көрсеткендей, шағымдар бұл қызметтердің барлық серверлеріне емес, жеке қызметтерге қатысты түскен. Мәселе қайтадан өте белгісіз болды.
Ең алдымен, біз, әрине, Sysctl параметрлерін кері қайтаруға тырыстық, бірақ бұл ешқандай нәтиже бермеді. Сервермен және қолданба параметрлерімен әртүрлі манипуляциялар да көмектеспеді. Қайта жүктеу көмектесті. Linux жүйесін қайта жүктеу ескі күндерде Windows үшін әдеттегідей табиғи емес. Дегенмен, бұл көмектесті және біз оны Sysctl-де жаңа параметрлерді қолдану кезінде «ядро ақауы» деп атадық. Бұл қаншалықты жеңіл болды ...
Үш аптадан кейін мәселе қайталанды. Бұл серверлердің конфигурациясы өте қарапайым болды: Nginx прокси/теңгерім режимінде. Көлік көп емес. Жаңа кіріспе ескерту: клиенттердегі 504 қатенің саны күн сайын артып келеді (). График осы қызмет үшін күніне 504 қатенің санын көрсетеді:
Барлық қателер шамамен бірдей серверде - бұлттағы қате туралы. Осы сервердегі бума фрагменттері үшін жадты тұтыну графигі келесідей болды:
Бұл операциялық жүйе графиктеріндегі мәселенің ең айқын көріністерінің бірі. Бұлтта дәл сол уақытта QoS (трафикті басқару) параметрлері бар тағы бір желі ақауы түзетілді. Пакет фрагменттері үшін жадты тұтыну графигінде ол дәл солай көрінді:
Болжам қарапайым болды: егер олар графиктерде бірдей көрінсе, онда олардың себебі бірдей. Сонымен қатар, жадтың бұл түріне қатысты кез келген проблемалар өте сирек кездеседі.
Түзетілген мәселенің мәні біз QoS жүйесінде әдепкі параметрлері бар fq пакеттік жоспарлаушыны пайдаландық. Әдепкі бойынша, бір қосылым үшін ол кезекке 100 пакет қосуға мүмкіндік береді, ал кейбір қосылымдар арна тапшылығы жағдайында кезекті сыйымдылыққа дейін бітеп тастады. Бұл жағдайда пакеттер жойылады. tc статистикасында (tc -s qdisc) оны келесідей көруге болады:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
“464545 flows_plimit” – бір қосылымның кезек шегінен асып кетуіне байланысты жойылған пакеттер, ал “төменделген 464545” – осы жоспарлаушының барлық түсірілген пакеттерінің қосындысы. Кезек ұзындығын 1 мыңға дейін ұлғайтып, контейнерлерді қайта іске қосқаннан кейін мәселе туындауын тоқтатты. Сіз отыруға және смузи ішуге болады.
FragmentSmack/SegmentSmack. Соңғы қан
Біріншіден, ядродағы осалдықтар туралы хабарландырудан бірнеше ай өткен соң, ақырында FragmentSmack үшін түзету пайда болды (тамыздағы хабарландырумен бірге тек SegmentSmack үшін түзету шыққанын еске саламын), бұл бізге Workaround-тан бас тартуға мүмкіндік берді, бұл бізге көп қиындық тудырды. Осы уақыт ішінде біз кейбір серверлерді жаңа ядроға көшіруге үлгердік, енді басынан бастау керек болды. Неліктен біз FragmentSmack түзетуін күтпей-ақ ядроны жаңарттық? Мәселе мынада, бұл осалдықтардан қорғау процесі CentOS-тың өзін жаңарту процесімен сәйкес келді (және біріктірілді) (бұл тек ядроны жаңартудан да көп уақытты алады). Сонымен қатар, SegmentSmack - аса қауіпті осалдық және оны түзету бірден пайда болды, сондықтан бәрібір мағынасы болды. Дегенмен, CentOS жүйесіндегі ядроны жай ғана жаңарта алмадық, себебі CentOS 7.5 кезінде пайда болған FragmentSmack осалдығы тек 7.6 нұсқасында түзетілген, сондықтан 7.5 нұсқасына жаңартуды тоқтатып, 7.6 нұсқасына жаңарту арқылы барлығын қайта бастауға тура келді. Және бұл да болады.
Екіншіден, пайдаланушылардың проблемалар туралы сирек шағымдары бізге қайтарылды. Енді біз олардың барлығы клиенттерден кейбір серверлерімізге файлдарды жүктеп салумен байланысты екенін анық білеміз. Сонымен қатар, осы серверлер арқылы жүктеп салулардың жалпы массасынан өте аз саны өтті.
Жоғарыдағы оқиғадан еске түсіргендей, Sysctl-ді кері қайтару көмектеспеді. Қайта жүктеу көмектесті, бірақ уақытша.
Sysctl-ге қатысты күдік жойылмады, бірақ бұл жолы мүмкіндігінше көбірек ақпарат жинау қажет болды. Сондай-ақ, не болып жатқанын дәлірек зерттеу үшін клиентке жүктеп салу мәселесін қайта шығару мүмкіндігінің үлкен жетіспеушілігі болды.
Барлық қолда бар статистика мен журналдарды талдау бізді не болып жатқанын түсінуге жақындата алмады. Белгілі бір байланысты «сезіну» үшін мәселені қайта шығару қабілетінің өткір жетіспеушілігі болды. Ақырында, әзірлеушілер қосымшаның арнайы нұсқасын қолдана отырып, Wi-Fi арқылы қосылған кезде сынақ құрылғысындағы мәселелердің тұрақты шығарылуына қол жеткізді. Бұл тергеудегі жаңалық болды. Клиент Nginx-ке қосылды, ол серверге прокси-сервермен қосылды, ол біздің Java қолданбасы болды.
Мәселелерге арналған диалог келесідей болды (Nginx прокси жағында бекітілген):
- Клиент: файлды жүктеп алу туралы ақпаратты алуды сұрау.
- Java сервері: жауап.
- Клиент: файлы бар POST.
- Java сервері: қате.
Бұл ретте Java сервері журналға клиенттен 0 байт деректер алынғанын жазады, ал Nginx проксиі сұраудың 30 секундтан астам уақыт алғанын жазады (30 секунд – клиент қолданбасының күту уақыты). Неліктен күту уақыты және неге 0 байт? HTTP тұрғысынан бәрі қажетінше жұмыс істейді, бірақ файлы бар POST желіден жоғалып кеткен сияқты. Сонымен қатар, ол клиент пен Nginx арасында жоғалады. Tcpdump-пен қаруланатын кез келді! Бірақ алдымен желі конфигурациясын түсіну керек. Nginx проксиі L3 балансының артында . Туннельдеу пакеттерді L3 балансизаторынан серверге жеткізу үшін қолданылады, ол пакеттерге өз тақырыптарын қосады:
Бұл жағдайда желі бұл серверге Vlan-тегтелген трафик түрінде келеді, ол сонымен қатар пакеттерге өз өрістерін қосады:
Және бұл трафикті де фрагменттелген болуы мүмкін (өтпе жолдан тәуекелдерді бағалау кезінде біз айтқан кіріс фрагменттелген трафиктің сол аз пайызы), ол тақырыптардың мазмұнын да өзгертеді:
Тағы да: пакеттер Vlan тегімен инкапсулирленген, туннельмен қапталған, фрагменттелген. Мұның қалай болатынын жақсырақ түсіну үшін клиенттен Nginx проксиіне дейінгі пакеттік маршрутты бақылап көрейік.
- Пакет L3 балансизаторына жетеді. Деректер орталығында дұрыс бағыттау үшін пакет туннельге инкапсуляцияланады және желі картасына жіберіледі.
- Пакет + туннель тақырыптары MTU-ға сәйкес келмейтіндіктен, пакет фрагменттерге кесіліп, желіге жіберіледі.
- L3 теңгерімінен кейінгі қосқыш пакетті алған кезде оған Vlan тегін қосады және оны жібереді.
- Nginx проксиінің алдындағы қосқыш (порт параметрлері негізінде) сервердің Vlan-инкапсуляцияланған пакетті күтіп тұрғанын көреді, сондықтан оны Vlan тегін жоймай-ақ жібереді.
- Linux жеке бумалардың фрагменттерін алып, оларды бір үлкен бумаға біріктіреді.
- Содан кейін пакет Vlan интерфейсіне жетеді, онда одан бірінші қабат жойылады - Vlan инкапсуляциясы.
- Содан кейін Linux оны туннель интерфейсіне жібереді, онда одан басқа қабат жойылады - туннель инкапсуляциясы.
Қиындық осының барлығын tcpdump параметріне беру болып табылады.
Соңынан бастайық: vlan және туннель инкапсуляциясы жойылған клиенттерден таза (қажетсіз тақырыптарсыз) IP пакеттері бар ма?
tcpdump host <ip клиента>
Жоқ, серверде мұндай пакеттер болған жоқ. Сондықтан мәселе ертерек болуы керек. Тек Vlan инкапсуляциясы жойылған пакеттер бар ма?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx - hex пішіміндегі клиенттің IP мекенжайы.
32:4 — туннель пакетінде SCR IP жазылған өрістің мекенжайы мен ұзындығы.
Өріс мекенжайын қатал күшпен таңдау керек болды, өйткені Интернетте олар 40, 44, 50, 54 туралы жазады, бірақ онда IP мекенжайы болмады. Сондай-ақ, сіз он алтылықтағы пакеттердің біреуін (tcpdump ішіндегі -xx немесе -XX параметрі) қарап, өзіңіз білетін IP мекенжайын есептей аласыз.
Vlan және туннель инкапсуляциясы жойылмаған пакет фрагменттері бар ма?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Бұл сиқыр бізге барлық фрагменттерді, соның ішінде соңғысын көрсетеді. Мүмкін, бірдей нәрсені IP арқылы сүзуге болады, бірақ мен тырыспадым, өйткені мұндай пакеттер онша көп емес, ал маған қажет пакеттер жалпы ағында оңай табылды. Міне олар:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Бұл фотосуреті бар бір пакеттің екі фрагменті (бір ID 53652) (бірінші бумада Exif сөзі көрінеді). Қоқыс орындарында біріктірілген түрде емес, осы деңгейде пакеттер бар болғандықтан, мәселе құрастыруда анық. Ақырында, мұның құжаттық дәлелі бар!
Пакеттік декодер құрастыруға кедергі болатын ақауларды анықтаған жоқ. Мұнда сынап көрдім: . Бастапқыда, бірдеңені толтыруға тырысқанда, декодер пакет пішімін ұнатпайды. Srcmac және Ethertype арасында қосымша екі октет бар екені белгілі болды (фрагменттік ақпаратқа қатысы жоқ). Оларды жойғаннан кейін декодер жұмыс істей бастады. Дегенмен, ол ешқандай проблемаларды көрсетпеді.
Біреу не айтса да, сол Sysctl-ден басқа ештеңе табылмады. Масштабты түсіну және одан әрі әрекеттерді шешу үшін проблемалық серверлерді анықтаудың жолын табу ғана қалды. Қажетті есептегіш жеткілікті тез табылды:
netstat -s | grep "packet reassembles failed”
Ол сондай-ақ snmpd ішінде OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
«IP қайта құрастыру алгоритмі анықтаған сәтсіздіктер саны (кез келген себеппен: күту уақыты аяқталды, қателер және т.б.).
Мәселе зерттелген серверлер тобының ішінде бұл есептегіш екеуінде жылдамырақ, екеуінде баяу өсті және екеуінде мүлдем өспеді. Бұл есептегіштің динамикасын Java серверіндегі HTTP қателерінің динамикасымен салыстыру корреляцияны анықтады. Яғни, есептегішті бақылауға болатын.
Мәселелердің сенімді индикаторына ие болу өте маңызды, сондықтан Sysctl кері қайтару көмектесетінін дәл анықтауға болады, өйткені алдыңғы оқиғадан біз оны қолданбадан бірден түсінуге болмайтынын білеміз. Бұл көрсеткіш пайдаланушылар оны таппай тұрып, өндірістегі барлық проблемалық аймақтарды анықтауға мүмкіндік береді.
Sysctl кері қайтарылғаннан кейін бақылау қателері тоқтатылды, осылайша проблемалардың себебі дәлелденді, сонымен қатар кері қайтару көмектеседі.
Біз басқа серверлердегі фрагментация параметрлерін қалпына келтірдік, мұнда жаңа мониторинг іске қосылды және бір жерде біз фрагменттер үшін бұрынғы әдепкіден гөрі көбірек жад бөлдік (бұл UDP статистикасы болды, оның ішінара жоғалуы жалпы фонда байқалмайды) .
Ең маңызды сұрақтар
Неліктен пакеттер L3 теңгерімінде фрагменттелген? Пайдаланушылардан балансерлерге келетін пакеттердің көпшілігі SYN және ACK болып табылады. Бұл пакеттердің өлшемдері кішкентай. Бірақ мұндай пакеттердің үлесі өте үлкен болғандықтан, олардың фонында біз фрагментациялай бастаған үлкен пакеттердің болуын байқамадық.
Мұның себебі бұзылған конфигурация сценарийі болды Vlan интерфейстері бар серверлерде (ол кезде өндірісте тегтелген трафикі бар серверлер өте аз болды). Advmss клиентке біздің бағыттағы пакеттердің көлемі кішірек болуы керек деген ақпаратты жеткізуге мүмкіндік береді, сондықтан оларға туннель тақырыптарын тіркегеннен кейін олар фрагменттелудің қажеті жоқ.
Неліктен Sysctl кері қайтару көмектеспеді, бірақ қайта жүктеу көмектесті? Sysctl кері қайтару бумаларды біріктіру үшін қолжетімді жад көлемін өзгертті. Сонымен қатар, фрагменттер үшін жадтың толып кету фактісінің өзі қосылымдардың баяулауына әкеліп соқтырды, бұл фрагменттердің кезекте ұзақ уақытқа кешіктірілуіне әкелді. Яғни, процесс циклдармен жүрді.
Қайта жүктеу жадты тазартты және бәрі ретіне оралды.
Шешімсіз істеу мүмкін болды ма? Иә, бірақ шабуыл жасалған жағдайда пайдаланушыларды қызметсіз қалдыру қаупі жоғары. Әрине, уақытша шешімді пайдалану әртүрлі мәселелерге, соның ішінде пайдаланушыларға арналған қызметтердің бірінің жұмысының баяулауына әкелді, бірақ соған қарамастан, біз әрекеттерді ақтады деп есептейміз.
Андрей Тимофеевке үлкен рахмет () тергеуді жүргізуге көмектескені үшін, сондай-ақ Алексей Креневке () - серверлердегі Centos және ядроларды жаңартудың титаникалық жұмысы үшін. Бұл жағдайда бірнеше рет басынан бастау керек болатын процесс, сондықтан ол көптеген айларға созылды.
Ақпарат көзі: www.habr.com