HestiaCP मा inode को प्रयोग कसरी जाँच गर्ने? प्रशस्त डिस्क स्पेस हुँदा पनि फाइलहरू लेख्न नसक्नुको कारण के हो?

केही दिन अघि, एक जना साथीले मलाई अबेर राति म्यासेज गरेर भन्यो कि उसको सर्भर क्र्यास भएको छ।

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

तर जब उनले `df -h` प्रयोग गरेर जाँच गरे, डिस्कमा दशौं गिगाबाइट खाली ठाउँ भएको थाहा पाएर उनी छक्क परे। यो कसरी भरिन सक्छ?

मैले उसलाई त्यहीँ भनेँ, "भाइ, तिमी भण्डारण ठाउँले मात्र भरिएका छैनौ, तिम्रो इनोड ओभरलोड छ।"

उनले प्रश्न चिन्हसहित जवाफ दिए: इनोड भनेको के हो?

वास्तवमा, धेरै मानिसहरूले पहिलो पटक यो पासोमा पर्दा उनले जस्तै प्रतिक्रिया देखाउँछन्, किनभने स्कूलमा कसैले पनि उनीहरूलाई यो कुरा कहिल्यै सिकाएको थिएन।

पहिले Inode भनेको के हो भनेर स्पष्ट पारौं।

यसलाई पुस्तकालय अनुक्रमणिका कार्डको रूपमा सोच्नुहोस्, र यो बुझ्न सजिलो हुनेछ।

डिस्क स्पेस भनेको बुकशेल्फ जस्तै हो; तपाईंले यसमा कतिवटा पुस्तकहरू राख्न सक्नुहुन्छ भन्ने कुरा यसको क्षमतामा निर्भर गर्दछ, जुन सबैलाई बुझ्न सजिलो छ।

एउटा इनोड भनेको प्रत्येक पुस्तकको लागि एउटा इन्डेक्स कार्ड जस्तै हो, जसमा त्यसको नाम, स्थान र यसलाई कसले सार्यो भनेर रेकर्ड गरिएको हुन्छ।

लिनक्समा , प्रत्येक फाइल र प्रत्येक डाइरेक्टरीले एउटा इनोड ओगटेको हुनुपर्छ, चाहे फाइल जतिसुकै सानो किन नहोस् ।

यदि यो खाली फाइल हो भने पनि, प्रणालीले यसको लागि अनुक्रमणिका कार्ड खपत गर्नेछ।

प्रणालीमा यसले सिर्जना गर्न सक्ने कुल फाइलहरूको संख्याको सीमा छ; यो सीमा इननोडहरूको कुल संख्या हो।

एक पटक इनोड प्रयोग भइसकेपछि, तपाईंको डिस्कमा सयौं गिगाबाइट खाली ठाउँ भए पनि, अपरेटिङ सिस्टमले कुनै पनि नयाँ फाइलहरू सिर्जना गर्न अस्वीकार गर्नेछ।

लगहरू लेख्न सकिँदैन, क्यास सिर्जना गर्न सकिँदैन, र वेबसाइट पूर्ण रूपमा क्र्यास हुन्छ—त्यो विचित्र दृश्य हो जुन तपाईंले देखिरहनुभएको छ।

इमानदारीपूर्वक भन्नुपर्दा, यो साँच्चै कठिन परिस्थिति हो किनभने त्रुटि सन्देश तपाईंले नहेर्नु भएको स्थानबाट पठाइएको हो।

पहिलो तरिका भनेको द्रुत सिंहावलोकन प्राप्त गर्न `df -i` प्रयोग गर्नु हो।

HestiaCP वातावरणमा , तपाईंले टर्मिनलमा SSH गरेर यो लाइन टाइप गर्न सक्नुहुन्छ।

df -i

यसले प्रत्येक माउन्ट गरिएको विभाजनको लागि इनोडहरूको कुल संख्या, प्रयोग गरिएको संख्या र बाँकी रहेको संख्या सूचीबद्ध गर्नेछ।

आउटपुटमा, IUse% भनिने स्तम्भ छ, जुन तपाईंले ध्यान दिनुपर्ने मुख्य मेट्रिक हो।

यदि कुनै विभाजनको IUse% १००% पुग्यो भने, त्यो विभाजनमा अझै प्रशस्त डिस्क स्पेस भए पनि, यसले अब कुनै पनि नयाँ फाइल वा लगहरू सिर्जना गर्न सक्षम हुनेछैन।

मैले मेरो साथीलाई पहिले यो चलाउन सुझाव दिएँ, ताकि समस्या Inode मा छ कि छैन भनेर एक सेकेन्डमा पत्ता लगाउन सकियोस् , जुन अनुमान गर्नु भन्दा धेरै छिटो हुनेछ।

दोस्रो विधि भनेको कुनै खास प्रयोगकर्तालाई ठ्याक्कै गणना गर्न `find` प्रयोग गर्नु हो।

समस्या इनोडमा छ भनेर पुष्टि गरेपछि, अर्को चरण भनेको इन्डेक्स कार्ड कसले अत्यधिक खपत गरिरहेको छ भनेर पत्ता लगाउनु हो।

HestiaCP मा प्रत्येक प्रयोगकर्ताको लागि छुट्टै गृह निर्देशिका छ। तपाईंले विशेष वेबसाइट निर्देशिका अन्तर्गत फाइल र निर्देशिकाहरूको कुल संख्या गणना गर्न सक्नुहुन्छ।

find /home/用户名/web/你的域名/public_html | wc -l

"username" र "your domain name" लाई तपाईंको वास्तविक मार्गले बदल्नुहोस्। टर्मिनलले फर्काएको शुद्ध संख्या त्यो डाइरेक्टरीमा रहेका सबै फाइल र फोल्डरहरूको योगफल हो।

प्रत्येक फाइल वा डाइरेक्टरी एउटा इनोडसँग मेल खान्छ, त्यसैले यो संख्याले इनोड प्रयोगलाई प्रतिनिधित्व गर्दछ।

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

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

यो लाइनले /home अन्तर्गत प्रत्येक प्रयोगकर्ता डाइरेक्टरीमा फाइलहरूको कुल संख्या छाप्नेछ, जसले गर्दा कुन प्रयोगकर्ता डाइरेक्टरीमा असामान्य रूपमा उच्च संख्यामा फाइलहरू छन् भनेर पत्ता लगाउन सजिलो हुनेछ।

तेस्रो रणनीति भनेको सबैभन्दा बढी आयोडिन खपत गर्ने उपनिर्देशिकाहरू पहिचान गर्नु हो।

कहिलेकाहीँ तपाईंलाई थाहा हुन्छ कि वेबसाइटमा हास्यास्पद रूपमा उच्च Inode मानहरू छन्, तर तपाईं अझै पनि फाइलहरूले भरिएको स्क्रिनमा के गलत छ भनेर पत्ता लगाउन सक्नुहुन्न।

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

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

यो आदेशले सबैभन्दा धेरै फाइलहरू खपत गर्ने शीर्ष १० उपफोल्डरहरूको सूची दिनेछ।

सूचीको सबैभन्दा माथि रहेको बाटो त्यो हो जहाँ धेरै संख्यामा साना फाइलहरू एकसाथ क्लस्टर गरिएका हुन्छन्।

मैले मेरो साथीलाई भनें कि यो सायद कुनै क्यासिङ प्लगइनले गोप्य रूपमा साना फाइलहरू उत्पन्न गरिरहेको थियो, र यो लाइन चलाउँदा मूल रूपमा यो पुष्टि हुनेछ।

चौथो सुझाव भनेको repquota प्रयोग गरेर कोटा सीमा जाँच गर्नु हो।

यदि तपाईंको सर्भरमा Linux फाइल प्रणाली कोटा सक्षम छ भने, तपाईं समस्यालाई फरक दृष्टिकोणबाट हेर्न सक्नुहुन्छ।

repquota -a

यो आदेशले सबै प्रयोगकर्ताहरूको लागि फाइल सीमा र वास्तविक फाइल प्रयोग बढाउनेछ।

आउटपुटमा रहेको फाइल सीमा खण्डमा ध्यान दिनुहोस्; प्रयोग गरिएको स्तम्भले कति फाइलहरू प्रयोग गरिएको छ भनेर संकेत गर्दछ।

"नरम" र "कडा" स्तम्भहरूले नरम र कडा सीमा थ्रेसहोल्डहरू प्रतिनिधित्व गर्छन्। एक पटक "प्रयोग गरिएको" "कडा" पुगेपछि, प्रणालीले नयाँ फाइलहरू सिर्जना गर्न सिधै अस्वीकार गर्नेछ।

यो तपाईंले आफ्नो डिस्कमा कति ठाउँ छोड्नुभएको छ भन्ने भन्दा पूर्णतया फरक कथा हो।

कुरा टुङ्ग्याउन, अनुसन्धानका बुँदाहरू जोडौं।

सुरुमा मध्यरातमा सर्भर क्र्यास गर्ने साथीतिर फर्कौं।

उनले मैले वर्णन गरेका चार चरणहरू पालना गरे, `df -i` बाट सुरु गरेर इनोड साँच्चै भरिएको छ भनी पुष्टि गरे।

त्यसपछि, find प्रयोग गरेर, हामीले एउटा परित्यक्त पुरानो वेबसाइटको क्यास डाइरेक्टरी पत्ता लगायौं जसले पागल जस्तै साना फाइलहरू उत्पन्न गरिरहेको थियो।

अन्तमा, `repquota` जाँच गर्दा यो वास्तवमै कठिन सीमामा पुगेको पुष्टि भयो।

त्यो जंक क्यासको थुप्रो खाली गरेपछि, वेबसाइट तुरुन्तै फेरि जीवन्त भयो।

त्यसैले अर्को पटक तपाईंले यो अनौठो परिस्थितिको सामना गर्नुहुँदा "डिस्कमा स्पष्ट रूपमा ठाउँ छ तर तपाईं फाइलहरू लेख्न सक्नुहुन्न", हार्ड ड्राइभ थप्न हतार नगर्नुहोस्।

पहिले, इनोड हेर्न `df -i` प्रयोग गर्नुहोस्; सत्य त्यो इन्डेक्स कार्डमा लुकेको हुन सक्छ जुन तपाईंले पहिले कहिल्यै याद गर्नुभएको छैन।

मलाई साँच्चै विश्वास छ कि प्रणालीको मूल भागमा लुकेका यी सामान्य ज्ञानका साना टुक्राहरू सयौं अनुकूलन सूचीहरू सम्झनु भन्दा बढी उपयोगी छन्।