कोई कचरा संग्रहकर्ता p99 विलंबता को क्यों नहीं बदलता?

एक औसत आवश्यक को छुपाता है। यदि 100 में से 99 अनुरोध 5 एमएस में उत्तर देते हैं और केवल एक 500 एमएस लेता है, तो औसत कम रहता है। लेकिन सौ में से एक उपयोगकर्ता को सौ गुना अधिक प्रतीक्षा का अनुभव होता है। पी99 ठीक इसी अनुरोध को मापता है: सबसे धीमा सौवां, वह जो आपके एसएलए का उल्लंघन करता है जबकि आपका औसत विलंबता डैशबोर्ड हरा रहता है।

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

एक बैकएंड जो प्रति सेकंड हजारों अनुरोधों को संसाधित करता है, एक बिंदु या किसी अन्य पर, एक अनुरोध भेजने के लिए बाध्य होता है जो जीसी ठहराव के दौरान आता है। बड़े पैमाने पर यह कोई असामान्य मामला नहीं है. यह एक सांख्यिकीय निश्चितता है.

एक कचरा संग्रहकर्ता (जीसी) किसी प्रोग्राम की जीवित वस्तुओं को लगातार ट्रैक करता है - जो अभी भी कहीं संदर्भित हैं - और उन वस्तुओं की मेमोरी को मुक्त करता है जो पहुंच से बाहर हो गई हैं। इस ट्रैकिंग को tracingकहा जाता है: GC संदर्भ ग्राफ़ के माध्यम से जाता है, जो अभी भी उपयोग किया जाता है उसे चिह्नित करता है, फिर बाकी को साफ़ करता है।

समस्या: जब प्रोग्राम नए संदर्भ बनाना जारी रखता है तो इस ग्राफ़ को पार करने से असंगत परिणाम उत्पन्न होते हैं। ऐतिहासिक उत्तर, जिसे अभी भी कई आधुनिक जीसी द्वारा अंतिम उपाय के रूप में उपयोग किया जाता है, stop-the-world है - मार्किंग और स्कैनिंग के दौरान पूरा प्रोग्राम रुक जाता है। ढेर जितना बड़ा होगा, विराम उतना ही लंबा होगा: इसकी अवधि लाइव डेटा के आकार पर निर्भर करती है, न कि वर्तमान कार्यभार पर।

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

फरवरी 2020 में, इंजीनियर जेसी हॉवर्थ ने एक पोस्ट प्रकाशित की जो उद्योग में एक संदर्भ बन गई है: "डिस्कॉर्ड गो से रस्ट में क्यों बदल रहा है" (डिस्कॉर्ड इंजीनियरिंग ब्लॉग)। प्रासंगिक सेवा, रीड स्टेट्स, लाखों उपयोगकर्ताओं के लिए संदेश पढ़ने की स्थिति का प्रबंधन करती है - प्रति कैश लाखों प्रविष्टियाँ - प्रति सेकंड सैकड़ों हजारों अपडेट के साथ।

निदान प्रत्यक्ष है, जैसा कि लेख में उद्धृत किया गया है: "गो कम से कम हर 2 मिनट में कचरा संग्रहण चलाने के लिए बाध्य करेगा"। दूसरे शब्दों में, गो इस सेवा पर कम से कम हर दो मिनट में एक कचरा संग्रहण चक्र ट्रिगर करता है - और प्रत्येक चक्र टीम के ग्राफ़ में दिखाई देने वाली विलंबता में वृद्धि उत्पन्न करता है।

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

पोस्ट ने एक जीवंत तकनीकी बहस छेड़ दी: प्रकाशन के उसी दिन (4 फरवरी, 2020) हैकर न्यूज़ पर 1,580 से अधिक अंक और 642 टिप्पणियाँ - एक संकेत है कि समस्या डिस्कोर्ड मामले से कहीं आगे तक जाती है।

गो कचरा संग्राहक जीसी ठहराव को नियंत्रित करने के लिए आवश्यक प्रयास के पैमाने को दर्शाता है - यहां तक ​​​​कि Google में एक समर्पित टीम के संसाधनों के साथ भी। गो जीसी तकनीकी प्रमुख रिक हडसन ने इस कहानी को दो आधिकारिक गो ब्लॉग पोस्ट में दर्ज किया है।

स्रोत: "गेटिंग टू गो: द जर्नी ऑफ़ गोज़ गारबेज कलेक्टर", go.dev, 12 जुलाई, 2018; और "गो जीसी: कम विलंबता और सरलता को प्राथमिकता देना", go.dev, 31 अगस्त, 2015।

तीन साल के समर्पित कार्य ने सामान्य ब्रेक को एक हजार गुना कम कर दिया है। लेकिन विराम कभी गायब नहीं हुआ: यह एक सेवा उद्देश्य (एसएलओ) है, शून्य की पूर्ण गारंटी नहीं। एक जीसी ट्रेसिंग को, निर्माण द्वारा, समय-समय पर जीवित वस्तुओं के ग्राफ को पार करना चाहिए। एकमात्र समायोज्य चर इस यात्रा की आवृत्ति और अवधि है - इसका अस्तित्व नहीं।

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

जंग जीसी रुकावटों को कम नहीं करता है: यह उस तंत्र को समाप्त कर देता है जो उन्हें पैदा करता है। कंपाइलर, कंपाइलेशन पर ट्रैक करता है कि प्रत्येक मेमोरी वैल्यू का मालिक कौन है - यहownershipहै। जब किसी मूल्य का स्वामी दायरे से बाहर हो जाता है, तो रस्ट स्वचालित रूप से उस कॉल को सम्मिलित करता है जो उस मेमोरी को बाइनरी कोड में उसी स्थान पर मुक्त करता है। इस तंत्र को RAII (संसाधन अधिग्रहण आरंभीकरण है) कहा जाता है: रिलीज नियतात्मक है, पृष्ठभूमि में चल रहे कचरा संग्रहकर्ता द्वारा निर्धारित नहीं है।

स्काला/रस्ट इकोसिस्टम में मान्यता प्राप्त एक तकनीकी ब्लॉग के लेखक एलेक्जेंड्रू नेडेलकु ने हाल के एक लेख में ट्रेड-ऑफ का सारांश दिया है: "रस्ट जो ट्रेड-ऑफ करता है, वह पूर्वानुमानित विलंबता और सुरक्षा के साथ प्रदर्शन को प्राथमिकता देते हुए उपयोग में आसान है" (alexn.org, 21 जुलाई, 2026)। रस्ट पूर्वानुमेय विलंबता के लिए लेखन की कुछ सरलता का व्यापार करता है।

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

यहां लगभग दस पंक्तियों में तंत्र है - एक सामान्य उदाहरण, ऑराबेस कोड से उद्धरण नहीं:

struct Connection {
    id: u32,
}

impl Drop for Connection {
    fn drop(&mut self) {
        println!("connexion {} fermée", self.id);
    }
}

fn handle_request() {
    let conn = Connection { id: 42 };
    // ...अनुरोध संसाधित करता है...
} // कॉन यहां दायरे से बाहर हो जाता है: ड्रॉप() निष्पादित होता है
   // सटीक क्षण में, संकलक द्वारा जांचा गया -
   // कचरा संग्रहण चक्र के माध्यम से नहीं।

महत्वपूर्ण बारीकियाँ: सब कुछ मुफ़्त नहीं है। संदर्भ-गिनती प्रकार (Rc, Arc) प्रत्येक क्लोन और रिलीज़ में एक छोटी लागत जोड़ते हैं। यह लागत स्थानीय और नियतात्मक रहती है। ऐसा कोई ठहराव नहीं है जो पूरे प्रोग्राम को मेमोरी ढेर से गुजरते समय रोक देता है।

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

हजारों समवर्ती अनुरोधों को पूरा करने वाले बैकएंड पर, GC की अनुपस्थिति समीकरण p99 से एक चर को हटा देती है। अब मेमोरी ढेर को आकार देने, संग्राहक की पीढ़ियों को समायोजित करने, या ऐसे चक्र की निगरानी करने की आवश्यकता नहीं है जो सबसे खराब समय में गिर सकता है। किसी व्यक्तिगत अनुरोध की विलंबता उसके स्वयं के कार्य पर निर्भर करती है, न कि कार्यक्रम में कहीं और किसी अप्रत्याशित वैश्विक घटना पर।

ऑराबेस का बैकएंड कोर इस सिद्धांत को लागू करता है: सभी सेवाएँ (aura-gateway, aura-auth, aura-db, aura-realtime, aura-storage, aura-functions, aura-ai…) रस्ट में लिखी जाती हैं, एक एकल कार्गो कार्यक्षेत्रमें व्यवस्थित होती हैं। इसे सीधे रिपॉजिटरी में सत्यापित किया जा सकता है:

[workspace]
resolver = "2"

members = [
    "services/aura-gateway",
    "services/aura-auth",
    "services/aura-db",
    # ...9 अन्य सेवाएँ + साझा कार्य
]

[workspace.dependencies]
axum = { version = "0.8", features = ["ws", "multipart", "macros"] }

Cargo.tomlसे वास्तविक उद्धरण, कार्यक्षेत्र संस्करण 2021, रिज़ॉल्वर v2 - ऑराबेस रिपॉजिटरी में सत्यापित।

इस स्तर पर यह तथ्य क्या साबित नहीं करता है: ऑराबेस के लिए मापा गया एक पी99 विलंबता आंकड़ा। हमने अभी तक अपने स्वयं के बैकएंड के लिए एक पुनरुत्पादित बेंचमार्क पद्धति प्रकाशित नहीं की है - यह कार्य प्रगति पर है, आज कोई परिणाम उपलब्ध नहीं है। कचरा संग्रहकर्ता की अनुपस्थिति कोड में सत्यापित एक तंत्र है। यह अकेले मापी गई p99 विलंबता का प्रमाण नहीं है। विषय पर किसी भी मार्केटिंग तर्क के सामने इस अंतर को ध्यान में रखें, जिसमें हमारा तर्क भी शामिल है - आर्किटेक्चर के विवरण के लिए हमारी तकनीकी तुलना ऑराबेस बनाम सुपाबेस देखें।

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

उदाहरण के लिए, ऑराबेस में, प्रत्येक सेवा पोस्टग्रेज़ के साथ एक कनेक्शन पूल (sqlx) के माध्यम से और अन्य सेवाओं के साथ NATS JetStreamके माध्यम से संचार करती है। एक कम आकार का पूल, एक धीमी गति से उपभोग करने वाली NATS सदस्यता, या एक उपयुक्त सूचकांक के बिना एक SQL क्वेरी प्रत्येक अपनी स्वयं की विलंबता स्पाइक उत्पन्न करती है - कचरा संग्रहकर्ता की अनुपस्थिति की परवाह किए बिना।

व्यावहारिक निष्कर्ष: पी99-जागरूक प्रणाली के लिए रस्ट बैकएंड चुनने के लिए जीसी की अनुपस्थिति एक अच्छा वास्तुशिल्प कारण है। यह, अपने आप में, विलंबता की गारंटी नहीं है - न तो ऑराबेस पर, न ही कहीं और। जो विधि मायने रखती है वह वही रहती है: मापें, कार्यप्रणाली प्रकाशित करें, फिर माप से जो पता चलता है उसे सही करें। यदि आप GC के साथ बैकएंड से माइग्रेट कर रहे हैं, तो हमारा सुपाबेस टू ऑराबेस माइग्रेशन गाइड विवरण देता है कि क्या बदल रहा है और क्या वही बना हुआ है।