गायब झालेली swap फाइल ज्यामुळे आमचे सर्व्हर गोठले

24 सप्टेंबर रोजी, आमच्यापैकी एक production सर्व्हर उत्तर देणे थांबवला. Load balancer ने त्याला unhealthy म्हणून चिन्हांकित केले आणि आमचे remote-command tool त्याच्यापर्यंत पोहोचू शकले नाही — पण काहीही crash झाले नव्हते आणि खूप मेमरी वापरल्याबद्दल कोणतीही प्रक्रिया मारली गेली नव्हती. सर्व्हर thrash करत होता: swap जागा नसल्यामुळे आणि कंटेनर्सना मशीनकडे असलेल्या मेमरीपेक्षा जास्त मेमरी वापरण्याची परवानगी असल्यामुळे, Linux आपला वेळ अशा फाइल्स बाहेर काढण्यात आणि पुन्हा वाचण्यात घालवत होते ज्या चालण्यासाठी आवश्यक होत्या, आणि प्रत्यक्षात जवळजवळ काहीच प्रगती करत नव्हते. प्रत्येक सर्व्हरवर 2 GB ची swap फाइल जोडल्यावर ते ठीक झाले. अधिक मनोरंजक धडा health checks बद्दल होता.

"अडकणे" कसे दिसत होते

• Load balancer चे health checks त्या सर्व्हरवर timeout झाले.
• AWS Systems Manager द्वारे पाठवलेल्या commands "Pending" मध्ये अडकल्या आणि कधीच चालल्या नाहीत.
• Logs मध्ये out-of-memory kill नव्हते. कोणतीही प्रक्रिया मेली नव्हती.

एका आठवड्यापूर्वी आम्ही production लहान ARM सर्व्हरवर हलवले होते, प्रत्येकी 2 GB RAM सह. आमचा staging सर्व्हर — अजून लहान — deploy दरम्यान container image unpack करताना त्याच प्रकारे गोठला होता.

मेमरी error का नाही?

Linux एखादी प्रक्रिया तेव्हाच मारते जेव्हा परत मिळवता येणारी मेमरी खरोखर संपते. त्या बिंदूपूर्वी ते page cache मधून मेमरी परत मिळवते — फाइल्सच्या प्रती ज्या ते RAM मध्ये ठेवते, ज्यात प्रत्येक चालणाऱ्या प्रोग्रामचा कोडही येतो.

आमच्या सर्व्हरवर, कंटेनर्सच्या एकत्रित memory मर्यादा सुमारे 1.8 GB उपयोगी मशीनवर सुमारे 3.3 GB इतक्या होत्या. साधारणपणे ते सर्व एकाच वेळी त्यांची मर्यादा वापरत नाहीत. जेव्हा ते वापरले, तेव्हा kernel मेमरी मोकळी करण्यासाठी cache मधून प्रोग्रामचा कोड सतत बाहेर काढत होता, आणि तो कोड पुन्हा चालल्याच्या क्षणी डिस्कवरून परत वाचावा लागत होता. ते चक्र — thrashing — मशीनला जवळजवळ पूर्णपणे अप्रतिसादी करू शकते, तरीही तांत्रिकदृष्ट्या मेमरी कधीच संपत नाही. त्यामुळे काहीही मारले जात नाही आणि काहीही सावरत नाही.

Swap शिवाय, kernel ला वाटप झालेली पण क्वचित वापरली जाणारी मेमरी ठेवायला जागा नसते, म्हणून ती cache मधून घ्यावी लागते.

उपाय

Server bootstrap script आता प्रत्येक वेळी सर्व्हर boot किंवा दुरुस्त होताना 2 GB swap फाइल तयार करते, कमी swappiness (10) सह. कमी swappiness म्हणजे kernel अजूनही कार्यरत मेमरी RAM मध्ये ठेवणे पसंत करते, पण क्वचित स्पर्श होणारी pages डिस्कवर हलवता येतात, प्रोग्राम कोडला cache बाहेर ढकलण्याऐवजी. आम्ही ते दोन्ही production सर्व्हर आणि staging वर जागेवरच लागू केले, आणि deploy pipeline प्रत्येक production deploy वर bootstrap script पुन्हा प्रकाशित करते, त्यामुळे बदललेल्या सर्व्हरलाही ते मिळते.

जास्त त्रास देणारा भाग: अनहेल्दी सर्व्हर तसाच राहिला

आमचा server group EC2 health checks वापरत होता — "मशीन चालू आहे का?" — load balancer health checks नव्हे — "विनंत्यांना उत्तर देत आहे का?". त्यामुळे ज्या सर्व्हरने load balancer ने सोडून दिला होता, तो group च्या दृष्टीने निरोगी होता. त्याची कधीच बदली होणार नव्हती. Production एक सर्व्हरवर शांतपणे चालत राहिले असते, कोणी लक्षात येईपर्यंत आणि दुसरा reboot होईपर्यंत.

Group ला load-balancer health checks वर बदलणे हा स्पष्ट उपाय वाटतो, पण आमच्यासाठी ते सरळ नाही: deploy दरम्यान सर्व्हर जाणूनबुजून त्यांच्या health endpoint ला error देतात, जेणेकरून balancer त्यांना drain करेल (पहा आम्ही deploys शून्य 502 पर्यंत कसे आणले). जो group त्या संकेतावर सर्व्हर बदलतो, तो प्रत्येक deploy च्या मध्यात त्यांना बदलेल.

त्यामुळे आता आम्ही आमच्या deploy checklist मध्ये एक पायरी जोडली आहे: प्रत्येक deploy नंतर, फक्त deploy job पास झाला का नव्हे, तर load balancer वर प्रत्येक target चे health तपासा. एखाद्या सर्व्हरवर commands "Pending" मध्ये अडकल्या, तर तो thrash करत आहे — तो reboot करा; तो आधीच rotation बाहेर आहे.

त्यातून आम्ही काय घेतले

• "क्रॅश न होणे" म्हणजे "निरोगी" नव्हे. Thrashing मध्ये कोणतीही error येत नाही, फक्त इतका टोकाचा मंदपणा की मशीन उत्तर देणे थांबवते.
• लहान सर्व्हरना swap हवा. थोडी जरी, कमी swappiness सह, kernel ला थंड मेमरी ठेवण्यासाठी जागा देते.
• मेमरी मर्यादा मशीनपेक्षा जास्त बेरीज होणे हा जुगार आहे. कधी कधी तो हरतो. तो कधी लावला ते जाणा.
• तुमचे autoscaling कोणत्या health check वर विश्वास ठेवते ते जाणून घ्या. "VM चालू आहे का?" एवढेच विचारणारा health check काम करणे थांबलेला सर्व्हर बदलणार नाही.