MiB से GiB में बदलें

एक मेबीबाइट 1,024 किबीबाइट की है, यानी 1,048,576 बाइट। Linux के औज़ार और याददाश्त की संख्याएँ लगभग हमेशा यही कहती हैं, भले लिखा «MB» हो।

एक गिबीबाइट 1,073,741,824 बाइट की है, यानी गीगाबाइट से क़रीब 7% ज़्यादा। Windows गिबीबाइट में नापता है पर उन्हें «GB» कहता है — और «जगह कम क्यों दिख रही है» वाली पूरी पहेली इसी में है।

इस तरफ़ हिसाब भाग का है, और वह भी पूरे अंक से: 1,024 इकाइयाँ एक गिबीबाइट में बिना कुछ बचे समा जाती हैं। असुविधा बस इतनी है कि नतीजे भिन्न में आते हैं — एक तिहाई, एक बटा बारह — उन गोल अंकों की जगह जो उलटी दिशा देती है।

फिर भी गोलाई में कुछ नहीं खोता, क्योंकि भाग पूरा उतरता है। अगर नतीजा दशमलव में टिकता ही न हो — 0.0833… और उसके जैसे — तो वह भिन्न झलक रही है, कोई ग़लती नहीं घुस रही।

एक MiB अपने नीचे वाली इकाई का 1,024 गुना होता है; एक MB 1,000 गुना। इस पेज पर यह 0.001 GiB और 0.0009 GiB का फ़र्क़ है — 4.9 % — और हर सीढ़ी पर यह फ़ासला बढ़ता जाता है। इसीलिए एक तस्वीर पर यह गोलाई भर है और हार्ड डिस्क पर दिखने लायक़ हिस्सा।

ग़ायब जगह का पूरा रहस्य इतना ही है, और इस पेज पर वह 4.9 % का बनता है। MB के नाम पर बिकी डिस्क में ठीक उतना ही होता है जितना डिब्बे पर लिखा है — दशमलव हिसाब से एक MB यानी 0.0009 GiB। विंडोज़ उसे 1,000 के बजाय 1,024 से बाँटता है और नाम दशमलव वाला ही रखता है, इसलिए उसका «एक MB» दरअसल 0.001 GiB का निकलता है और डिस्क का अंक उतना ही छोटा दिखने लगता है। ऐपल का मैकओएस 10.6 से इन्हें दशमलव इकाइयों में ही गिनता है, और यही वजह है कि एक ही डिस्क दो मशीनों पर दो अलग आकार की दिख सकती है। न कुछ ग़ायब हुआ है, न कोई गोलाई हुई है — वही बाइट दो नामों से गिने जा रहे हैं।

Kubernetes resource quantity दो तरह के प्रत्यय स्वीकारता है। Binary सेट — Ki, Mi, Gi, Ti, Pi, Ei — 1,024 की घातों से गुणा करता है। Decimal सेट — m, k, M, G, T, P, E — 1,000 की घातों से गुणा करता है। memory: 512Mi और memory: 512M दोनों वैध हैं, 24,870,912 बाइट अलग हैं, और कोई चेतावनी नहीं मिलती।

मेबिबाइट क़दम पर 4.9 प्रतिशत का फ़र्क़ गिबिबाइट क़दम पर 7.4 प्रतिशत तक बढ़ता है: 4Gi 4,294,967,296 बाइट है और 4G 4,000,000,000। किसी रिपॉज़िटरी में memory फ़ील्ड में सादा M या G खोजना पाँच-मिनट की जाँच है जो एक बार करने लायक़ है।

CPU compressible है: सीमा से ज़्यादा माँगने वाला कंटेनर धीमा हो जाता है और चलता रहता है। Memory नहीं। जब कंटेनर का cgroup अपनी memory सीमा पार करता है, kernel का OOM killer उसके भीतर की एक प्रोसेस ख़त्म कर देता है, कंटेनर exit code 137 बताता है, और pod दोबारा शुरू होता है।

इसका मतलब यह भी है दोनों प्रत्यय असमान रूप से नाकाम होते हैं। Mi की जगह M लिखना सीमा छोटी करता है और कंटेनर को मारे जाने के क़रीब लाता है — एक दिखने वाली नाकामी जिसकी जाँच होती है। M की जगह Mi लिखना उसे बड़ा करता है, जो node overcommitted होने तक कुछ नहीं दिखाता।

-Xmx4096m से शुरू JVM का heap 4 GiB है और कुल footprint काफ़ी बड़ा। Metaspace class metadata रखता है और डिफ़ॉल्ट रूप से असीमित है; हर thread अपना stack लेता है, आम तौर पर 1 MiB, heap के बाहर; JIT का code cache 64-बिट HotSpot पर डिफ़ॉल्ट 240 MiB है।

आम तरीक़ा है कंटेनर को heap से 25 से 50 प्रतिशत ज़्यादा देना, या -Xmx सेट करना बंद करके JVM को ख़ुद आकार तय करने देना। JDK 10 से runtime cgroup सीमा पढ़ता है और -XX:MaxRAMPercentage लागू करता है, जिसका डिफ़ॉल्ट 25 है।

16 GiB बताया node pod को 16,384 MiB नहीं देता। Capacity माइनस kube-reserved माइनस system-reserved माइनस hard eviction threshold allocatable देता है, और managed cluster पर reservation छोटे node पर कुछ सौ MiB से बड़े पर एक GiB से ज़्यादा तक होता है। kubectl describe node capacity और allocatable दोनों दिखाता है।

यहीं गिबिबाइट में बदलना अपनी क़ीमत चुकाता है, क्योंकि मेबिबाइट में bin-packing हिसाब ग़लती न्योता देता है। 1,536Mi पर नौ replica 13,824Mi है, यानी 13.5 GiB, जो 14.6 GiB allocatable में daemonset के लिए जगह छोड़ते हुए समा जाता है।

Request वह है जो scheduler आरक्षित करता है और limit वह जो kernel लागू करता है, और दोनों के बीच का रिश्ता pod की eviction प्राथमिकता तय करता है। बराबर request और limit Guaranteed देता है; limit से कम request Burstable देता है; दोनों सेट न होना BestEffort देता है।

ख़ासकर memory के लिए, दोनों बराबर रखने की दलील CPU से मज़बूत है। जो Burstable pod अपने request से ज़्यादा इस्तेमाल करता है वह छोटा मानकर shedule होता है और बड़ा मानकर मारा जाता है। जहाँ working set पता है, एक ही गिबिबाइट आँकड़ा दो बार लिखना सादा और ईमानदार है।

Manifest 1536Mi कहता है; Grafana 1.5 GiB कहता है; cloud console 1.61 GB कहता है; लागत रिपोर्ट 1.6 GB-घंटे कहती है। ये चारों एक ही 1,610,612,736 बाइट हैं, चार अलग रिवाज़ वाले टूल से पेश। बिल को manifest से मिलाने के लिए यह जानना ज़रूरी है हर आँकड़ा किस तरफ़ है।

मदद करने वाली आदत है हर दस्तावेज़ में एक ही मानक इकाई रखना। Capacity योजना गिबिबाइट में, manifest जो भी Mi या Gi संख्या को पूरा रखे उसमें, और दशमलव इकाई में बताया कोई भी आँकड़ा उसी तरह लेबल किया हुआ।

बदलने लायक़ आँकड़ा वही है जो workload असल में इस्तेमाल करता है, और container_memory_working_set_bytes वह मीट्रिक है जिस पर kernel और OOM killer असल में काम करते हैं। दो हफ़्ते की चोटी लेकर, गुंजाइश जोड़कर, और सुथरे मेबिबाइट या गिबिबाइट आँकड़े तक गोल करके ऐसी सीमा बनती है जिसे बचाया जा सके।

जहाँ चुनाव मुफ़्त हो, दो की घात तक ऊपर गोल कीजिए। 1,536Mi की सीमा 1.5 GiB है और गिबिबाइट में नापे node में साफ़ समाती है; 1,600Mi की सीमा 1.5625 GiB है, बुरी तरह समाती है, और अगले पाठक को बताती है यह संख्या ऊपर कहीं दशमलव गणना से आई।