Серверлерімізді қатырған жоқ swap файлы

Қыркүйектің 24-інде өндірістік серверлердің бірі жауап беруін тоқтатты. Жүктеме теңестіргіші оны денсаулығы нашар деп белгіледі, ал бізнің қашықтан команда құралы оған қол жеткізе алмады, бірақ ештеңе құлаған жоқ және жадты тым көп пайдаланғаны үшін ешбір процесс өлтірілген жоқ. Сервер тозақта болды: swap кеңістігі жоқ және контейнерлерге машинада бар жадтан көбірек пайдалануға рұқсат етілгендіктен, Linux уақытын орындау үшін қажет файлдарды шығарумен және қайтадан оқумен өткізді, әрі ештеңеге жетпеді. Әр серверге 2 ГБ swap файлын қосу мәселені шешті. Ең қызықты сабақ денсаулық тексерулері туралы болды.

«Қатып қалу» қалай көрінді

• Жүктеме теңестіргішінің денсаулық тексерулері сол серверде уақыт бітті.
• AWS Systems Manager арқылы жіберілген командалар «Pending» күйінде тұрып қалды және ешқашан іске қосылмады.
• Журналдарда жадтың таусылуынан өлтірілген процесс жоқ еді. Ешбір процесс өлген жоқ.

Бір апта бұрын өндірісті жадысы 2 ГБ кішірек ARM серверлеріне көшірдік. Кішірек staging серверіміз де деплой кезінде контейнер бейнесін ашып жатқанда дәл солай қатып қалған.

Жад қатесі неге жоқ?

Linux процесті тек қайта алуға болатын жады таусылғанда ғана өлтіреді. Одан бұрын ол жадты page cache-тен алады — RAM-да сақталатын файлдардың көшірмелері, оның ішінде әр жұмыс істеп тұрған бағдарламаның коды.

Біздің серверлерде контейнерлердің шектеулерінің қосындысы шамамен 1,8 ГБ пайдаланылатын машинада шамамен 3,3 ГБ болды. Әдетте олардың бәрі бірдей шегіне жетпейді. Олар жеткенде ядро бағдарлама кодын кэштен шығарып, оны сол код қайта іске қосылған сәтте дискіден қайта оқуға мәжбүр болды. Бұл цикл — ауыстыру (thrashing) — машинаны жадтың таусылуы техникалық тұрғыдан болмаса да, толық жауап бермейтін етуі мүмкін. Сондықтан ештеңе өлтірілмейді және ештеңе қалпына келмейді.

Swap болмаса, ядрода бөлінген, бірақ сирек пайдаланылатын жадты қоятын жер жоқ, сондықтан оны кэштен алуға мәжбүр.

Түзету

Сервер бутстрап скрипті енді серверді іске қосқан немесе жөндеген сайын 2 ГБ swap файлын төмен swappiness параметрімен (10) жасайды. Төмен swappiness ядро жұмыс жадын RAM-да ұстағанды қалайды, бірақ сирек қолданылатын беттер дискіге көшуі мүмкін, бағдарлама кодын кэштен шығаруға мәжбүр етпей. Біз мұны өндірістің екі серверіне және staging-ке тікелей қолдандық, ал деплой құбыры әр өндірістік деплойда бутстрап скриптін қайта жариялайды, сондықтан ауыстырылған сервер де оны алады.

Бізді одан да көп алаңдатқан бөлік: денсаулығы нашар сервер қалды

Серверлер тобы EC2 денсаулық тексерулерін пайдаланды — «машина іске қосулы ма?» — жүктеме теңестіргішінің денсаулық тексерулерін емес — «сұрауларға жауап беріп жатыр ма?». Сондықтан жүктеме теңестіргіші бас тартқан сервер топқа қарағанда сау болып тұрды. Ол ешқашан ауыстырылмады. Өндіріс біреу байқап, екіншісін қайта жүктегенше бір серверде үнсіз жұмыс істеп тұрды.

Топты жүктеме теңестіргішінің денсаулық тексерулеріне ауыстыру оңай шешімдей көрінеді, бірақ бізде ол қиын: деплой кезінде серверлер әдейі өз денсаулық соңғы нүктесіне қате жауап береді, сонда теңестіруші оларды айналымнан шығарады (қараңыз: деплойлар қалай нөлдік 502-ге жетті). Сол белгі бойынша серверлерді ауыстыратын топ әр деплойдың ортасында оларды ауыстырар еді.

Сондықтан қазірге деплой тексеру тізіміне қадам қостық: әр деплойдан кейін тек деплой жұмысының өткенін ғана емес, жүктеме теңестірушісінде әр нысанның денсаулығын тексеріңіз. Егер серверге командалар «Pending» күйінде тұрып қалса, ол тозақта — оны қайта жүктеңіз; ол бұл кезде айналымнан шығып қалған.

Одан не алдық

• «Құлап тұрмау» «сау» дегенді білдірмейді. Тозақ ешқандай қате бермейді, тек серверді жауап бермейтін дәрежеде баяулатады.
• Кішкене серверлерге swap керек. Тіпті аз болса да, төмен swappiness-пен ядроға суық жадты қоятын орын береді.
• Жадтың шектеулері машина сыйымдылығынан асып кетсе, бұл — ставка. Кейде ұтылады. Қашан ставка жасағаныңызды біліңіз.
• Автомасштабтау қай денсаулық тексеруіне сенетінін біліңіз. «ВМ қосулы ма?» деп сұрайтын денсаулық тексеруі жұмысын тоқтатқан серверді ауыстырмайды.