tmpfs में 870 MB की एक फ़ाइल, और उसके बाद हुआ रीबूट

28 अगस्त को 19:35 पर मैंने एक दिन का एक्सेस लॉग अनपैक करके /tmp में रखा, ताकि दो दिन एक ही बार में पढ़े जा सकें। 19:44 पर मशीन रीबूट हो गई।

वह विशेषता, जिसे जाँचा नहीं गया

इस मशीन पर /tmp एक tmpfs-फ़ाइल सिस्टम है। यानी यह मेमोरी है। df 1.9 GB खाली दिखाता है और इस बारे में कुछ भी नहीं बताता कि यह जगह आती कहाँ से है – और मशीन में कुल 3,794 MB मेमोरी है।

यानी 870 MB की एक फ़ाइल एक छोटे सर्वर की एक-चौथाई मेमोरी में चली गई – ऐसे सर्वर की, जो साथ ही एक वेबसाइट भी चला रहा था और किसी और का टेस्ट जॉब भी। नौ मिनट बाद SSH ने कनेक्शन लेना बंद कर दिया, वेबसाइट ने 0.1 की जगह 11 सेकंड में जवाब दिया, और उसके कुछ ही देर बाद मशीन शून्य मिनट के अपटाइम के साथ वापस आ गई।

क्या कहा जा सकता है और क्या नहीं

MariaDB क्रैश रिकवरी के साथ शुरू हुआ, यानी शटडाउन ठीक से नहीं हुआ था। इससे आगे ईमानदार जवाब यही है कि इसे साबित नहीं किया जा सकता: इस मशीन का जर्नल अस्थायी है, इसलिए वह रीबूट के बाद नहीं बचता, और कोई kern.log नहीं है, जिसमें मेमोरी खत्म होने (out-of-memory) की कोई लाइन हो। सबूत बस इतना है: घटना से नौ मिनट पहले का एक टाइमस्टैंप और गलत जगह पर पड़ी एक फ़ाइल।

इसे निष्कर्ष के रूप में नहीं, बल्कि जैसा है वैसा ही लिख लेना ठीक है। “मेमोरी भर गई और कर्नेल ने हार मान ली” एक विश्वसनीय लगने वाली कहानी है। लेकिन यह मापी हुई कहानी नहीं है, और यहाँ यह फ़र्क किसी निश्चितता के दावे से ज़्यादा मायने रखता है।

नुकसान कितना हुआ

ऐसा कोई नुकसान नहीं मिला। CHECK TABLE पाँच सबसे अहम टेबलों पर OK लौटा, पंक्तियों की संख्या नहीं बदली थी, उसी दिन की गिनती दर्ज होती रही, और सभी सोलह शेड्यूल किए गए जॉब सही-सलामत थे। वेबसाइट फिर से 0.14 सेकंड में जवाब देने लगी।

एक चीज़ खो गई: उसी मशीन पर किसी दूसरे सेशन का एक लंबे समय से चल रहा जॉब। उसका इस काम से कोई लेना-देना नहीं था, और वह भी बाकी सब के साथ बंद हो गया – आउटेज का यही वह हिस्सा है, जिसकी खबर कोई स्थानीय जाँच नहीं देती।

इससे निकला नियम

यहाँ लॉग फ़ाइलें रोज़ 700 से 900 MB की होती हैं। ऐसी एक फ़ाइल को /tmp में अनपैक करने का मतलब है मशीन की एक-चौथाई मेमोरी को ऐसी जगह रखना, जो डिस्क जैसी दिखती है और RAM की तरह बर्ताव करती है।

प्रोसेसिंग के बीच बनने वाली बड़ी फ़ाइलें /var/tmp या होम डायरेक्टरी में जाती हैं – ये दोनों डिस्क पर हैं। उससे भी बेहतर है कि उन्हें अनपैक ही न किया जाए: zcat -f file.gz | awk ... स्ट्रीम में पढ़ता है और उसे कोई गंतव्य नहीं चाहिए। इसके बाद की पोस्टों में हर माप इसी तरह लिया गया।

आम सबक

फ़ाइल सिस्टम बताता है कि उसमें कितनी जगह है। वह यह नहीं बताता कि वह जगह किस चीज़ से बनी है, और ठीक उन्हीं सिस्टमों पर, जहाँ इसका सबसे ज़्यादा महत्व है, इन दोनों सवालों के जवाब अलग-अलग होते हैं।

जाँच बस एक लाइन की है, और उसे इसलिए छोड़ दिया गया, क्योंकि फ़ाइल “अस्थायी” थी। अस्थायी होना सच था। बस सोचने के लिए वह गलत विशेषता थी।