English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

guest
1 / ?
back to lessons

सिस्टम को अनुकूलित करें, इसके घटकों को नहीं

सिस्टम्स इंजीनियरिंग का हैमिंग का पहला नियम

Ch. 28 से हैमिंग का मूल सिद्धांत: यदि आप घटकों को अनुकूलित करते हैं तो आप संभवतः सिस्टम के प्रदर्शन को बर्बाद कर देंगे।


उन्होंने इसे डिफरेंशियल एनालाइज़र की कहानी से समझाया। दो इकाइयों को जोड़ा जाना था। बिल्डर्स ने दूसरी इकाई में एम्प्लिफ़ायरों को बेहतर बनाया। स्वीकृति के दिन, हैमिंग ने मानक परीक्षण चलाया — y'' + y = 0 हल करें, y बनाम y' प्लॉट करें, एक वृत्त की अपेक्षा करें। यह विफल रहा। कारण: बेहतर एम्प्लिफ़ायरों ने ग्राउंडिंग सर्किट के माध्यम से अधिक करंट खींचा। मूल डिज़ाइन के लिए ग्राउंडिंग ठीक थी। यह नए करंट स्तर के लिए रेटेड नहीं थी। इंटरफ़ेस टूट गया, घटक नहीं।


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


मुख्य असमानता: किसी घटक में 10× सुधार से सिस्टम में 10× गिरावट हो सकती है, यदि वह घटक एक सीमित इंटरफेस को फीड करता है। सुधार जोड़ता नहीं — घटाता है।

शिक्षा प्रणाली एक असफल सिस्टम इंजीनियरिंग के रूप में

Hamming का शिक्षा उदाहरण

Hamming ने इस सिद्धांत को शिक्षा पर लागू किया। व्यक्तिगत विषयों के स्कोर को अनुकूलित करना — छात्रों को प्रत्येक विषय में परीक्षा प्रदर्शन को अधिकतम करने के लिए ड्रिल करना — ऐसे छात्र तैयार करता है जो व्यक्तिगत परीक्षाओं में अच्छा स्कोर करते हैं, लेकिन विषयों के बीच ज्ञान को एकीकृत नहीं कर पाते।


प्रत्येक घटक (विषय अंक) में सुधार होता है। प्रणाली (शिक्षा, जिसे एकीकृत समझ के रूप में परिभाषित किया गया है) में गिरावट आती है। विषयों के बीच का इंटरफ़ेस — विभिन्न क्षेत्रों में ज्ञान लागू करने की छात्र की क्षमता — कभी अनुकूलित नहीं किया गया। यह क्षीण हो गया।


यह कार्यान्वयन की दुर्घटना नहीं है। यह संरचनात्मक है। जब आप घटक प्रदर्शन को मापते और पुरस्कृत करते हैं, तो आपको घटक अनुकूलन मिलता है। इंटरफ़ेस घटक मेट्रिक्स के लिए अदृश्य होते हैं।


उनका नुस्खा: प्रणाली में बाधा का पता लगाएं, फिर पूछें कि जब आप इसे हटाते हैं तो डाउनस्ट्रीम क्या होता है। बाधा हटाने से अगली कतार में बाढ़ आ जाती है। एक अनियंत्रित अनुकूलन नई बाधा बन जाता है।

इंटरफ़ेस क्षरण का पता लगाना

हैमिंग ने दिखाया कि घटक में सुधार करने से उसका इंटरफ़ेस व्यवहार बदल जाता है — और शेष प्रणाली पुराने इंटरफ़ेस के आसपास डिज़ाइन की गई थी।

सॉफ़्टवेयर से एक ठोस उदाहरण दें जहां एक घटक के प्रदर्शन में सुधार करने से डाउनस्ट्रीम में समस्या उत्पन्न हुई। सुधार किए गए घटक का नाम बताएं, प्रभावित इंटरफ़ेस का नाम बताएं, और चेतावनी संकेत बताएं जो डाउनस्ट्रीम विफलता से पहले दिखाई देता।

Nodes, Queues, Surge Scores

A MOAD Factory Model

हर सॉफ़्टवेयर डिपेंडेंसी ग्राफ़ एक फैक्ट्री बनाता है। प्रत्येक नोड एक वर्कस्टेशन है। प्रत्येक एज एक कतार है। काम एक नोड की कतार में प्रवेश करता है, प्रोसेस होता है, और डाउनस्ट्रीम कतारों में प्रवाहित होता है।


हर नोड को दो स्कोर से चिह्नित किया जाता है:


Factory Model DAG: workaholic node (high betweenness + surge) and glutton node (high out-degree)

Surge score = speedup × in-degree

जब यह बाधा दूर होती है तो डाउनस्ट्रीम में कितना काम बाढ़ की तरह आता है। एक नोड जिसमें इन-डिग्री 5 (5 अपस्ट्रीम निर्भरताएँ इसे फीड कर रही हैं) और 100× स्पीडअप है, वह डाउनस्ट्रीम में 500× सर्ज उत्पन्न करता है।


Betweenness = in-degree + out-degree

कुल प्रवाह में यह वर्कस्टेशन कितना केंद्रीय है। उच्च बिचवीनता (betweenness) का मतलब है कि कई पथ इस नोड से होकर गुजरते हैं।


दो आर्केटाइप:


वर्काहोलिक नोड: उच्च बिचवीनता, उच्च सर्ज स्कोर। यह बाधा (bottleneck) है। इसके कारण ऊपर की ओर हर कतार जाम हो जाती है। बिना डाउनस्ट्रीम क्षमता को स्टेज किए इस बाधा को हटाने से, डाउनस्ट्रीम सब कुछ एक साथ ढह जाता है।


ग्लटन नोड: उच्च आउट-डिग्री, निम्न सर्ज स्कोर। इसे जो भी दिया जाता है, वह सब खा लेता है। इसे कोई दर्द महसूस नहीं होता क्योंकि इसकी बाधा आंतरिक है, थ्रूपुट नहीं। वह मशीन जो रुकना भूल जाती है — काम अंदर जाता है, कुछ बाहर नहीं निकलता, और नोड हमेशा 'व्यस्त' रिपोर्ट करता है।

MOAD-0001 & MOAD-0005: एक कपलिंग केस

GHC का मामला

GHC के डिपेंडेंसी रिज़ॉल्वर में MOAD-0001 पैच से पहले: N=50,000 डिपेंडेंसीज को बिल्ड करने में 17 मिनट लगते थे। बाद में: 10 सेकंड। स्पीडअप: 100×।


डाउनस्ट्रीम क्या होता है? हर बिल्ड कैश, आर्टिफैक्ट स्टोर, और CI रनर जो 17-मिनट के बैच अराइवल्स के हिसाब से खुद को एडजस्ट कर रहा था, अब प्रति घंटे 100× अधिक पूर्ण बिल्ड्स प्राप्त करता है। कैशेस जो प्रति घंटे 60 बिल्ड आर्टिफैक्ट्स हैंडल करने के लिए डिज़ाइन किए गए थे, अब 6,000 प्राप्त करते हैं।


यह MOAD-0005 है: कैश स्टैम्पीड डिफेक्ट। हर कैश कुंजी एक साथ मिस हो जाती है क्योंकि नई अराइवल रेट के लिए कोई कैश पहले से वार्म नहीं किया गया था। MOAD-0001 का फिक्स MOAD-0005 को उत्पन्न करता है।


यह कपलिंग आकस्मिक नहीं है। यह संरचनात्मक है। कोई भी O(N²) → O(N) स्पीडअप जिसमें इन-डिग्री > 1 हो, 1 से ऊपर का सर्ज स्कोर उत्पन्न करता है। 100 से ऊपर का सर्ज स्कोर MOAD-0005 का उम्मीदवार होता है।

Staging Before Disclosure

एक बिल्ड सिस्टम प्रति घंटे 1,000 पैकेज डिपेंडेंसी ग्राफ़ प्रोसेस करता है। आप इसके ग्राफ़ ट्रैवर्सल में MOAD-0001 को पैच करते हैं, जिससे बिल्ड समय 60 मिनट से घटकर 30 सेकंड हो जाता है — यानी 120× स्पीडअप। अब सिस्टम प्रति घंटे 120,000 ग्राफ़ प्रोसेस कर सकता है।

इस पैच के बाद MOAD-0005 के सबसे अधिक जोखिम में कौन-सा डाउनस्ट्रीम सिस्टम है, और आप उसे डिस्क्लोज़ करने से पहले किस फिक्स को स्टेज करेंगे?

कब रुकें: The Halt Condition

हॉल्ट कंडीशन

एक पैच हॉल्ट कंडीशन को पूरा करता है — अर्थात: प्रकट न करें — जब निम्नलिखित चारों शर्तें एक साथ पूरी हों:


1. पैच एक लाइव सिस्टम में मौजूद हो (मर्ज किया गया, डिप्लॉय किया गया)

2. डाउनस्ट्रीम प्रभाव की जिम्मेदारी लेने के लिए कोई केयरटेकर नियुक्त न हों

3. डाउनस्ट्रीम दोष (MOAD-0005) अनसुलझा हो

4. स्पीडअप >= 100×


चारों को मिलाकर = बच्चा रोता है। मर्ज करने से पहले टीम असाइन करें, बाद में नहीं।


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

WALL-E: लोलुप और वर्काहोलिक्स

WALL-E मॉडल

Pixar का WALL-E फ़ैक्टरी मॉडल की विफलता को सबसे स्पष्ट रूप में दर्शाता है। होवर चेयर पर लोलुप लोग, बिना घर्षण के खिलाए जाते हैं। वर्काहोलिक्स — WALL-E, EVE — फीड को चलाए रखने के लिए अपने स्टेशनों पर मरते हैं।


लोलुप नोड (होवर चेयर पर मनुष्य) की अधिकतम आउट-डिग्री होती है: यह सब कुछ खा जाता है जो उसे खिलाया जाता है, कुछ भी उत्पन्न नहीं करता। इसका सर्ज स्कोर शून्य है — यह एक सिंक है। इसे कोई दर्द महसूस नहीं होता क्योंकि इसके आउटपुट पर कुछ भी जमा नहीं होता। यह केवल उपभोग करता है।


वर्काहोलिक नोड (WALL-E) में अधिकतम बिटवीननेस है: सब कुछ इसके माध्यम से बहता है। यह सभी इनपुट को अवशोषित करता है। यह एकमात्र आउटपुट उत्पन्न करता है। इसका सर्ज स्कोर, यदि कभी इसे किसी तेज़ मॉडल से बदल दिया जाए, तो हर डाउनस्ट्रीम कतार को एक साथ बाढ़ देगा।


WALL-E सिस्टम में दोष ग्लूटन्स में नहीं है। यह अनुपस्थित केयरटेकर है: कोई भी वर्कस्टेशन को संतुलित करने के लिए नियुक्त नहीं किया गया। किसी ने भी एल्गोरिदम चलाने से पहले क्षमता का मंचन नहीं किया।

The pip Case: Pre-Disclosure Checklist

आपको Python के pip डिपेंडेंसी रिज़ॉल्वर में MOAD-0001 मिलता है। मापा गया स्पीडअप: 200×। pip प्रतिदिन लगभग 400 मिलियन इंस्टॉल पर चलता है। PyPI पैकेजेस सर्व करता है।

इस पैच को डिस्क्लोज़ करने से पहले, तीन चीज़ें सूचीबद्ध करें जिनकी आपको पुष्टि या मंचन करना चाहिए, और बताएं कि यदि आप प्रत्येक को छोड़ दें तो क्या टूटेगा।