Ինչպե՞ս ստուգել inode-ի օգտագործումը HestiaCP-ում: Ի՞նչն է առաջացնում ֆայլեր գրելու անկարողությունը նույնիսկ այն դեպքում, երբ սկավառակի վրա բավականաչափ տարածք կա:

Մի քանի օր առաջ ուշ գիշերին ընկերներիցս մեկը հաղորդագրություն ուղարկեց ինձ՝ ասելով, որ իր սերվերը խափանվել է։

Հատուկ ախտանիշները հատկապես տարօրինակ էին. կայքը հանկարծ սկսեց սխալներ ցուցադրել, գրանցամատյաններում գրառումներ անել հնարավոր չէր, իսկ նոր ֆայլեր ստեղծելը անմիջապես հուշում էր, որ սկավառակը լիքն է։

Բայց երբ նա ստուգեց `df -h`-ով, ապշեց, երբ հայտնաբերեց, որ սկավառակի վրա հստակորեն տասնյակ գիգաբայթ ազատ տարածք կար։ Ինչպե՞ս կարող էր այն լիքը լինել։

Ես նրան հենց այդ պահին ասացի. «Եղբայր, դու ոչ միայն լի ես պահեստային տարածքով, այլև քո Inode-ը գերծանրաբեռնված է»։

Նա հարցական նշանով պատասխանեց. Ի՞նչ է իրականում Inode-ը։

Իրականում, շատ մարդիկ արձագանքում են ճիշտ այնպես, ինչպես նա, երբ առաջին անգամ ընկան այս թակարդը, քանի որ դպրոցում ոչ ոք նրանց երբեք այս բաները չի սովորեցրել։

Նախ պարզաբանենք, թե ինչ է Inode-ը։

Պատկերացրեք այն որպես գրադարանի ցուցանակ, և այն հեշտ կլինի հասկանալ։

Սկավառակի տարածքը նման է գրապահարանի. քանի գիրք կարող եք տեղադրել դրա վրա, կախված է դրա տարողությունից, ինչը բոլորի համար հեշտ է հասկանալ։

Ինոդը յուրաքանչյուր գրքի համար նախատեսված ինդեքսային քարտի նման է, որը գրանցում է դրա անվանումը, գտնվելու վայրը և թե ով է այն տեղափոխել։

Linux- ում յուրաքանչյուր ֆայլ և յուրաքանչյուր պանակ պետք է զբաղեցնի ինոդ, անկախ ֆայլի փոքրությունից։

Նույնիսկ եթե դա դատարկ ֆայլ է, համակարգը դեռ կօգտագործի դրա ինդեքսային քարտը։

Համակարգն ունի ստեղծման ենթակա ֆայլերի ընդհանուր թվի սահմանափակում։ Այս սահմանափակումը հանգույցների ընդհանուր թիվն է։

Երբ ինոդը սպառվի, նույնիսկ եթե ձեր սկավառակի վրա դեռ հարյուրավոր գիգաբայթ ազատ տարածք կա, օպերացիոն համակարգը կհրաժարվի նոր ֆայլեր ստեղծելուց։

Հնարավոր չէ գրանցել գրանցամատյաններ, հնարավոր չէ ստեղծել քեշ, և կայքը լիովին խափանվում է. ահա թե ինչ տարօրինակ տեսարանի եք ականատես լինում։

Անկեղծ ասած, սա իսկապես բարդ իրավիճակ է, քանի որ սխալի հաղորդագրությունը ուղարկվում է այնպիսի վայրից, որը դուք չեք նայում։

Առաջին հնարքը `df -i`-ի օգտագործումն է՝ ամբողջական պատկերացում ստանալու համար։

HestiaCP միջավայրում դուք կարող եք պարզապես SSH մուտք գործել տերմինալ և մուտքագրել այս տողը։

df -i

Այն կցուցադրի հանգույցների ընդհանուր քանակը, օգտագործված քանակը և յուրաքանչյուր տեղադրված բաժնի մնացած քանակը։

Արդյունքում կա IUse% անունով սյունակ, որը հիմնական չափանիշն է, որին պետք է ուշադրություն դարձնեք։

Եթե ​​բաժանման IUse% -ը հասնի 100%-ի, նույնիսկ եթե այդ բաժանումը դեռ բավականաչափ սկավառակի տարածք ունի, այն այլևս չի կարողանա ստեղծել որևէ նոր ֆայլ կամ գրանցամատյան։

Ես առաջարկեցի ընկերոջս, որ նա նախ սա աշխատեցնի, որպեսզի այն կարողանա վայրկյանում պարզել, թե արդյոք խնդիրը Inode-ի մեջ է , թե ոչ , ինչը շատ ավելի արագ կլինի, քան կռահելը։

Երկրորդ մեթոդը `find` ֆունկցիայի օգտագործումն է՝ որոշակի օգտատիրոջ ճշգրիտ հաշվելու համար։

Հաստատելուց հետո, որ խնդիրը հանգույցի մեջ է, հաջորդ քայլը պարզելն է, թե ով է չափից շատ օգտագործում ինդեքսային քարտը։

HestiaCP-ն ունի առանձին տնային տեղեկատու յուրաքանչյուր օգտատիրոջ համար։ Դուք կարող եք պարզապես հաշվել որոշակի կայքի տեղեկատուի տակ գտնվող ֆայլերի և տեղեկատուների ընդհանուր քանակը։

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

Փոխարինեք «օգտատիրոջ անունը» և «ձեր տիրույթի անունը» ձեր իրական ուղով։ Տերմինալի կողմից վերադարձվող մաքուր թիվը այդ գրացուցակում գտնվող բոլոր ֆայլերի և թղթապանակների գումարն է։

Յուրաքանչյուր ֆայլ կամ գրացուցակ համապատասխանում է մեկ ինոդի, ուստի այս թիվը ներկայացնում է ինոդի օգտագործումը։

Ինչպե՞ս ստուգել inode-ի օգտագործումը HestiaCP-ում: Ի՞նչն է առաջացնում ֆայլեր գրելու անկարողությունը նույնիսկ այն դեպքում, երբ սկավառակի վրա բավականաչափ տարածք կա:

Եթե ​​չափազանց ծույլ եք յուրաքանչյուրը առանձին ստուգելու համար և ցանկանում եք տեսնել բոլոր օգտատերերի օգտագործման բաշխումը ամբողջ կայքում միաժամանակ, կա նաև ցիկլի հրաման։

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`՝ ինոդը տեսնելու համար. ճշմարտությունը կարող է թաքնված լինել այն ինդեքսային քարտի վրա, որը դուք երբեք չեք նկատել։

Ես անկեղծորեն հավատում եմ, որ համակարգի միջուկում թաքնված առողջ բանականության այս փոքրիկ կտորները ավելի օգտակար են, քան հարյուր օպտիմալացման ցուցակ անգիր սովորելը։

Հուսով եմ, որ Չեն Վեյլիանգի բլոգում ( https://www.chenweiliang.com/ ) տեղադրված «Ինչպե՞ս ստուգել Inode-ի օգտագործումը HestiaCP-ում։ Սկավառակի տարածքի ազատության պատճառը ֆայլեր գրելու անկարողությունն է» հոդվածը օգտակար կլինի ձեզ համար։

Ազատորեն կիսվեք այս հոդվածի հղումով՝ https://www.chenweiliang.com/cwl-34619.html

Ավելի շատ թաքնված հնարքներ բացահայտելու համար🔑, միացեք մեր Telegram ալիքին։

Տարածեք և հավանեք, եթե ձեզ դուր եկավ: Ձեր կիսումներն ու հավանումները մեր շարունակական շարժառիթն են:

 

发表 评论

您的邮箱地址不会被公开。必填项已用*标注

Ոլորել դեպի սկիզբ