Kā pārbaudīt inode izmantošanu HestiaCP? Kas izraisa nespēju rakstīt failus pat tad, ja diskā ir daudz vietas?

Pirms pāris dienām vēlu vakarā draugs man uzrakstīja, ka viņa serveris ir avarējis.

Konkrētie simptomi bija īpaši dīvaini: vietne pēkšņi sāka mest kļūdas, žurnālus nevarēja ierakstīt, un, veidojot jaunus failus, nekavējoties tika parādīts ziņojums, ka disks ir pilns.

Bet, kad viņš pārbaudīja ar `df -h`, viņš bija šokēts, atklājot, ka diskā nepārprotami ir desmitiem gigabaitu brīvas vietas. Kā tas var būt pilns?

Es viņam tūlīt un tur pateicu: "Brāli, tev ne tikai ir daudz vietas krātuvē, tavs Inode ir pārslogots."

Viņš atbildēja ar jautājuma zīmi: Kas īsti ir inode?

Patiesībā daudzi cilvēki reaģē tieši tāpat kā viņš, kad pirmo reizi iekrita šajā slazdā, jo skolā neviens viņiem to nekad nav mācījis.

Vispirms noskaidrosim, kas ir Inode.

Domājiet par to kā par bibliotēkas indekskarti, un to būs viegli saprast.

Diska vieta ir kā grāmatu plaukts; cik grāmatu tajā var ievietot, ir atkarīgs no tā ietilpības, kas ir viegli saprotams ikvienam.

Inode ir kā katras grāmatas indekskarte, kurā ierakstīts tās nosaukums, atrašanās vieta un tas, kas to pārvietoja.

Linux sistēmā katram failam un katrai direktorijai ir jāaizņem inode neatkarīgi no faila lieluma.

Pat ja tas ir tukšs fails, sistēma joprojām izmantos indekskarti.

Sistēmai ir ierobežojums kopējam izveidojamo failu skaitam; šis ierobežojums ir kopējais innodu skaits.

Kad inode ir izmantota, pat ja diskā joprojām ir simtiem gigabaitu brīvas vietas, operētājsistēma atteiksies izveidot jaunus failus.

Žurnālus nevar ierakstīt, kešatmiņu nevar izveidot, un vietne pilnībā avarē — lūk, šī dīvainā aina, kurai jūs šobrīd pievēršaties.

Godīgi sakot, šī ir patiešām sarežģīta situācija, jo kļūdas ziņojums tiek nosūtīts no vietas, uz kuru jūs neskatāties.

Pirmais triks ir izmantot `df -i`, lai iegūtu ātru pārskatu.

HestiaCP vidē varat vienkārši SSH ievadīt terminālī un ierakstīt šo rindiņu.

df -i

Tajā tiks uzskaitīts kopējais iekšējo mezglu skaits, izmantotais skaits un atlikušais skaits katram uzstādītajam nodalījumam.

Izvadē ir kolonna ar nosaukumu IUse%, kas ir galvenais rādītājs, kam jāpievērš uzmanība.

Ja nodalījuma IUse% sasniedz 100%, pat ja šajā nodalījumā joprojām ir daudz vietas diskā, tas vairs nevarēs izveidot jaunus failus vai žurnālus.

Es ieteicu savam draugam vispirms palaist šo, lai tas sekundē varētu noteikt, vai problēma ir Inode , kas būtu daudz ātrāk nekā minēt.

Otra metode ir izmantot funkciju `find`, lai precīzi saskaitītu konkrētu lietotāju.

Pēc tam, kad ir apstiprināts, ka problēma ir ar innodu, nākamais solis ir noskaidrot, kurš pārmērīgi patērē indekskarti.

HestiaCP katram lietotājam ir atsevišķa mājas direktorijs. Jūs varat vienkārši saskaitīt kopējo failu un direktoriju skaitu noteiktā vietnes direktorijā.

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

Aizvietojiet "lietotājvārds" un "jūsu domēna vārds" ar savu faktisko ceļu. Termināļa atgrieztais tīrais skaitlis ir visu failu un mapju summa šajā direktorijā.

Katrs fails vai direktorijs atbilst vienam inodei, tāpēc šis skaitlis apzīmē inode izmantošanu.

Ja esat pārāk slinks, lai pārbaudītu katru atsevišķi, un vēlaties redzēt visu lietotāju lietojuma sadalījumu visā vietnē vienlaikus, ir arī viena cikla komanda.

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

Šajā rindā tiks parādīts kopējais failu skaits katrā lietotāja direktorijā sadaļā /home, tādējādi atvieglojot neparasti liela failu skaita noteikšanu.

Trešā stratēģija ir identificēt apakšdirektorijus, kas patērē visvairāk joda.

Dažreiz jūs zināt, ka vietnei ir smieklīgi augstas Inode vērtības, bet jūs joprojām nevarat saprast, kas par vainu ir ekrānā, kas ir pilns ar failiem.

Šādos gadījumos ir jāiedziļinās vienā līmenī, lai atrastu apakšmapes, kurās ir liels skaits mazu failu, piemēram, kešatmiņas direktoriji, sesiju direktoriji un žurnālu direktoriji — tās ir visproblemātiskākās zonas.

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

Šī komanda uzskaitīs 10 apakšmapes, kas patērē visvairāk failu.

Ceļš saraksta pašā augšdaļā ir vieta, kur kopā ir sagrupēti daudzi mazi faili.

Es teicu savam draugam, ka tas droši vien ir kāds kešatmiņas spraudnis, kas slepeni ģenerē mazus failus, un šīs rindas palaišana to būtībā apstiprinātu.

Ceturtais padoms ir pārbaudīt kvotas ierobežojumu, izmantojot repquota.

Ja jūsu serverī ir iespējotas Linux failu sistēmas kvotas, problēmu var aplūkot no cita skatupunkta.

repquota -a

Šī komanda parādīs failu skaita ierobežojumu un faktisko failu izmantošanu visiem lietotājiem.

Pievērsiet īpašu uzmanību sadaļai Failu ierobežojumi izvadē; izmantotā kolonna norāda, cik failu ir izmantoti.

Kolonnas “vieglā” un “stingrā” attēlo mīkstā un stingrā ierobežojuma sliekšņus. Kad “lietots” sasniedz “stingrā” vērtību, sistēma nekavējoties atteiksies veidot jaunus failus.

Tas ir pavisam cits stāsts nekā tas, cik daudz vietas jums ir atlicis diskā.

Noslēgumā savienosim izmeklēšanas punktus.

Atgriezīsimies pie drauga, kurš sākumā nakts vidū avarēja serverī.

Viņš izpildīja četrus aprakstītos soļus, sākot ar `df -i`, lai apstiprinātu, ka inode patiešām ir pilna.

Pēc tam, izmantojot find, mēs atradām pamestas vecas vietnes kešatmiņas direktoriju, kas neprātīgi ģenerēja mazus failus.

Visbeidzot, pārbaudot `repquota`, tika apstiprināts, ka tas patiešām ir sasniedzis stingro ierobežojumu.

Pēc šīs nevēlamās kešatmiņas kaudzes iztīrīšanas vietne nekavējoties atdzīvojās.

Tāpēc nākamreiz, kad saskarsieties ar šo dīvaino situāciju, kad "diskā acīmredzami ir vieta, bet failus nevar ierakstīt", nesteidzieties pievienot cieto disku.

Vispirms izmantojiet `df -i`, lai aplūkotu inodu; patiesība, iespējams, ir paslēpta uz tās indekskartes, kuru nekad iepriekš neesat pamanījis.

Es patiesi ticu, ka šie mazie veselā saprāta gabaliņi, kas paslēpti sistēmas kodolā, ir noderīgāki nekā simts optimizācijas sarakstu iegaumēšana.