Як праверыць выкарыстанне inode ў HestiaCP? Што з'яўляецца прычынай немагчымасці запісу файлаў, нават калі на дыску шмат месца?

Пару дзён таму позна ўвечары сябар напісаў мне, што ў яго зламаўся сервер.

Канкрэтныя сімптомы былі асабліва дзіўнымі: вэб-сайт раптам пачаў выдаваць памылкі, журналы не маглі быць запісаны, а стварэнне новых файлаў адразу ж паведамляла, што дыск поўны.

Але калі ён праверыў з дапамогай `df -h`, то быў шакаваны, выявіўшы, што на дыску відавочна былі дзясяткі гігабайтаў вольнага месца. Як ён мог быць поўным?

Я адразу сказаў яму: «Брат, у цябе не проста поўна месца для захоўвання, твой індэкс перагружаны».

Ён адказаў пытальнікам: што такое індэкс?

Насамрэч, многія людзі рэагуюць гэтак жа, як і ён, калі ўпершыню трапілі ў гэтую пастку, бо ніхто ў школе ніколі іх гэтаму не вучыў.

Давайце спачатку высветлім, што такое Inode.

Уявіце сабе гэта як бібліятэчную картку, і гэта будзе лёгка зразумець.

Дыскавая прастора падобная да кніжнай паліцы: колькасць кніг, якія можна на яе пакласці, залежыць ад яе ёмістасці, што лёгка зразумець кожнаму.

Індэксны дескриптор падобны на індэксную картку для кожнай кнігі, у якой запісана яе назва, месцазнаходжанне і хто яе перамясціў.

У Linux кожны файл і кожны каталог павінны займаць 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, але ўсё роўна не можаце зразумець, што не так з экранам, поўным файлаў.

У такіх выпадках вам трэба перайсці на адзін узровень ніжэй, каб знайсці падпапкі, якія ўтрымліваюць вялікую колькасць невялікіх файлаў, такіх як каталогі кэша, каталогі сесій і каталогі журналаў — гэта найбольш праблемныя вобласці.

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`, каб пераканацца, што inode сапраўды запоўнены.

Затым, выкарыстоўваючы find, мы знайшлі каталог кэша закінутага старога вэб-сайта, які генераваў неверагодна маленькія файлы.

Нарэшце, праверка `repquota` пацвердзіла, што сапраўды дасягнута жорсткая мяжа.

Пасля ачысткі гэтай кучы смецця з кэша сайт адразу ж ажыў.

Таму, калі наступным разам вы сутыкнецеся з гэтай дзіўнай сітуацыяй, калі «на дыску відавочна ёсць месца, але вы не можаце запісаць файлы», не спяшайцеся дадаваць жорсткі дыск.

Спачатку выкарыстайце `df -i`, каб зірнуць на inode; праўда можа быць схавана на той індэкснай картцы, якую вы ніколі раней не заўважалі.

Я шчыра веру, што гэтыя маленькія кавалачкі здаровага сэнсу, схаваныя ў аснове сістэмы, больш карысныя, чым запамінанне сотні спісаў аптымізацыі.