جیسا کہ زیادہ تر پوسٹس, ایک تقسیم شدہ سروس میں ایک مسئلہ ہے، آئیے اس سروس کو Alvin کہتے ہیں۔ اس بار میں نے خود مسئلہ دریافت نہیں کیا، کلائنٹ کی طرف سے لڑکوں نے مجھے آگاہ کیا۔

ایک دن میں ایلون کے ساتھ طویل تاخیر کی وجہ سے ایک ناراض ای میل پر جاگ گیا، جسے ہم نے مستقبل قریب میں شروع کرنے کا منصوبہ بنایا تھا۔ خاص طور پر، کلائنٹ نے 99 ms کے علاقے میں 50ویں پرسنٹائل لیٹنسی کا تجربہ کیا، جو ہمارے لیٹنسی بجٹ سے کافی زیادہ ہے۔ یہ حیران کن تھا کیونکہ میں نے سروس کا بڑے پیمانے پر تجربہ کیا، خاص طور پر تاخیر پر، جو ایک عام شکایت ہے۔

اس سے پہلے کہ میں ایلون کو جانچ میں ڈالوں، میں نے 40k سوالات فی سیکنڈ (QPS) کے ساتھ بہت سارے تجربات کیے، یہ سبھی 10ms سے کم تاخیر کا مظاہرہ کرتے ہیں۔ میں یہ اعلان کرنے کے لیے تیار تھا کہ میں ان کے نتائج سے متفق نہیں ہوں۔ لیکن خط پر ایک اور نظر ڈالتے ہوئے، میں نے کچھ نیا دیکھا: میں نے ان حالات کا بالکل تجربہ نہیں کیا تھا جن کا انہوں نے ذکر کیا تھا، ان کا QPS میرے مقابلے میں بہت کم تھا۔ میں نے 40k QPS پر تجربہ کیا، لیکن وہ صرف 1k پر۔ میں نے ایک اور تجربہ کیا، اس بار کم QPS کے ساتھ، صرف انہیں مطمئن کرنے کے لیے۔

چونکہ میں اس کے بارے میں بلاگ کر رہا ہوں، آپ کو شاید پہلے ہی اندازہ ہو گیا ہو گا کہ ان کے نمبر درست تھے۔ میں نے اپنے ورچوئل کلائنٹ کا بار بار تجربہ کیا، اسی نتیجہ کے ساتھ: درخواستوں کی کم تعداد نہ صرف تاخیر میں اضافہ کرتی ہے، بلکہ 10 ایم ایس سے زیادہ تاخیر کے ساتھ درخواستوں کی تعداد میں اضافہ کرتی ہے۔ دوسرے لفظوں میں، اگر 40k کیو پی ایس پر تقریباً 50 درخواستیں فی سیکنڈ 50 ایم ایس سے زیادہ ہوتی ہیں، تو 1k کیو پی ایس پر ہر سیکنڈ میں 100 ایم ایس سے زیادہ 50 درخواستیں تھیں۔ پیراڈاکس!

تلاش کو کم کرنا

بہت سے اجزاء کے ساتھ تقسیم شدہ نظام میں تاخیر کے مسئلے کا سامنا کرنے پر، پہلا قدم مشتبہ افراد کی ایک مختصر فہرست بنانا ہے۔ آئیے ایلون کے فن تعمیر کو تھوڑا گہرائی میں کھودیں:

ایک اچھا نقطہ آغاز مکمل I/O ٹرانزیشن کی فہرست ہے (نیٹ ورک کالز/ڈسک تلاش کرنا وغیرہ)۔ آئیے یہ جاننے کی کوشش کرتے ہیں کہ تاخیر کہاں ہوئی ہے۔ کلائنٹ کے ساتھ واضح I/O کے علاوہ، ایلون ایک اضافی قدم اٹھاتا ہے: وہ ڈیٹا اسٹور تک رسائی حاصل کرتا ہے۔ تاہم، یہ سٹوریج اسی کلسٹر میں کام کرتا ہے جیسا کہ Alvin، اس لیے وہاں تاخیر کلائنٹ کے مقابلے میں کم ہونی چاہیے۔ لہذا، مشتبہ افراد کی فہرست:

1. کلائنٹ سے ایلون کو نیٹ ورک کال۔
2. ایلون سے ڈیٹا اسٹور پر نیٹ ورک کال۔
3. ڈیٹا اسٹور میں ڈسک پر تلاش کریں۔
4. ڈیٹا گودام سے ایلون کو نیٹ ورک کال۔
5. ایلون سے ایک کلائنٹ کو نیٹ ورک کال۔

آئیے کچھ نکات کو عبور کرنے کی کوشش کرتے ہیں۔

ڈیٹا اسٹوریج کا اس سے کوئی تعلق نہیں ہے۔

پہلا کام جو میں نے کیا وہ ایلون کو ایک پنگ پنگ سرور میں تبدیل کرنا تھا جو درخواستوں پر کارروائی نہیں کرتا ہے۔ جب اسے کوئی درخواست موصول ہوتی ہے، تو یہ خالی جواب دیتا ہے۔ اگر تاخیر میں کمی آتی ہے، تو پھر ایلون یا ڈیٹا گودام کے نفاذ میں ایک بگ کی کوئی بات نہیں سنی جاتی۔ پہلے تجربے میں ہمیں درج ذیل گراف ملتا ہے:

جیسا کہ آپ دیکھ سکتے ہیں، پنگ پنگ سرور استعمال کرتے وقت کوئی بہتری نہیں ہوتی۔ اس کا مطلب یہ ہے کہ ڈیٹا گودام میں تاخیر میں اضافہ نہیں ہوتا ہے، اور مشتبہ افراد کی فہرست نصف میں کٹ جاتی ہے:

1. کلائنٹ سے ایلون کو نیٹ ورک کال۔
2. ایلون سے ایک کلائنٹ کو نیٹ ورک کال۔

زبردست! فہرست تیزی سے سکڑ رہی ہے۔ میں نے سوچا کہ میں نے اس کی وجہ تقریباً سمجھ لی ہے۔

جی آر پی سی

اب وقت آگیا ہے کہ آپ کو ایک نئے کھلاڑی سے متعارف کروایا جائے: جی آر پی سی. یہ Google کی طرف سے ایک اوپن سورس لائبریری ہے جو اندرونِ عمل مواصلات کے لیے ہے۔ آر پی سی... اگرچہ gRPC اچھی طرح سے بہتر بنایا گیا اور وسیع پیمانے پر استعمال کیا گیا، یہ میرا پہلا موقع تھا جب اس سائز کے سسٹم پر اسے استعمال کیا گیا تھا اور میں نے توقع کی تھی کہ میرا نفاذ سب سے زیادہ بہتر ہوگا۔

دستیابی gRPC in stack نے ایک نئے سوال کو جنم دیا: ہوسکتا ہے کہ یہ میرا نفاذ ہو یا میں gRPC تاخیر کا مسئلہ پیدا کر رہا ہے؟ فہرست میں ایک نئے مشتبہ کو شامل کرنا:

1. کلائنٹ لائبریری کو کال کرتا ہے۔ gRPC
2. لائبریری gRPC کلائنٹ پر لائبریری کو نیٹ ورک کال کرتا ہے۔ gRPC سرور پر
3. لائبریری gRPC ایلون سے رابطہ کریں (پنگ پونگ سرور کی صورت میں کوئی آپریشن نہیں)

آپ کو یہ بتانے کے لیے کہ کوڈ کیسا لگتا ہے، میرا کلائنٹ/ایلون کا نفاذ کلائنٹ سرور سے زیادہ مختلف نہیں ہے۔ async مثالیں.

نوٹ: مندرجہ بالا فہرست تھوڑی آسان ہے کیونکہ gRPC آپ کا اپنا (ٹیمپلیٹ؟) تھریڈنگ ماڈل استعمال کرنا ممکن بناتا ہے، جس میں ایگزیکیوشن اسٹیک آپس میں جڑا ہوا ہے۔ gRPC اور صارف کا نفاذ۔ سادگی کی خاطر، ہم اس ماڈل پر قائم رہیں گے۔

پروفائلنگ سب کچھ ٹھیک کر دے گی۔

ڈیٹا اسٹورز کو عبور کرنے کے بعد، میں نے سوچا کہ میں تقریباً مکمل ہو چکا ہوں: "اب یہ آسان ہے! آئیے پروفائل لگائیں اور معلوم کریں کہ تاخیر کہاں ہوتی ہے۔" میں صحت سے متعلق پروفائلنگ کا بڑا پرستار، کیونکہ CPUs بہت تیز ہیں اور اکثر رکاوٹ نہیں ہوتے ہیں۔ زیادہ تر تاخیر اس وقت ہوتی ہے جب پروسیسر کو کچھ اور کرنے کے لیے پروسیسنگ روک دینی چاہیے۔ درست سی پی یو پروفائلنگ صرف یہ کرتی ہے: یہ ہر چیز کو درست طریقے سے ریکارڈ کرتی ہے۔ سیاق و سباق کے سوئچز اور یہ واضح کرتا ہے کہ تاخیر کہاں ہوتی ہے۔

میں نے چار پروفائلز لیے: ہائی کیو پی ایس (کم لیٹنسی) کے ساتھ اور کم کیو پی ایس (ہائی لیٹنسی) والے پنگ پونگ سرور کے ساتھ، کلائنٹ کی طرف اور سرور کی طرف۔ اور صرف اس صورت میں، میں نے ایک نمونہ پروسیسر پروفائل بھی لیا۔ پروفائلز کا موازنہ کرتے وقت، میں عام طور پر ایک غیر معمولی کال اسٹیک تلاش کرتا ہوں۔ مثال کے طور پر، زیادہ تاخیر کے ساتھ برے پہلو پر اور بھی بہت سے سیاق و سباق کے سوئچز ہیں (10 بار یا اس سے زیادہ)۔ لیکن میرے معاملے میں، سیاق و سباق کے سوئچز کی تعداد تقریباً ایک جیسی تھی۔ میرے خوف سے، وہاں کوئی اہم چیز نہیں تھی۔

اضافی ڈیبگنگ

میں مایوسی میں تھا۔ میں نہیں جانتا تھا کہ میں کون سے دوسرے ٹولز استعمال کر سکتا ہوں، اور میرا اگلا منصوبہ بنیادی طور پر مسئلہ کی واضح تشخیص کرنے کے بجائے مختلف تغیرات کے ساتھ تجربات کو دہرانا تھا۔

کیا اگر

شروع ہی سے، میں مخصوص 50ms لیٹنسی کے بارے میں فکر مند تھا۔ یہ بہت بڑا وقت ہے۔ میں نے فیصلہ کیا ہے کہ میں کوڈ کے ٹکڑوں کو اس وقت تک کاٹ دوں گا جب تک میں یہ معلوم نہ کر سکوں کہ کون سا حصہ اس خرابی کی وجہ بن رہا ہے۔ پھر ایک تجربہ آیا جس نے کام کیا۔

ہمیشہ کی طرح، پچھلی نظر میں ایسا لگتا ہے کہ سب کچھ واضح تھا۔ میں نے کلائنٹ کو اسی مشین پر رکھا جس میں ایلون تھا - اور اسے ایک درخواست بھیجی۔ localhost. اور تاخیر میں اضافہ ختم ہو گیا ہے!

نیٹ ورک میں کچھ گڑبڑ تھی۔

نیٹ ورک انجینئر کی مہارتیں سیکھیں۔

مجھے تسلیم کرنا ہوگا: نیٹ ورک ٹیکنالوجیز کے بارے میں میرا علم خوفناک ہے، خاص طور پر اس حقیقت پر غور کرتے ہوئے کہ میں ان کے ساتھ ہر روز کام کرتا ہوں۔ لیکن نیٹ ورک بنیادی مشتبہ تھا، اور مجھے اسے ڈیبگ کرنے کا طریقہ سیکھنے کی ضرورت تھی۔

خوش قسمتی سے، انٹرنیٹ ان لوگوں کو پسند کرتا ہے جو سیکھنا چاہتے ہیں۔ پنگ اور ٹریسرٹ کا امتزاج نیٹ ورک ٹرانسپورٹ کے مسائل کو ڈیبگ کرنے کے لیے کافی اچھی شروعات کی طرح لگتا ہے۔

سب سے پہلے، میں نے شروع کیا پی ایس پینگ ایلون کے ٹی سی پی پورٹ پر۔ میں نے پہلے سے طے شدہ ترتیبات کا استعمال کیا - کچھ خاص نہیں۔ ایک ہزار سے زیادہ پنگز میں سے، کوئی بھی 10 ms سے زیادہ نہیں ہوا، سوائے وارم اپ کے لیے پہلے والے کے۔ یہ 50 ویں پرسنٹائل پر 99 ms کی تاخیر میں مشاہدہ شدہ اضافے کے برعکس ہے: وہاں، ہر 100 درخواستوں کے لیے، ہمیں 50 ms کی تاخیر کے ساتھ تقریباً ایک درخواست دیکھنی چاہیے تھی۔

پھر میں نے کوشش کی۔ ٹریکرٹ: ایلون اور کلائنٹ کے درمیان راستے میں نوڈس میں سے ایک پر مسئلہ ہوسکتا ہے۔ لیکن ٹریسر بھی خالی ہاتھ لوٹ گیا۔

تو یہ میرا کوڈ، جی آر پی سی کا نفاذ، یا وہ نیٹ ورک نہیں تھا جو تاخیر کا سبب بن رہا تھا۔ میں پریشان ہونے لگا تھا کہ میں یہ بات کبھی نہیں سمجھوں گا۔

اب ہم کس OS پر ہیں۔

gRPC لینکس پر وسیع پیمانے پر استعمال کیا جاتا ہے، لیکن ونڈوز پر غیر ملکی. میں نے ایک تجربہ آزمانے کا فیصلہ کیا، جس نے کام کیا: میں نے ایک لینکس ورچوئل مشین بنائی، لینکس کے لیے ایلون کو مرتب کیا، اور اسے تعینات کیا۔

اور یہاں کیا ہوا ہے: لینکس پنگ پونگ سرور میں ونڈوز ہوسٹ کی طرح تاخیر نہیں تھی، حالانکہ ڈیٹا سورس مختلف نہیں تھا۔ یہ پتہ چلتا ہے کہ مسئلہ ونڈوز کے لیے جی آر پی سی کے نفاذ میں ہے۔

ناگل کا الگورتھم

اس سارے وقت میں میں نے سوچا کہ میں ایک جھنڈا کھو رہا ہوں۔ gRPC. اب میں سمجھتا ہوں کہ یہ اصل میں کیا ہے۔ gRPC ونڈوز کا جھنڈا غائب ہے۔ مجھے ایک داخلی RPC لائبریری ملی جس کے بارے میں مجھے یقین تھا کہ تمام جھنڈوں کے سیٹ کے لیے اچھا کام کرے گا۔ ونساک۔. پھر میں نے ان تمام جھنڈوں کو جی آر پی سی میں شامل کیا اور ایلون کو ونڈوز پر ایک پیچ شدہ ونڈوز پنگ پونگ سرور میں تعینات کیا!

تقریبا ہو گیا: میں نے شامل کردہ جھنڈوں کو ایک ایک کرکے ہٹانا شروع کر دیا جب تک کہ رجعت واپس نہ آجائے تاکہ میں وجہ کی نشاندہی کر سکوں۔ یہ بدنام تھا۔ TCP_NODELAY، ناگل کا الگورتھم سوئچ۔

ناگل کا الگورتھم پیغامات کی ترسیل میں تاخیر کرکے نیٹ ورک پر بھیجے گئے پیکٹوں کی تعداد کو کم کرنے کی کوشش کرتا ہے جب تک کہ پیکٹ کا سائز بائٹس کی ایک مخصوص تعداد سے زیادہ نہ ہوجائے۔ اگرچہ یہ اوسط صارف کے لیے اچھا ہو سکتا ہے، لیکن یہ ریئل ٹائم سرورز کے لیے تباہ کن ہے کیونکہ OS کچھ پیغامات میں تاخیر کرے گا، جس کی وجہ سے کم QPS میں تاخیر ہو گی۔ یو gRPC یہ پرچم TCP ساکٹ کے لیے لینکس کے نفاذ میں ترتیب دیا گیا تھا، لیکن ونڈوز میں نہیں۔ میں یہ ہوں۔ درست کیا.

حاصل يہ ہوا

کم QPS پر زیادہ تاخیر OS کی اصلاح کی وجہ سے ہوئی۔ ماضی میں، پروفائلنگ میں تاخیر کا پتہ نہیں چل سکا کیونکہ یہ اندر کی بجائے کرنل موڈ میں کیا گیا تھا۔ صارف موڈ. مجھے نہیں معلوم کہ ETW کیپچرز کے ذریعے ناگل کے الگورتھم کا مشاہدہ کیا جا سکتا ہے، لیکن یہ دلچسپ ہوگا۔

جہاں تک لوکل ہوسٹ کے تجربے کا تعلق ہے، اس نے شاید اصل نیٹ ورکنگ کوڈ کو نہیں چھوا اور ناگل کا الگورتھم نہیں چلا، اس لیے جب کلائنٹ لوکل ہوسٹ کے ذریعے ایلون تک پہنچا تو تاخیر کے مسائل دور ہو گئے۔

اگلی بار جب آپ فی سیکنڈ درخواستوں کی تعداد میں کمی کے ساتھ تاخیر میں اضافہ دیکھیں گے، تو ناگل کا الگورتھم آپ کے مشتبہ افراد کی فہرست میں ہونا چاہیے!

ماخذ: www.habr.com