როგორ შევამოწმო ინოდის გამოყენება HestiaCP-ში? რა იწვევს ფაილების ჩაწერის შეუძლებლობას მაშინაც კი, როცა დისკზე საკმარისი ადგილია?

რამდენიმე დღის წინ, გვიან ღამით, მეგობარმა მომწერა, რომ მისი სერვერი გაითიშა.

კონკრეტული სიმპტომები განსაკუთრებით უცნაური იყო: ვებსაიტმა მოულოდნელად დაიწყო შეცდომების გაგზავნა, ჟურნალების ჩაწერა შეუძლებელი იყო და ახალი ფაილების შექმნა მაშინვე მიუთითებდა, რომ დისკი სავსე იყო.

მაგრამ როდესაც მან `df -h`-ით შეამოწმა, გაოგნებული დარჩა, როდესაც აღმოაჩინა, რომ დისკზე აშკარად ათობით გიგაბაიტი თავისუფალი ადგილი იყო. როგორ შეიძლებოდა ის სავსე ყოფილიყო?

მე მაშინვე ვუთხარი: „ძმაო, შენ არა მხოლოდ სავსე ხარ საცავის სივრცით, შენი Inode გადატვირთულია“.

მან კითხვის ნიშნით უპასუხა: რა არის ზუსტად Inode?

სინამდვილეში, ბევრი ადამიანი ზუსტად ისევე რეაგირებს, როგორც ის, როდესაც პირველად გაება ამ ხაფანგში, რადგან სკოლაში არავის არასდროს უსწავლებია მათთვის ეს ყველაფერი.

ჯერ განვმარტოთ, რა არის ინოდი.

წარმოიდგინეთ ეს, როგორც ბიბლიოთეკის საინდექსო ბარათი და მისი გაგება ადვილი იქნება.

დისკის სივრცე წიგნების თაროს ჰგავს; მასზე წიგნების რაოდენობის განთავსება მის ტევადობაზეა დამოკიდებული, რაც ყველასთვის ადვილად გასაგებია.

ინოდი თითოეული წიგნის საინდექსო ბარათის მსგავსია, რომელზეც ჩაწერილია მისი სახელი, ადგილმდებარეობა და ვინ გადაიტანა იგი.

Linux- ში , ყველა ფაილს და ყველა დირექტორიას უნდა ჰქონდეს ინოდის პოზიცია, ფაილის ზომის მიუხედავად.

მაშინაც კი, თუ ეს ცარიელი ფაილია, სისტემა მაინც მოიხმარს მისთვის განკუთვნილ ინდექსის ბარათს.

სისტემას აქვს შეზღუდვა ფაილების საერთო რაოდენობაზე, რომელთა შექმნაც მას შეუძლია; ეს ლიმიტი არის კვანძების საერთო რაოდენობა.

როგორც კი ინოდი ამოიწურება, მაშინაც კი, თუ თქვენს დისკზე ასობით გიგაბაიტი თავისუფალი ადგილია, ოპერაციული სისტემა უარს იტყვის ახალი ფაილების შექმნაზე.

ლოგების ჩაწერა შეუძლებელია, ქეშის შექმნა შეუძლებელია და ვებსაიტი მთლიანად ითიშება — აი, რა უცნაური სცენის მოწმენი ხართ.

გულწრფელად რომ ვთქვათ, ეს ნამდვილად რთული სიტუაციაა, რადგან შეცდომის შეტყობინება იგზავნება იმ ადგილიდან, რომელსაც თქვენ არ უყურებთ.

პირველი ხრიკი არის `df -i`-ს გამოყენება სწრაფი მიმოხილვის მისაღებად.

HestiaCP გარემოში , შეგიძლიათ უბრალოდ SSH შეხვიდეთ ტერმინალში და აკრიფოთ ეს ხაზი.

df -i

ის ჩამოთვლის კვანძების საერთო რაოდენობას, გამოყენებულ რაოდენობას და თითოეული დამონტაჟებული დანაყოფისთვის დარჩენილ რაოდენობას.

გამომავალში არის სვეტი სახელწოდებით IUse%, რომელიც წარმოადგენს ძირითად მეტრიკას, რომელსაც ყურადღება უნდა მიაქციოთ.

თუ დანაყოფის IUse% 100%-ს მიაღწევს, მაშინაც კი, თუ ამ დანაყოფს დისკზე საკმარისი ადგილი აქვს, ის ვეღარ შეძლებს ახალი ფაილების ან ჟურნალების შექმნას.

ჩემს მეგობარს შევთავაზე, რომ ჯერ ეს გაეშვა, რათა წამში დაედგინა, პრობლემა Inode-ში იყო თუ არა , რაც გაცილებით სწრაფი იქნებოდა, ვიდრე გამოცნობა.

მეორე მეთოდია `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 მნიშვნელობები აქვს, მაგრამ მაინც ვერ ხვდებით, რა სჭირს ფაილებით სავსე ეკრანს.

ასეთ შემთხვევებში, თქვენ უნდა ჩაუღრმავდეთ ერთი დონით ქვემოთ იმ ქვესაქაღალდეების მოსაძებნად, რომლებიც შეიცავს დიდი რაოდენობით მცირე ფაილებს, როგორიცაა ქეშის დირექტორიები, სესიის დირექტორიები და ჟურნალის დირექტორიები - ეს არის ყველაზე პრობლემური ადგილები.

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

ეს ბრძანება აჩვენებს 10 ქვესაქაღალდეს, რომლებიც ყველაზე მეტ ფაილს მოიხმარენ.

სიის ზედა ნაწილში მდებარე გზა არის ის ადგილი, სადაც დიდი რაოდენობით მცირე ფაილებია დაჯგუფებული.

მეგობარს ვუთხარი, რომ ეს ალბათ რაღაც ქეშირების დანამატი იყო, რომელიც ფარულად პატარა ფაილებს გენერირებდა და ამ ხაზის გაშვება, ფაქტობრივად, ამას დაადასტურებდა.

მეოთხე რჩევაა კვოტის ლიმიტის შემოწმება repquota-ს გამოყენებით.

თუ თქვენს სერვერს ჩართული აქვს Linux ფაილური სისტემის კვოტები, შეგიძლიათ პრობლემას სხვა პერსპექტივიდან შეხედოთ.

repquota -a

ეს ბრძანება აჩვენებს ფაილის ლიმიტს და ფაილის ფაქტობრივ გამოყენებას ყველა მომხმარებლისთვის.

დიდი ყურადღება მიაქციეთ გამომავალში ფაილების ლიმიტების განყოფილებას; გამოყენებული სვეტი მიუთითებს გამოყენებული ფაილების რაოდენობაზე.

„რბილი“ და „მკაცრი“ სვეტები წარმოადგენს რბილი და მკაცრი ლიმიტების ზღურბლებს. როგორც კი „გამოყენებული“ მიაღწევს „მკაცრ“ მნიშვნელობას, სისტემა პირდაპირ უარს იტყვის ახალი ფაილების შექმნაზე.

ეს სრულიად განსხვავებული ამბავია იმისგან, თუ რამდენი ადგილი დაგრჩათ დისკზე.

დასასრულებლად, მოდით, გამოძიების წერტილები ერთმანეთთან დავაკავშიროთ.

დავუბრუნდეთ მეგობარს, რომელმაც დასაწყისში შუაღამისას სერვერი გათიშა.

მან ჩემს მიერ აღწერილი ოთხი ნაბიჯი გადადგა, დაწყებული `df -i`-ით, რათა დაედასტურებინა, რომ ინოდი ნამდვილად სავსე იყო.

შემდეგ, find-ის გამოყენებით, ჩვენ ვიპოვეთ მიტოვებული ძველი ვებსაიტის ქეშის დირექტორია, რომელიც საოცრად პატარა ფაილებს გენერირებდა.

საბოლოოდ, `repquota`-ს შემოწმებით დადასტურდა, რომ მან მართლაც მიაღწია მკაცრ ზღვარს.

არასაჭირო ფაილების გროვის გასუფთავების შემდეგ, ვებსაიტი მაშინვე გაცოცხლდა.

ასე რომ, შემდეგ ჯერზე, როდესაც ამ უცნაურ სიტუაციას წააწყდებით, სადაც „დისკზე აშკარად არის ადგილი, მაგრამ ფაილების ჩაწერა არ შეგიძლიათ“, ნუ იჩქარებთ მყარი დისკის დამატებას.

პირველ რიგში, ინოდის სანახავად გამოიყენეთ `df -i`; შესაძლოა, სიმართლე იმ ინდექსის ბარათზე იყოს დამალული, რომელიც აქამდე არასდროს შეგინიშნავთ.

მე გულწრფელად მჯერა, რომ სისტემის ბირთვში დამალული საღი აზრის ეს პატარა მინუსები უფრო სასარგებლოა, ვიდრე ასი ოპტიმიზაციის სიის დამახსოვრება.