Како да проверим коришћење индексних лозова у HestiaCP-у? Шта узрокује немогућност писања датотека чак и када има довољно простора на диску?

Пре пар дана, пријатељ ми је касно увече послао поруку рекавши да му се сервер срушио.

Конкретни симптоми су били посебно бизарни: веб локација је изненада почела да избацује грешке, записи се нису могли писати, а креирање нових датотека би одмах указивало да је диск пун.

Али када је проверио са `df -h`, био је шокиран када је открио да диск очигледно има десетине гигабајта слободног простора. Како је могуће да је пун?

Рекао сам му одмах тада и тамо: „Брате, ниси само пун простора за складиштење, твој иноде је преоптерећен.“

Одговорио је упитником: Шта је тачно иноде?

У ствари, многи људи реагују потпуно исто као и он када су први пут упали у ову замку, јер их нико у школи никада није научио овим стварима.

Хајде прво да разјаснимо шта је 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-а, али и даље не можете да схватите шта није у реду са екраном пуним датотека.

У таквим случајевима, потребно је да се померите један ниво надоле да бисте пронашли подфасцикле које садрже велики број малих датотека, као што су директоријуми кеша, директоријуми сесија и директоријуми дневника – то су најпроблематичнија подручја.

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` да погледате индексни код; истина је вероватно сакривена на тој индексној картици коју никада раније нисте приметили.

Искрено верујем да су ови мали делови здравог разума скривени у сржи система кориснији од памћења стотину листа оптимизације.