जगह ख़त्म हो जाना सर्वर के बिना किसी बुरी नीयत के काम करना बंद कर देने का सबसे आम कारण है। साइट 500 लौटाती है, डेटाबेस लिख नहीं पाता, मेल बाहर नहीं जाती — और df -h इस बीच कई ख़ाली गीगाबाइट बताता है। आइए उन तीनों स्थितियों से गुज़रें जहाँ ऐसा होता है, और उससे भी जो SMART के बारे में जानने लायक है।

पहली स्थिति: inode ख़त्म

फ़ाइल सिस्टम में दो सीमित संसाधन होते हैं: सामग्री के लिए जगह और फ़ाइलों के बारे में प्रविष्टियाँ। दूसरा पहले से स्वतंत्र रूप से ख़त्म होता है:

df -h
df -i

अगर दूसरी कमांड में IUse% 100 है, तो समस्या inode की है। जगह है, पर एक भी फ़ाइल नहीं बनाई जा सकती, ख़ाली भी नहीं।

दोषी हमेशा वही होते हैं: लाखों नन्ही फ़ाइलें। /var/lib/php/sessions में PHP सत्र जिनकी कचरा सफ़ाई टूट गई। एप्लिकेशन का कैश जो कभी साफ़ नहीं होता। अटकी हुई मेल क़तार। थंबनेल की डायरेक्टरी। इन्हें यूँ ढूँढ़ा जा सकता है:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

कमांड सबसे ज़्यादा फ़ाइलों वाली डायरेक्टरियाँ गिनाती है। बड़े सिस्टम पर यह मिनटों चलती है — यह सामान्य है।

दूसरी स्थिति: फ़ाइल मिट गई और जगह नहीं लौटी

और भी छली स्थिति। किसी ने बढ़ा हुआ लॉग rm से हटा दिया, पर उसमें लिखती प्रक्रिया उसे अब भी खुला पकड़े है। फ़ाइल डायरेक्टरी में नहीं रही, जगह अब भी घिरी है, और तब तक ऐसी ही रहेगी जब तक प्रक्रिया दोबारा चालू न हो।

sudo lsof +L1

कमांड ऐसी फ़ाइलें दिखाती है जिनकी फ़ाइल सिस्टम में शून्य कड़ियाँ हैं पर कोई प्रक्रिया उन्हें अब भी पकड़े है। इलाज उस प्रक्रिया को दोबारा चालू करना या नरमी से लोड करना है, न कि «गीगाबाइट कहाँ गए» की तलाश।

इससे नियम बनता है: बढ़ा हुआ लॉग मिटाया नहीं, ख़ाली किया जाता है, जिससे खुला descriptor काम लायक बना रहता है:

sudo truncate -s 0 /var/log/huge.log

और तुरंत बाद रोटेशन सेट करें — वरना यही सब एक हफ़्ते में दोहराएगा।

तीसरी स्थिति: लॉग खा गए

जगह कहाँ गई, यह स्तर-दर-स्तर नीचे उतरकर दिखता है:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

-x झंडा इसे दूसरे फ़ाइल सिस्टमों में भटकने से रोकता है; उसके बिना गिनती /proc और नेटवर्क माउंट में घुस जाती है। यह सब ncdu में अधिक आरामदेह है, अगर वह उपलब्ध हो।

आम भक्षक:

  • journald। एक कमांड सब तय कर देती है: journalctl --disk-usage। इसे /etc/systemd/journald.conf में SystemMaxUse=500M पंक्ति से सीमित किया जाता है और journalctl --vacuum-size=200M से एक बार साफ़;
  • सुरक्षा औज़ारों के लॉग। Suricata अपनी मानक व्यवस्था के साथ तीस तरह की घटनाएँ लिखता है और अपने लिए रोटेशन सेट नहीं करता — असली सर्वर पर इसने दो दिन में 15 GB बनाए। यही audit.log के साथ और nginx के डिबग लॉग के साथ होता है;
  • बैकअप जो उसी डिस्क पर लिखे जाते हैं और कभी हटाए नहीं जाते;
  • apt का कैश — apt clean कभी-कभी दो-एक गीगाबाइट लौटा देता है।

/boot के बारे में दो शब्द

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

SMART: कौन सी विशेषताएँ मायने रखती हैं

पहले एक चेतावनी: वर्चुअल सर्वर पर SMART आमतौर पर उपलब्ध नहीं होता — डिस्क आभासी है और उसके नीचे की भौतिक डिस्क आप नहीं देखते। यह ख़राबी नहीं, बस डेटा है ही नहीं। आगे की सब बात समर्पित सर्वरों और अपने हार्डवेयर के बारे में है।

sudo smartctl -a /dev/sda

पंक्ति SMART overall-health self-assessment test result: PASSED निश्चिंत होने का कारण नहीं: वह ड्राइव के मरने तक व्यावहारिक रूप से हरी बनी रहती है। देखने लायक ठोस गिनतियाँ हैं:

  • 5, Reallocated_Sector_Ct — पुनर्आवंटित सेक्टर। शून्य न होना बताता है कि ड्राइव पहले से बिगड़ रही है; समय के साथ बढ़ना बताता है कि बिना देर बदल दें;
  • 197, Current_Pending_Sector — वे सेक्टर जो पढ़े नहीं जा सकते और निर्णय की प्रतीक्षा में हैं। इनमें सबसे चिंताजनक: आमतौर पर इसका मतलब है कि डेटा का हिस्सा पहले ही अपुनर्प्राप्य है;
  • 198, Offline_Uncorrectable — वही, जाँच से पुष्ट;
  • SSD: Percentage Used / Media_Wearout_Indicator — लिखने की खपी हुई सहनशक्ति। पूर्वानुमेय आँकड़ा, और वही जिसके सापेक्ष बदलने की योजना बनती है।

दूसरी ओर तापमान और चालू रहने के घंटे अपने-आप में कुछ नहीं कहते: पाँच साल चली और त्रुटि गिनतियाँ शून्य वाली ड्राइव विशेषता 197 में 1 वाली नई ड्राइव से ज़्यादा भरोसेमंद है।

निगरानी का मतलब

ऊपर की सब बातें उस पर प्रतिक्रिया हैं जो हो चुका। जबकि भरती डिस्क और SSD की घिसाई दोनों धीमी, पूरी तरह पूर्वानुमेय प्रक्रियाएँ हैं: दो हफ़्तों के क़ब्ज़े का ग्राफ़ जगह ख़त्म होने की तारीख़ बहुत पहले दिखा देता है। «साइट तीन बजे रात से बंद है» और «गुरुवार को लॉग साफ़ करने हैं» के बीच का फ़र्क़ सिर्फ़ इतना है कि आँकड़ा आपके सामने हो। जुड़ा हुआ यह कैसा लगता है, नीचे डेमो पेज पर।