jemalloc क्यों मायने रखता है: बड़े पैमाने पर मेमोरी आवंटन

हर बार जब आपका प्रोग्राम malloc() कॉल करता है, तो किसी न किसी को तय करना पड़ता है कि वर्चुअल मेमोरी का कौन-सा हिस्सा वापस लौटाया जाए। छोटे प्रोग्राम के लिए यह फ़ैसला मामूली है, लेकिन बड़े पैमाने पर यह एक भारी इंजीनियरिंग समस्या बन जाता है। खराब allocator मेमोरी को फ़्रैगमेंट करता है, RAM बर्बाद करता है, थ्रेड्स के बीच lock contention पैदा करता है, और जब OS को पेज वापस लेने पड़ते हैं तो latency में उछाल ला देता है। अच्छा allocator इनमें से कुछ नहीं करता। jemalloc एक अच्छा allocator है, और Meta ने हाल ही में इसके प्रति अपनी प्रतिबद्धता दोहराई है, क्योंकि उनके स्तर पर अच्छे और औसत allocator का फ़र्क हार्डवेयर लागत में अरबों डॉलर का होता है।

ज़्यादातर डेवलपर्स मेमोरी आवंटन के बारे में सोचते ही नहीं। वे new या malloc कॉल करते हैं और एक pointer मिल जाता है। लेकिन Meta के स्तर पर, यानी रोज़ अरबों रिक्वेस्ट, लाखों सर्वर और पेटाबाइट्स RAM, allocator का व्यवहार हार्डवेयर की दक्षता, tail latency और परिचालन लागत पर सीधा और मापा जा सकने वाला असर डालता है।

मेमोरी allocator असल में क्या करता है

Memory allocator आपके प्रोग्राम और ऑपरेटिंग सिस्टम के बीच बैठता है। OS मेमोरी बड़े टुकड़ों में देता है (पेज, आमतौर पर 4KB या 2MB)। आपके प्रोग्राम को छोटे, अलग-अलग आकार के टुकड़े चाहिए (यहाँ 24 बाइट की स्ट्रिंग, वहाँ 4096 बाइट का बफ़र)। Allocator का काम है OS के दिए पेजों को आपकी ज़रूरत के हिसाब से काटना और फ़्री हुए टुकड़ों को आगे के आवंटनों के लिए दोबारा इस्तेमाल करना।

सीधा तरीका, यानी हर आवंटन के लिए OS से नया पेज माँगना और फ़्री होने पर लौटाना, बेहद धीमा है। System calls का अपना overhead होता है, और ज़्यादातर आवंटनों से पेज कहीं बड़ा होता है। 24 बाइट की स्ट्रिंग के लिए आप 4KB मेमोरी खर्च कर देंगे।

असली allocator मेमोरी का एक pool रखते हैं और उसमें से sub-allocate करते हैं। चुनौतियाँ तीन हैं: फ़्रैगमेंटेशन घटाना (आवंटनों के बीच के वे खाली गैप जो इतने छोटे हैं कि इस्तेमाल ही नहीं हो सकते), lock contention घटाना (कई थ्रेड्स एक साथ आवंटन करें तो), और overhead घटाना (हर आवंटन का metadata उसके अपने आकार के मुकाबले छोटा होना चाहिए)।

jemalloc कैसे काम करता है

jemalloc को Jason Evans ने बनाया था, इसलिए नाम में ‘je’ है। यह शुरू में FreeBSD के लिए विकसित हुआ और बाद में Meta (तब Facebook) ने C और C++ सेवाओं में इसे अपना डिफ़ॉल्ट allocator बनाया। इसका डिज़ाइन तीन मुख्य चुनौतियों को ठोस तकनीकों से हल करता है।

Thread caches contention खत्म करते हैं। हर थ्रेड को छोटे आवंटनों का अपना cache मिलता है। जब कोई थ्रेड छोटी वस्तु के लिए malloc() कॉल करता है, तो आवंटन पूरी तरह उसके लोकल cache से होता है, बिना lock, बिना atomic operations और बिना contention के। केवल तब जब thread cache खत्म हो जाता है, वह refill के लिए shared arena तक जाता है।

jemalloc allocation flow:
Thread calls malloc(64)
↓
Check thread cache for 64-byte size class
→ Hit: return cached chunk (no lock, no contention)
→ Miss: refill from arena
↓
Arena (shared, but per-thread affinity)
→ Find a partially-full slab for 64-byte objects
→ Carve out a chunk
→ Return to thread cache
↓
Return chunk to caller
Thread caches handle 95%+ of allocations without any locking.

Size classes फ़्रैगमेंटेशन घटाती हैं। jemalloc माँगे गए बाइट्स की ठीक संख्या देने के बजाय निकटतम size class तक ऊपर गोल कर देता है। Size classes सावधानी से चुनी गई हैं: 8, 16, 32, 48, 64, 80, 96, 112, 128, 160, 192, 224, 256 और आगे, जहाँ आकार बढ़ने के साथ अंतर भी बढ़ता है। यानी 50 बाइट के आवंटन को 64 बाइट का टुकड़ा मिलता है (23% बर्बादी)। सुनने में बुरा लगता है, लेकिन असल में यह अच्छा है, क्योंकि एक ही size class के सारे 64 बाइट के टुकड़े आपस में बदले जा सकते हैं, इसलिए उस class के भीतर बाहरी फ़्रैगमेंटेशन लगभग शून्य है।

Slabs एक जैसे आकार के आवंटनों को व्यवस्थित करते हैं। हर slab मेमोरी का एक सटीक क्षेत्र है जिसे एक ही size class के टुकड़ों में बाँटा गया है। 64 बाइट की वस्तुओं वाला slab केवल 64 बाइट के टुकड़ों से भरा होता है। इससे फ़्रैगमेंटेशन का सबसे खराब रूप खत्म हो जाता है, जहाँ फ़्री हुई मेमोरी इसलिए दोबारा इस्तेमाल नहीं हो पाती क्योंकि वह अलग आकार के सक्रिय आवंटनों के बीच फँसी होती है।

फ़्रैगमेंटेशन की समस्या

Memory fragmentation लंबे समय तक चलने वाली सेवाओं का खामोश कातिल है। ताज़ा शुरू हुआ सर्वर मेमोरी कुशलता से इस्तेमाल करता है, आवंटन कसकर पैक होते हैं। लेकिन दिनों या हफ़्तों तक मिले-जुले आवंटन और फ़्री होने के बाद heap Swiss cheese जैसा हो जाता है: सक्रिय आवंटनों के बीच छोटे-छोटे खाली गैप भरे पड़े होते हैं। कुल खाली मेमोरी शायद 2GB हो, पर सबसे बड़ा लगातार खाली हिस्सा सिर्फ़ 64KB का हो सकता है।

बाहरी फ़्रैगमेंटेशन (आवंटनों के बीच बेकार गैप) और आंतरिक फ़्रैगमेंटेशन (गोल करने से आवंटन के भीतर बची जगह), दोनों मायने रखते हैं, लेकिन बाहरी वाला ज़्यादा खतरनाक है। आंतरिक फ़्रैगमेंटेशन size class के अंतर से सीमित रहता है, यानी ज़्यादा से ज़्यादा हर आवंटन में लगभग 25% बर्बादी। बाहरी फ़्रैगमेंटेशन की कोई सीमा नहीं है और समय के साथ बढ़ता जाता है।

jemalloc का slab-आधारित तरीका छोटे आवंटनों (जो ज़्यादातर आवंटन होते हैं) के लिए बाहरी फ़्रैगमेंटेशन को काफ़ी हद तक खत्म कर देता है। चूँकि slab की सारी वस्तुएँ एक ही आकार की हैं, एक वस्तु फ़्री होने पर जो गड्ढा बनता है वह उसी size class के अगले आवंटन के लिए बिल्कुल सही आकार का होता है। कोई बेकार गैप नहीं बचता।

बड़े आवंटनों (आमतौर पर 14KB से ऊपर) के लिए jemalloc अलग रणनीति अपनाता है। इन्हें अपने पेज मिलते हैं, और फ़्री हुए पेज OS को लौटाए जा सकते हैं या अलग size classes के लिए दोबारा इस्तेमाल हो सकते हैं। यहाँ फ़्रैगमेंटेशन अब भी हो सकता है, लेकिन बड़े आवंटन अपेक्षाकृत कम होते हैं।

jemalloc बनाम glibc malloc बनाम tcmalloc

Linux इकोसिस्टम के तीन मुख्य allocator अलग-अलग समझौते करते हैं।

• glibc malloc (ptmalloc2) ज़्यादातर Linux सिस्टम्स पर डिफ़ॉल्ट है। यह थ्रेड स्केलेबिलिटी के लिए arenas इस्तेमाल करता है, लेकिन jemalloc से कम size classes रखता है, जिससे लंबे समय तक चलने वाली सेवाओं में ज़्यादा फ़्रैगमेंटेशन होता है। इसका मुख्य फ़ायदा यह है कि यह डिफ़ॉल्ट है, इसलिए कोई कॉन्फ़िगरेशन नहीं चाहिए।
• tcmalloc (Google) एक thread-caching malloc है, जो मूल रूप से Google की C++ सेवाओं के लिए बना था। इसमें बेहतरीन thread-local caching है और overhead कम है। यह उन workloads के लिए अच्छा है जिनमें छोटे-समय के आवंटन बहुत होते हैं, और उन workloads के लिए कम उपयुक्त है जिनमें मेमोरी पर भारी दबाव हो और फ़्रैगमेंटेशन मायने रखता हो।
• jemalloc लगातार लोड के तहत कम फ़्रैगमेंटेशन और अनुमानित व्यवहार के लिए अनुकूलित है। यह दूसरों से ज़्यादा परिष्कृत size classes और slab प्रबंधन इस्तेमाल करता है। समझौता यह है: हर आवंटन पर थोड़ा ज़्यादा overhead (ज़्यादा metadata), बदले में समय के साथ बेहतर मेमोरी दक्षता।

सही चुनाव आपके workload पर निर्भर करता है। छोटे-समय के प्रोसेस के लिए तीनों लगभग एक जैसा प्रदर्शन करते हैं। मिश्रित आवंटन पैटर्न वाले लंबे समय तक चलने वाले सर्वरों (web servers, databases, caches) के लिए jemalloc का फ़्रैगमेंटेशन-प्रतिरोध आम तौर पर जीतता है। एक ही workload के लिए आप glibc malloc की तुलना में 10-30% कम RAM इस्तेमाल करते हैं, और बड़े पैमाने पर यह सीधे हार्डवेयर की बचत में बदल जाता है।

Meta को इसकी परवाह क्यों है

Meta के स्तर पर, उनकी C++ सेवाओं में मेमोरी उपयोग में 10% की कमी हर महीने लाखों डॉलर की हार्डवेयर लागत बचाती है। सालाना नहीं, महीने के हिसाब से। जब आप लाखों सर्वर चला रहे हों, और हर सर्वर पर चलने वाली सेवाएँ रोज़ अरबों बार मेमोरी आवंटित और फ़्री करती हों, तो allocator की दक्षता बजट की एक लाइन-आइटम बन जाती है।

Meta का jemalloc में नया निवेश कई क्षेत्रों पर केंद्रित है: बेहतर huge page सपोर्ट (बड़ी मेमोरी वाले सिस्टम्स पर TLB misses घटाना), OS को मेमोरी लौटाने का बेहतर तरीका (लोड घटने पर resident memory कम करना), और बेहतर profiling tools (यह समझना कि मेमोरी कहाँ इस्तेमाल हो रही है और कहाँ बर्बाद हो रही है)।

Profiling वाला हिस्सा खास दिलचस्प है। jemalloc में built-in heap profiling है: आप उसे कुछ आवंटनों का सैंपल लेने को कह सकते हैं, और वह एक profile बनाता है जिसमें दिखता है कि मेमोरी कहाँ आवंटित हुई, कितनी सक्रिय है बनाम फ़्री, और heap कितना फ़्रैगमेंटेड है। Production में इस profiling का overhead लगभग शून्य है, इसलिए इसे production सर्वरों पर लगातार चलाना व्यावहारिक हो जाता है।

अपने प्रोजेक्ट में jemalloc का इस्तेमाल

C/C++ प्रोग्राम्स के लिए jemalloc पर स्विच करना आमतौर पर बेहद आसान है। Linux पर आप या तो इसे सीधे link कर सकते हैं, या LD_PRELOAD से रनटाइम पर inject कर सकते हैं, बिना कोड बदले।

# Install jemalloc
sudo apt install libjemalloc-dev  # Debian/Ubuntu
brew install jemalloc             # macOS
# Use LD_PRELOAD — works with any program, no recompilation
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so ./my_server
# Or link at compile time
gcc -o my_server my_server.c -ljemalloc
# Enable profiling
export MALLOC_CONF="prof:true,prof_prefix:jeprof"
./my_server
# Then analyze: jeprof --svg ./my_server jeprof.*.heap > heap.svg

कई बड़े प्रोजेक्ट्स डिफ़ॉल्ट रूप से jemalloc इस्तेमाल करते हैं: Redis, Rust (कुछ प्लेटफ़ॉर्म्स पर इसका डिफ़ॉल्ट allocator), Firefox (jemalloc मूल रूप से FreeBSD के लिए बना था, जिसे Firefox निशाना बनाता था), और कई game engines।

Managed memory वाली भाषाओं (Python, Java, Go) में language runtime ही आवंटन संभालता है, इसलिए jemalloc सीधे लागू नहीं होता। लेकिन इसके विचार, जैसे thread-local caching, size classes और slab allocation, हर आधुनिक runtime के garbage collector और memory allocator में दिखते हैं। उदाहरण के लिए Go का runtime allocator tcmalloc से प्रेरित डिज़ाइन इस्तेमाल करता है, जिसमें per-P (processor) caches और size classes हैं।

अदृश्य इन्फ्रास्ट्रक्चर

मेमोरी आवंटन ऐसा इन्फ्रास्ट्रक्चर है जो काम करते समय दिखता ही नहीं, और गड़बड़ होने पर तबाही मचा देता है। फ़्रैगमेंटेशन की वजह से धीरे-धीरे मेमोरी लीक करने वाला सर्वर आखिरकार OOM-kill हो जाएगा, और इसका कारण किसी application log में नहीं दिखेगा, क्योंकि समस्या application layer के नीचे होती है।

ज़्यादातर applications के लिए डिफ़ॉल्ट allocator ठीक है। लेकिन अगर आप लंबे समय तक चलने वाले सर्वर चला रहे हैं, अनजाने मेमोरी बढ़ने की समस्या झेल रहे हैं, या ऐसे पैमाने पर काम कर रहे हैं जहाँ हार्डवेयर दक्षता मायने रखती है, तो अपने allocator को समझना, और ज़रूरत पड़ने पर बेहतर विकल्प पर जाना, सबसे असरदार इन्फ्रास्ट्रक्चर बदलावों में से एक है। jemalloc कोई जादू नहीं है। यह इंजीनियरिंग है: सावधान data structure डिज़ाइन, सोच-समझकर लिए गए समझौते, और उन बारीकियों पर लगातार ध्यान जो बड़े पैमाने पर मायने रखती हैं।