HestiaCP मध्ये आयनोडचा वापर कसा तपासायचा? डिस्कवर पुरेशी जागा असूनही फाईल्स लिहिता न येण्याचे कारण काय आहे?

दोन दिवसांपूर्वी, एका मित्राने मला रात्री उशिरा मेसेज करून सांगितले की त्याचा सर्वर क्रॅश झाला आहे.

विशिष्ट लक्षणे विशेषतः विचित्र होती: वेबसाइटवर अचानक त्रुटी येऊ लागल्या, लॉग्स लिहिता येत नव्हते आणि नवीन फाइल्स तयार केल्यावर डिस्क पूर्ण भरल्याचा संदेश लगेच येत होता.

पण जेव्हा त्याने `df -h` वापरून तपासले, तेव्हा त्याला हे पाहून धक्काच बसला की डिस्कवर स्पष्टपणे कित्येक गिगाबाईट्स मोकळी जागा होती. ती पूर्ण कशी भरली असेल?

मी त्याला त्याच क्षणी म्हणालो, "भाऊ, तुझ्याकडे फक्त स्टोरेज स्पेसच भरलेली नाही, तर तुझा आयनोड (Inode) ओव्हरलोड झाला आहे."

त्याने प्रश्नचिन्हासह उत्तर दिले: आयनोड म्हणजे नक्की काय?

खरं तर, जेव्हा अनेक लोक पहिल्यांदा या सापळ्यात अडकतात, तेव्हा ते अगदी त्याच्यासारखीच प्रतिक्रिया देतात, कारण शाळेत त्यांना कोणीही या गोष्टी शिकवलेल्या नसतात.

सर्वप्रथम आयनोड म्हणजे काय हे स्पष्ट करूया.

याची कल्पना ग्रंथालयातील सूचीपत्रिकेसारखी करा, म्हणजे ते समजायला सोपे जाईल.

डिस्क स्पेस ही पुस्तकांच्या कपाटासारखी असते; त्यावर तुम्ही किती पुस्तके ठेवू शकता हे त्याच्या क्षमतेवर अवलंबून असते, हे कोणालाही सहज समजू शकते.

आयनोड म्हणजे प्रत्येक पुस्तकासाठी असलेल्या एका इंडेक्स कार्डसारखे असते, ज्यावर त्याचे नाव, ठिकाण आणि ते कोणी हलवले याची नोंद असते.

लिनक्समध्ये , फाईल कितीही लहान असली तरी, प्रत्येक फाईल आणि प्रत्येक डिरेक्टरीला एक आयनोड (inode) व्यापणे बंधनकारक आहे.

फाईल रिकामी असली तरीही, सिस्टम त्यासाठी एक इंडेक्स कार्ड वापरेल.

सिस्टम तयार करू शकणाऱ्या एकूण फाईल्सच्या संख्येला एक मर्यादा आहे; ही मर्यादा म्हणजे एकूण इननोड्सची संख्या होय.

एकदा आयनोड (inode) संपला की, तुमच्या डिस्कवर शेकडो गिगाबाइट्स मोकळी जागा असली तरीही, ऑपरेटिंग सिस्टम नवीन फाईल्स तयार करण्यास नकार देईल.

लॉग्स लिहिले जाऊ शकत नाहीत, कॅशे तयार केला जाऊ शकत नाही आणि वेबसाइट पूर्णपणे क्रॅश होते—हेच ते विचित्र दृश्य आहे जे तुम्ही पाहत आहात.

खरं सांगायचं तर, ही एक खूप अवघड परिस्थिती आहे कारण त्रुटी संदेश अशा ठिकाणाहून पाठवला जातो जिथे तुम्ही पाहत नाही आहात.

पहिली युक्ती म्हणजे पटकन आढावा घेण्यासाठी `df -i` वापरणे.

HestiaCP वातावरणात , तुम्ही फक्त टर्मिनलमध्ये SSH करून ही ओळ टाईप करू शकता.

df -i

प्रत्येक माउंट केलेल्या पार्टिशनसाठी एकूण इननोड्सची संख्या, वापरलेल्यांची संख्या आणि शिल्लक राहिलेल्यांची संख्या सूचीबद्ध केली जाईल.

आउटपुटमध्ये IUse% नावाचा एक कॉलम आहे, जो एक महत्त्वाचा मेट्रिक आहे ज्यावर तुम्ही लक्ष ठेवले पाहिजे.

जर एखाद्या पार्टिशनचा IUse% 100% पर्यंत पोहोचला, तर त्या पार्टिशनमध्ये पुरेशी डिस्क जागा असली तरीही, ते नवीन फाईल्स किंवा लॉग्स तयार करू शकणार नाही.

मी माझ्या मित्राला सुचवले की त्याने हे आधी चालवावे, जेणेकरून समस्या आयनोडमध्ये आहे की नाही हे एका सेकंदात निश्चित करता येईल , जे अंदाज लावण्यापेक्षा खूपच वेगवान असेल.

दुसरी पद्धत म्हणजे विशिष्ट वापरकर्त्याची अचूक गणना करण्यासाठी `find` वापरणे.

समस्या इननोडमध्ये असल्याची खात्री झाल्यावर, इंडेक्स कार्डचा अतिरिक्त वापर कोण करत आहे हे शोधणे ही पुढची पायरी आहे.

HestiaCP मध्ये प्रत्येक वापरकर्त्यासाठी एक स्वतंत्र होम डिरेक्टरी असते. तुम्ही एका विशिष्ट वेबसाइट डिरेक्टरी अंतर्गत असलेल्या फाइल्स आणि डिरेक्टरींची एकूण संख्या सहजपणे मोजू शकता.

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

"वापरकर्त्याचे नाव" आणि "तुमच्या डोमेनचे नाव" यांच्या जागी तुमचा खरा पाथ टाका. टर्मिनलद्वारे मिळणारी निव्वळ संख्या ही त्या डिरेक्टरीमधील सर्व फाइल्स आणि फोल्डर्सची बेरीज असते.

प्रत्येक फाईल किंवा डिरेक्टरी एका आयनोडशी संबंधित असते, त्यामुळे ही संख्या आयनोडचा वापर दर्शवते.

जर तुम्हाला प्रत्येकाची वैयक्तिकरित्या तपासणी करण्याचा कंटाळा येत असेल आणि संपूर्ण साइटवरील सर्व वापरकर्त्यांच्या वापराचे वितरण एकाच वेळी पाहायचे असेल, तर त्यासाठी एकच लूप कमांड देखील आहे.

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

ही ओळ /home अंतर्गत प्रत्येक वापरकर्ता डिरेक्टरीमधील फाइल्सची एकूण संख्या प्रिंट करेल, ज्यामुळे कोणत्या वापरकर्ता डिरेक्टरीमध्ये फाइल्सची संख्या असामान्यपणे जास्त आहे हे ओळखणे सोपे होईल.

सर्वाधिक आयोडीन वापरणाऱ्या उपनिर्देशिका ओळखणे ही तिसरी रणनीती आहे.

कधीकधी आपल्याला माहित असते की एखाद्या वेबसाइटचे आयनोड व्हॅल्यूज (Inode values) अवास्तवपणे जास्त आहेत, पण तरीही फाईल्सने भरलेल्या स्क्रीनमध्ये नक्की काय चूक आहे हे आपल्याला कळत नाही.

अशा प्रकरणांमध्ये, तुम्हाला मोठ्या संख्येने लहान फाइल्स असलेले सबफोल्डर्स शोधण्यासाठी एक स्तर खाली जावे लागेल, जसे की कॅशे डिरेक्टरीज, सेशन डिरेक्टरीज आणि लॉग डिरेक्टरीज—हे सर्वात समस्याप्रधान भाग आहेत.

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 वापरून कोटा मर्यादा तपासणे.

जर तुमच्या सर्व्हरवर लिनक्स फाइल सिस्टम कोटा सक्षम केले असतील, तर तुम्ही समस्येकडे वेगळ्या दृष्टिकोनातून पाहू शकता.

repquota -a

ही कमांड सर्व वापरकर्त्यांसाठी फाईल मर्यादा आणि प्रत्यक्ष फाईल वापराची माहिती मिळवून देईल.

आउटपुटमधील 'फाईल लिमिट्स' विभागाकडे बारकाईने लक्ष द्या; 'यूज्ड' कॉलम किती फाईल्स वापरल्या गेल्या आहेत हे दर्शवतो.

'सॉफ्ट' आणि 'हार्ड' हे स्तंभ सॉफ्ट आणि हार्ड मर्यादा दर्शवतात. एकदा 'वापरलेले' (used) 'हार्ड' मर्यादेपर्यंत पोहोचले की, प्रणाली नवीन फाईल्स तयार करण्यास थेट नकार देईल.

तुमच्या डिस्कवर किती जागा शिल्लक आहे, ही एक पूर्णपणे वेगळी बाब आहे.

शेवटी, तपासातील सर्व दुवे जोडूया.

चला, सुरुवातीला मध्यरात्री सर्वर क्रॅश करणाऱ्या त्या मित्राकडे परत जाऊया.

आयनोड खरोखरच पूर्ण भरला आहे याची खात्री करण्यासाठी `df -i` ने सुरुवात करून, त्याने मी वर्णन केलेल्या चार पायऱ्यांचे पालन केले.

मग, ‘find’ वापरून, आम्ही एका जुन्या, बंद पडलेल्या वेबसाइटची कॅशे डिरेक्टरी शोधून काढली, जी प्रचंड प्रमाणात लहान फाइल्स तयार करत होती.

शेवटी, `repquota` तपासल्यावर याची खात्री झाली की ते खरोखरच हार्ड लिमिटपर्यंत पोहोचले होते.

तो निरुपयोगी कॅशेचा ढीग साफ केल्यावर, वेबसाइट लगेच पुन्हा सुरू झाली.

त्यामुळे पुढच्या वेळी जेव्हा तुम्हाला 'डिस्कवर जागा स्पष्टपणे असूनही तुम्ही फाईल्स लिहू शकत नाही' अशी विचित्र परिस्थिती जाणवेल, तेव्हा हार्ड ड्राइव्ह जोडण्याची घाई करू नका.

सर्वप्रथम, आयनोड पाहण्यासाठी `df -i` वापरा; सत्य कदाचित त्या इंडेक्स कार्डवर दडलेले असू शकते जे तुम्ही यापूर्वी कधीही पाहिले नसेल.

माझा प्रामाणिक विश्वास आहे की शंभर ऑप्टिमायझेशनच्या याद्या पाठ करण्यापेक्षा, सिस्टीमच्या गाभ्यामध्ये दडलेल्या सामान्य ज्ञानाच्या या छोट्या गोष्टी अधिक उपयुक्त आहेत.