وہ غائب swap file جس نے ہمارے سرور جما دیے

24 ستمبر کو ہمارا ایک production سرور جواب دینا بند ہو گیا۔ Load balancer نے اسے unhealthy قرار دیا اور ہمارا remote-command tool اس تک نہیں پہنچ سکا، مگر کچھ کریش نہیں ہوا تھا اور نہ کسی process کو زیادہ memory استعمال کرنے پر مارا گیا تھا۔ سرور thrash کر رہا تھا: swap space کے بغیر اور containers کو مشین کی memory سے زیادہ استعمال کی اجازت ہونے کی وجہ سے، Linux اپنا وقت ان فائلوں کو نکالنے اور دوبارہ پڑھنے میں لگا رہا تھا جن کی اسے چلنے کے لیے ضرورت تھی، اور بمشکل کوئی پیش رفت ہو رہی تھی۔ ہر سرور پر 2 GB کی swap file شامل کرنے سے یہ ٹھیک ہو گیا۔ زیادہ دلچسپ سبق health checks کے بارے میں تھا۔

“hung” ہونا کیسا لگا

• Load balancer کے health checks اس سرور پر timeout ہو گئے۔
• AWS Systems Manager کے ذریعے بھیجی گئی commands “Pending” میں پڑی رہیں اور کبھی نہیں چلیں۔
• Logs میں کوئی out-of-memory kill نہیں تھا۔ کوئی process نہیں مرا۔

ایک ہفتہ پہلے ہم نے production کو 2 GB RAM والے چھوٹے ARM سرورز پر منتقل کیا تھا۔ ہمارا staging سرور، جو اور بھی چھوٹا ہے، deploy کے دوران ایک container image کھولتے ہوئے اسی طرح جم گیا تھا۔

Memory کی کوئی خرابی کیوں نہیں؟

Linux کسی process کو صرف تب مارتا ہے جب اس کے پاس واقعی وہ memory ختم ہو جائے جو واپس لی جا سکتی ہو۔ اس نقطے سے پہلے، وہ memory page cache سے واپس لیتا ہے، یعنی وہ کاپیاں جو وہ RAM میں فائلوں کی رکھتا ہے، بشمول ہر چلتے program کا کوڈ۔

ہمارے سرورز پر containers کی مشترکہ memory حدیں تقریباً 3.3 GB بنتی تھیں، جبکہ مشین پر تقریباً 1.8 GB قابلِ استعمال تھا۔ عام طور پر وہ سب ایک ساتھ اپنی حد تک استعمال نہیں کرتے۔ جب انہوں نے کیا، تو kernel جگہ بنانے کے لیے cache سے program کا کوڈ نکالتا رہا، اور جیسے ہی وہ کوڈ دوبارہ چلتا، اسے disk سے واپس پڑھنا پڑتا۔ یہ چکر، یعنی thrashing، مشین کو تقریباً مکمل طور پر غیر جواب دہ بنا سکتا ہے، جبکہ تکنیکی طور پر memory کبھی ختم نہیں ہوتی۔ نتیجتاً کچھ مارا نہیں جاتا، اور کچھ بحال نہیں ہوتا۔

Swap کے بغیر، kernel کے پاس وہ memory رکھنے کی جگہ نہیں ہوتی جو مختص ہو چکی ہو مگر شاذ و نادر استعمال ہو، اس لیے وہ اسے cache سے لینے پر مجبور ہوتا ہے۔

حل

سرور bootstrap script اب ہر بار جب سرور boot ہو یا درست کیا جائے تو 2 GB swap file بناتا ہے، جس کی swappiness کم (10) ہوتی ہے۔ کم swappiness کا مطلب ہے کہ kernel پھر بھی کام کی memory RAM میں رکھنا پسند کرتا ہے، مگر شاذ و نادر چھوئے جانے والے pages disk پر جا سکتے ہیں، بجائے اس کے کہ program کا کوڈ cache سے نکالنے پر مجبور ہوں۔ ہم نے یہ دونوں production سرورز اور staging پر فوراً لاگو کر دیا، اور deploy pipeline ہر production deploy پر bootstrap script دوبارہ publish کرتی ہے تاکہ بدلے گئے سرور کو بھی یہ ملے۔

وہ حصہ جس نے ہمیں زیادہ پریشان کیا: unhealthy سرور باقی رہا

ہمارا server group EC2 health checks استعمال کرتا تھا، یعنی “کیا مشین چل رہی ہے؟”، نہ کہ load balancer health checks، یعنی “کیا یہ درخواستوں کا جواب دے رہی ہے؟”۔ تو جس سرور کو load balancer چھوڑ چکا تھا، group کے نزدیک وہ پھر بھی صحت مند تھا۔ اسے کبھی بدلا نہیں جاتا۔ Production خاموشی سے ایک ہی سرور پر چلتا رہتا جب تک کوئی نوٹس نہ کرتا اور دوسرا reboot نہ کرتا۔

Group کو load-balancer health checks پر منتقل کرنا واضح حل لگتا ہے، مگر ہمارے لیے یہ سیدھا نہیں: deploy کے دوران سرورز جان بوجھ کر اپنے health endpoint پر ایک خرابی لوٹاتے ہیں تاکہ balancer انہیں خالی کرے (دیکھیں ہم نے deploys کو صفر 502s تک کیسے پہنچایا)۔ جو group اس اشارے پر سرور بدلتا، وہ ہر deploy کے بیچ میں انہیں بدل دیتا۔

اس لیے ابھی ہم نے اپنی deploy checklist میں ایک قدم شامل کیا: ہر deploy کے بعد load balancer پر ہر target کی health چیک کریں، نہ کہ صرف یہ کہ deploy job پاس ہوا۔ اگر کسی سرور کو commands “Pending” میں پڑی نظر آئیں تو وہ thrash کر رہا ہے، اسے reboot کریں؛ وہ پہلے ہی rotation سے باہر ہے۔

ہم نے اس سے کیا سیکھا

• “کریش نہ ہونا” “صحت مند ہونا” نہیں۔ Thrashing کوئی خرابی پیدا نہیں کرتا، صرف اتنی شدید سستی کہ مشین جواب دینا بند کر دے۔
• چھوٹے سرورز کو swap چاہیے۔ تھوڑا سا بھی، کم swappiness کے ساتھ، kernel کو ٹھنڈی memory رکھنے کی جگہ دیتا ہے۔
• Memory حدیں جو مشین سے زیادہ جمع ہوں، ایک شرط ہیں۔ کبھی آپ ہار جاتے ہیں۔ جانیں کہ آپ نے کب شرط لگائی ہے۔
• جانیں کہ آپ کا autoscaling کس health check پر بھروسہ کرتا ہے۔ وہ health check جو صرف یہ پوچھتا ہے “کیا VM آن ہے؟” اس سرور کو نہیں بدلے گا جو کام کرنا بند کر چکا ہو۔