Як перевірити використання 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

Замініть «ім’я користувача» та «ім’я вашого домену» на фактичний шлях. Чисте число, яке повертає термінал, – це сума всіх файлів і папок у цьому каталозі.

Кожен файл або каталог відповідає одному inode, тому це число відображає використання inode.

Якщо вам ліньки перевіряти кожного окремо та ви хочете побачити розподіл використання всіх користувачів по всьому сайту одночасно, є також команда з одним циклом.

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; правда цілком може бути прихована на тій картці індексу, яку ви ніколи раніше не помічали.

Я щиро вірю, що ці маленькі шматочки здорового глузду, приховані в ядрі системи, корисніші, ніж запам'ятовування сотні списків оптимізації.