Прочитайте попередження про пам’ять і диск перед оновленням.

Зніміть невеликий базовий рівень з контекстом

Використовуйте обліковий запис Linux, дозволений для огляду застосунку, яким ви керуєте. Команди тут оглядають стан; вони не видаляють файли і не змінюють розмір сховища. Деякі каталоги та журнали потребують підвищеного доступу. Замініть /var/lib/field-api, /opt/field-api та /opt/first-api на реальні шляхи застосунку та підтвердьте, що ці шляхи існують, перш ніж тлумачити результати.

Запишіть час, поточний реліз і активність: звичайний трафік, завантаження, завдання звіту або збірку розгортання. Зробіть ще одне вимірювання під час порівнянної активності. Два не пов'язані знімки екрана можуть змусити здорову машину виглядати невідповідно. Якщо користувачі вже постраждали, зафіксуйте першу корисну підказку з посібника зі збоїв застосунку перш ніж робити кілька змін одночасно.

Прочитайте доступну пам'ять, потім огляньте навантаження

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

У free, доступна пам'ять оцінює, що можна використати для нових застосунків без свопу. Вона враховує кеш, який можна звільнити, тому відповідає на інше питання, ніж повністю невикористана «вільна» пам'ять. Дивіться посібник upstream free. Linux використовує пам'ять для кешування файлів; великий кеш сам по собі не є доказом витоку. огляд пам'яті ядра пояснює, чому кеш і пам'ять застосунку співіснують.

Ілюстративне показання, а не вимірювання сервера: малий хост має близько 1.9 GiB доступної пам'яті, 80 MiB вільної та 850 MiB доступної. Низький показник вільної пам'яті сам по собі не виправдовує оновлення. Якщо доступна пам'ять неодноразово падає майже до нуля під час звіту, запити сповільнюються і з'являються відповідні повідомлення про виділення пам'яті або вичерпання пам'яті, ці сукупні докази заслуговують на дослідження.

The ps команда виводить RSS процесів у KiB, найбільші спочатку. RSS описує резидентну пам'ять, а не повний облік виключного володіння; спільні сторінки можуть з'являтися в кількох процесах. Не додавайте кожен показник RSS і не вважайте результат точним використанням хоста. довідник upstream ps визначає RSS і сортування. Запишіть назву процесу та чи повертається його обсяг до попереднього рівня після завершення навантаження.

Використаний своп може відображати попередню активність; він сам по собі не доводить поточний тиск. Також розрізняйте ємність хоста від лімітів сервісу або контейнера. Обмежений процес може зазнати збою, поки хост ще має доступну пам'ять. Огляньте налаштований ліміт і час збою, перш ніж збільшувати розмір VPS. Довідник ядра proc filesystem документує поля пам'яті, що стоять за цими спостереженнями.

Знайдіть файлову систему, яка насправді заповнюється

df -h / /opt/first-api
df -i / /opt/first-api

Перша команда повідомляє про простір у файлових системах, що містять ці шляхи. Друга повідомляє про іноди — записи файлової системи, потрібні для файлів і каталогів. Навантаження з багатьма крихітними файлами може вичерпати іноди, поки ємність у байтах залишається. Перевірте точку монтування та обидва види ємності, а не використовуйте розмір усього VPS як єдине число. Дивіться посібник GNU df.

Шлях на окремому змонтованому томі може заповнюватися незалежно від кореневої файлової системи. І навпаки, два перелічені шляхи можуть належати одній файловій системі, тому їхній доступний простір не додається. Резервування файлової системи, квоти та шари сховища також можуть впливати на те, що застосунок може записати. Один відображений відсоток не визначає власника зростання.

Віднесіть зростання до логів, завантажень або артефактів

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du оцінює виділений простір у кожному каталозі. Тут -x уникає переходу в іншу файлову систему, -h використовує читабельні одиниці та -d1 обмежує відображувану глибину. Великі дерева все одно можуть вимагати часу та активності диска для сканування. Помилки дозволу означають, що перегляд неповний. Дивіться посібник GNU du. Команда journal повідомляє про сховище журналу, включно з активними та архівованими файлами, як задокументовано в journalctl.

Порівняйте найбільші каталоги з їхнім призначенням:

• Логи: чи повторювана помилка збільшила обсяг, і чи налаштовано ротацію?
• Завантаження: чи зберігаються файли користувачів зростають, як очікувалося, і чи враховано покинуті часткові завантаження?
• Артефакти релізу: чи накопичуються старі збірки понад політику відкату?
• Файли бази даних: чи власні інструменти бази даних пояснюють зростання та потреби в обслуговуванні?

Не видаляйте незнайомий каталог бази даних і не використовуйте широке очищення тому контейнера як крок дослідження. Спочатку визначте власника, вимоги до збереження та відновлювану копію. Якщо df та підсумки каталогів суттєво розходяться, огляньте межі монтування, помилки доступу та файли, які все ще утримуються відкритими після видалення, разом з досвідченим оператором; повторне видалення видимих файлів може не врахувати зайнятий простір.

Перетворіть показання на конкретну наступну дію

Ілюстративний випадок: доступна пам'ять залишається достатньою, але каталог завантажень зростає приблизно на 400 MiB кожного з двох спостережуваних днів. Файлова система має близько 2 GiB доступного простору. Поділ залишкового простору на це короткострокове зростання вказує лише на близько п'яти днів за тієї самої швидкості, перш ніж враховувати робочий запас. Це оцінка для планування, а не прогноз і не безпечний термін очікування; завантаження та тимчасова робота можуть надходити нерівномірно.

Наступна дія — перевірити збереження завантажень і очікуваний попит, запланувати додаткове сховище, якщо це виправдано, і налаштувати сповіщення достатньо рано, щоб діяти. Більше RAM не вирішило б цю знахідку. В іншому випадку збірка розгортання може створити короткочасний пік пам'яті, поки обслуговування залишається невеликим; перенесення збірки з VPS могло б бути кориснішим, ніж постійне збільшення середовища виконання.

Після виправданої зміни повторіть ті самі показання та одну дію застосунку. Підтвердьте, що простір справді доступний і потрібні дані все ще працюють. Тримайте видалення та зміну розміру як заплановані операції з кроками відновлення, а не як автоматичні реакції на червоне число. Використовуйте посібник з бюджету ресурсів щоб перетворити продемонстровану потребу на вибір конфігурації, і практикуйте відновлення перш ніж покладатися на очищення або міграцію.