NumaRing: Topology-Aware Routing for NUMA-Local MPMC Queues, and What Broke When We Optimized It

تُبنى الحواسيب الحديثة مثل المدن الصاخبة التي تضم أحياء متعددة، كل منها يمتلك قوته المعالجة وذاكرته الخاصة. عندما يحتاج برنامج ما للقيام بعمل ما، فإنه يرسل طلباً إلى حي معين. إذا كانت البيانات التي يحتاجها موجودة بالفعل في الذاكرة المحلية لذلك الحي، فإن المهمة تتم فوراً. أما إذا كان يجب على الطلب السفر إلى حي آخر لجلب المعلومات، فإن الرحلة تستغرق وقتاً أطول بكثير. هذا التأخير، الناتج عن المسافة الفيزيائية بين الأحياء، هو حد أساسي لكيفية بناء هذه الآلات. لعقود من الزمن، حاول مهندسو البرمجيات كتابة برامج تحافظ على بقاء البيانات والعمال الذين يستخدمونها في نفس الحي، آملين في تجنب تلك الرحلات الطويلة عبر البلاد. والتحدي يكمكم في أنه عندما يحاول العديد من العمال الوصول إلى قائمة مهام مشتركة في نفس الوقت، فإن الاختناقات المرورية التي يسببونها يمكن أن تكون ضارة بقدر الضرر الذي تسببه المسافة نفسها.

قام أحد الباحثين ببناء طريقة أفضل لإدارة هذه القوائم المشتركة، وتحديداً للحواسيب ذات منطقتين متميزتين. لقد ابتكر نظاماً يسمى "NumaRing"، صُمم لإبقاء العمال وبياناتهم محليين في منطقتهم الخاصة كلما أمكن ذلك. كانت الفكرة بسيطة: إذا كان العامل في المنطقة الأولى، فعليه فقط النظر في القائمة الموجودة في المنطقة الأولى. وإذا امتلأت تلك القائمة أو فرغت، يقوم النظام بعد ذلك بنقل دفعة من المهام إلى المنطقة الأخرى دفعة واحدة، بدلاً من نقلها واحدة تلو الأخرى. وعد هذا النهج بالحفاظ على تدفق حركة المرور المحلية السريعة مع تقليل الرحلات الطويلة والبطيئة. ومع ذلك، عندما وضع الباحث نظامه تحت الاختبار، اكتشف أن نواياه الحسنة كانت تخفي فخاخاً مستترة. فمن خلال قياس نظامه بدقة متناهية بدلاً من التخمين حول كيفية عمله، وجد أن خطأين محددين كانا يبطئان نظامه أكثر من الأجهزة نفسها، وأن نصيحة شائعة لإصلاح بطء الحواسيب كانت في الواقع تجعل الأمور أسوأ.

بدأ الباحث ببناء نظامه على حاسوب سحابي يتكون من منطقتين، تضم كل منهما ستة عشر معالجاً افتراضياً. ملأه بتدفق مستمر من المهام، مراقباً المدة التي تستغرقها المهمة للانتقال من بداية الطابور إلى نهايته. في البៃ، كان النظام بطيئاً بشكل مفاجئ. أدرك الباحث أنه في كل مرة يحاول فيها عامل إضافة أو إزالة مهمة، يسأل البرنامج سؤالاً: "في أي منطقة أنا الآن؟". بدا هذا السؤال غير ضار، لكن الإجابة عليه استغرقت وقتاً طلاً في الحساب. كان البرنامج يعيد حساب الموقع من الصفر في كل مرة، رغم أن موقع العامل نادراً ما يتغير. كان تكلفة هذا السؤال مرتفعاً لدرجة أنه استهلك أكثر من إحدى عشرة مرة من الجهد المبذول في المهمة الفعلية لنقل البيانات.

بمجرد أن أصلح الباحث هذا الأمر عن طريق تذكر الموقع والتحقق منه فقط عند الضرورة، تسارع النظام بشكل كبير. قفز عدد المهام المعالجة في الثانية بمعدل ست إلى سبع مرات أعلى. لكن القصة لم تنتهِ عند هذا الحد. فعندما أضاف المزيد من العمال إلى الآلة، اصطدم النظام بحائط جديد. كان العمال لا يزالون ينتظرون لفترة طويلة جداً، خاصة عندما يكون النظام تحت ضغط شديد. وبالتعمق أكثر، وجدوا مشكلة ثانية في طريقة مشاركة العمال للمهام بين المناطق. فعندما يحتاج عامل إلى أخذ دفعة من المهام من منطقة أخرى، كان كل عامل يتقاتل على نفس العداد الصغير لتحديد من سيذهب تالياً. خلق هذا ازدحاماً مرورياً هائلاً عند البوابة. ومن خلال منح كل عامل عداداً خاصاً به لاستخدامه، أزال الباحث هذا الاختناق. كان هذا التغيير أكثر دراماتيكية، حيث قلل من وقت انتظار العامل في منتصف الطابور بأكثر من مائتي مرة.

مع وجود هذين الإصلاحين الرئيسيين، توقع الباحث أن يكون نظامه بطلاً. لقد قضى على أخطاء البرمجيات التي كانت تعيق تقدمه. ومع ذلك، عندما دفع بالآلة إلى أقصى حدودها بـ اثنين وثلاثين عاملاً، لم يستطع النظام الوصول إلى السرعة التي كان يأملها في الأصل. اختبر الباحث تقنية قياسية تُستخدم لحل بطء الحواسيب تسمى "التراجع" (backoff). الفكرة وراء التراجع هي أنه إذا فشل عامل في الحصول على مهمة، فينبغي عليه الانتظار لحظة قصيرة قبل المحاولة مرة أخرى، على أمل أن يخف الزحام. في كثير من المواقف، يساعد هذا التوقف. ولكن في هذه البيئة المحددة وعالية الضغط، كان التوقف خطأً. قاس الباحث أن الانتظار كلفهم في الواقع خمسة عشر إلى ثلاثين بالمائة من سرعتهم الإجمالية. كان المسار الأسرع هو الاستمرار في المحاولة فوراً، لأن الأجهزة كانت تتعامل مع النزاع بكفاءة كافية بحيث أن الانتظار لم يؤدِ إلا إلى إضاعة الوقت.

كانت الصورة النهائية التي ظهرت هي صورة من النجاح والحدود الصارمة. نجح الباحث في بناء نظام يحافظ على محلية البيانات وأصلح عيبين برمجيين رئيسيين كانا يسببان تأخيرات هائلة. لقد أثبت أن استراتيجية تحسين شائعة يمكن أن تكون ضارة في سيناريوهات معينة عالية السرعة. ومع ذلك، رغم هذه الانتصارات، لم يستطع النظام معالجة المهام بالسرعة التي كان يهدف إليها التصميم الأصلي. استنتج الباحث أن البطء المتبقي لم يكن خطأً برمجياً يمكنه إصلاحه، بل كان حداً فيزيائياً للآلة نفسها. إن المسافة بين المنطقتين ونطاق التردد (bandwidth) للطريق الذي يربنهما خلق سقفاً لا يمكن لأي قدر من البرمجة الذكية اختراقه بهذا التصميم. لقد عرض نتائج أبحاثه بأمانة، موضحاً بالضبط أين نجح نظامه، وأين فشل، ولما لماذا كانت الأجهزة نفسها هي الحكم النهائي. إن عمله بمثابة تذكير بأنه في عالم الحوسبة عالية السرعة، فإن فهم الآلة الفيزيائية لا يقل أهمية عن كتابة الكود.