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

आधुनिक कंप्यूटर कई जिलों वाले व्यस्त शहरों की तरह बनाए जाते हैं, जिनमें से प्रत्येक में अपनी स्वयं की प्रसंस्करण शक्ति और मेमोरी होती है। जब किसी प्रोग्राम को काम करने की आवश्यकता होती है, तो वह एक विशिष्ट जिले को अनुरोध भेजता है। यदि आवश्यक डेटा उस जिले की स्थानीय मेमोरी में पहले से ही मौजूद है, तो कार्य तुरंत हो जाता है। लेकिन यदि अनुरोध को जानकारी प्राप्त करने के लिए दूसरे जिले तक यात्रा करनी पड़ती है, तो इस यात्रा में काफी अधिक समय लगता है। यह देरी, जो जिलों के बीच की भौतिक दूरी के कारण होती है, इन मशीनों के निर्माण की एक मौलिक सीमा है। दशकों से, सॉफ्टवेयर इंजीनियर ऐसे प्रोग्राम लिखने का प्रयास कर रहे हैं जो डेटा और उसका उपयोग करने वाले श्रमिकों को एक ही जिले में रखें, ताकि लंबी दूरी की यात्राओं से बचा जा सके। चुनौती यह है कि जब कई श्रमिक एक ही समय में कार्यों की एक साझा सूची तक पहुँचने की कोशिश करते हैं, तो उनके द्वारा उत्पन्न ट्रैफिक जाम उतना ही नुकसानदेह हो सकता है जितना कि स्वयं दूरी।

एक शोधकर्ता ने इन साझा सूचियों को प्रबंधित करने का एक बेहतर तरीका बनाने का लक्ष्य रखा, विशेष रूप से दो अलग-अलग जिलों वाले कंप्यूटरों के लिए। उन्होंने 'NumaRing' नामक एक प्रणाली बनाई, जिसे जहाँ भी संभव हो, श्रमिकों और उनके डेटा को उनके अपने जिले के स्थानीय रखने के लिए डिज़ाइन किया गया था। विचार सरल था: यदि कोई श्रमिक पहले जिले में है, तो उसे केवल पहले जिले की सूची देखनी चाहिए। यदि वह सूची भर जाती है या खाली हो जाती है, तो सिस्टम कार्यों के एक समूह (batch) को एक बार में दूसरे जिले में स्थानांतरित करेगा, न कि उन्हें एक-एक करके। इस दृष्टिकोण ने वादा किया कि यह तेज़, स्थानीय ट्रैफ़िक को चालू रखेगा और धीमी, लंबी दूरी की यात्राओं को कम करेगा। हालाँकि, जब शोधकर्ता ने अपने सिस्टम का परीक्षण किया, तो उन्होंने पाया कि उनकी अच्छी मंशा के पीछे छिपे हुए जाल थे। अपने सिस्टम को अनुमान लगाने के बजाय अत्यधिक सटीकता के साथ मापने पर, उन्होंने पाया कि दो विशिष्ट गलतियाँ इसे हार्डवेयर की तुलना में अधिक धीमा कर रही थीं, और कंप्यूटर की धीमी गति को ठीक करने के लिए दी जाने वाली एक सामान्य सलाह वास्तव में चीजों को और खराब कर रही थी।

शोधकर्ता ने दो जिलों वाले एक क्लाउड कंप्यूटर पर अपना सिस्टम बनाकर शुरुआत की, जिसमें प्रत्येक में सोलह वर्चुअल प्रोसेसर थे। उन्होंने इसे कार्यों की एक निरंतर धारा से भर दिया, और यह देखते रहे कि एक कार्य को लाइन की शुरुआत से अंत तक जाने में कितना समय लगता है। शुरुआत में, सिस्टम आश्चर्यजनक रूप से धीमा था। शोधकर्ता को एहसास हुआ कि हर बार जब एक श्रमिक एक कार्य जोड़ने या हटाने की कोशिश करता था, तो सॉफ्टवेयर एक प्रश्न पूछता था: "मैं अभी किस जिले में हूँ?" यह प्रश्न हानिरहित लग रहा था, लेकिन उत्तर देने में लंबा समय लगता था। सॉफ्टवेयर हर बार शून्य से स्थान की पुन: गणना कर रहा था, भले ही श्रमिक का स्थान शायद ही कभी बदलता था। यह बार-बार की जाने वाली गणना ऐसी थी जैसे कोई ड्राइवर हर चौराहे पर दिशा-निर्देशों के लिए रुककर पूछ रहा हो, जबकि उसे पता है कि वह कहाँ जा रहा है। इस प्रश्न की लागत इतनी अधिक थी कि इसमें डेटा को स्थानांतरित करने के वास्तविक कार्य की तुलना में ग्यारह गुना अधिक प्रयास लगा।

एक बार जब उन्होंने इसे याद रखने और केवल आवश्यकता होने पर ही जाँच करने के माध्यम से ठीक किया, तो सिस्टम की गति नाटकीय रूप रूप से बढ़ गई। प्रति सेकंड संसाधित कार्यों की संख्या छह से सात गुना बढ़ गई। लेकिन कहानी यहाँ समाप्त नहीं हुई। जब उन्होंने मशीन में अधिक श्रमिकों को जोड़ा, तो सिस्टम एक नई बाधा से टकरा गया। श्रमिक अभी भी बहुत अधिक प्रतीक्षा कर रहे थे, विशेष रूप से तब जब सिस्टम भारी दबाव में था। गहराई से जाँच करने पर, उन्हें जिलों के बीच कार्यों को साझा करने के तरीके में दूसरी समस्या मिली। जब एक श्रमिक को दूसरे जिले से कार्यों का एक समूह लेने की आवश्यकता होती थी, तो प्रत्येक श्रमिक यह तय करने के लिए कि अगला कौन जाएगा, एक ही छोटे काउंटर के लिए लड़ रहा था। इसने गेट पर एक बड़ा ट्रैफिक जाम पैदा कर दिया। प्रत्येक श्रमिक को उपयोग करने के लिए अपना निजी काउंटर देकर, शोधकर्ता ने इस बाधा को हटा दिया। यह परिवर्तन और भी नाटकीय था, जिसने लाइन के बीच में एक श्रमिक के प्रतीक्षा समय को दो सौ गुना से अधिक कम कर दिया।

इन दो प्रमुख सुधारों के साथ, शोधकर्ता को उम्मीद थी कि उनका सिस्टम एक विजेता बनेगा। उन्होंने उन सॉफ्टवेयर त्रुटियों को समाप्त कर दिया था जो इसे पीछे खींच रही थीं। हालाँकि, जब उन्होंने तीस-दो श्रमिकों के साथ मशीन को उसकी पूर्ण सीमा तक धकेला, तो सिस्टम अभी भी उस गति तक नहीं पहुँच सका जिसकी उन्होंने मूल रूप से आशा की थी। शोधकर्ता ने कंप्यूटर की धीमी गति को हल करने के लिए उपयोग की जाने वाली एक मानक तकनीक का परीक्षण किया जिसे "बैकऑफ" (backoff) कहा जाता है। बैकऑफ के पीछे का विचार यह है कि यदि कोई श्रमिक कार्य प्राप्त करने में विफल रहता है, तो उसे फिर से प्रयास करने से पहले एक क्षण के लिए रुक जाना चाहिए, इस उम्मीद में कि लाइन खाली हो जाएगी। कई स्थितियों में, यह ठहराव मदद करता है। लेकिन इस विशिष्ट, उच्च-दबाव वाले वातावरण में, यह ठहराव एक गलती थी। शोधकर्ता ने मापा कि प्रतीक्षा करने से वास्तव में उनकी कुल गति में पंद्रह से तीस प्रतिशत की कमी आई। सबसे तेज़ रास्ता तुरंत प्रयास करते रहना था, क्योंकि हार्डवेयर पहले से ही संघर्ष को कुशलतापूर्वक संभाल रहा था और प्रतीक्षा करना केवल समय की बर्बादी थी।

जो अंतिम चित्र उभरा वह सफलता और कठोर सीमाओं का मिश्रण था। शोधकर्ता ने सफलतापूर्वक एक ऐसा सिस्टम बनाया जो डेटा को स्थानीय रखता है और दो प्रमुख सॉफ्टवेयर बग्स को ठीक करता है जो भारी देरी का कारण बन रहे थे। उन्होंने सिद्ध किया कि एक सामान्य अनुकूलन रणनीति कुछ उच्च-गति वाले परिदृश्यों में हानिकारक हो सकती है। फिर भी, इन विजयों के बावजूद, सिस्टम मूल डिज़ाइन लक्ष्य के अनुसार कार्यों को प्रोसेस करने में सक्षम नहीं था। शोधकर्ता ने निष्कर्ष निकाला कि शेष धीमी गति एक सॉफ्टवेयर त्रुटि नहीं थी जिसे वे ठीक कर सकते थे, बल्कि यह स्वयं मशीन की एक भौतिक सीमा थी। दोनों जिलों के बीच की दूरी और उन्हें जोड़ने वाली सड़क की बैंडविड्थ (bandwidth) ने एक ऐसी सीमा बना दी थी जिसे इस डिज़ाइन के साथ कोई भी चतुर कोडिंग तोड़ नहीं सकती थी। उन्होंने अपने निष्कर्षों को ईमानदारी से रिपोर्ट किया, यह दिखाते हुए कि उनका सिस्टम कहाँ सफल हुआ, कहाँ विफल हुआ, और क्यों हार्डवेयर स्वयं अंतिम निर्णायक था। उनका कार्य एक अनुस्मारक के रूप में कार्य करता है कि उच्च-गति कंप्यूटिंग की दुनिया में, भौतिक मशीन को समझना कोड लिखने जितना ही महत्वपूर्ण है।