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

Снимите небольшой базовый уровень с контекстом

Используйте учётную запись 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 ГиБ доступной памяти, 80 МиБ свободной и 850 МиБ доступной. Низкое значение свободной памяти само по себе не оправдывает обновление. Если доступная память неоднократно падает почти до нуля во время отчёта, запросы замедляются и появляются соответствующие сообщения о выделении памяти или о нехватке памяти, эти совокупные свидетельства заслуживают изучения.

The ps Команда выводит список RSS процессов в КиБ, начиная с самого большого. RSS описывает резидентную память, а не полный учёт исключительного владения; общие страницы могут появляться в нескольких процессах. Не складывайте все значения RSS и не считайте результат точным использованием хоста. справочник upstream ps определяет RSS и сортировку. Запишите имя процесса и возвращается ли его объём к прежнему уровню после завершения нагрузки.

Используемый своп может отражать более раннюю активность; сам по себе он не доказывает текущее давление. Также отличайте ёмкость хоста от лимитов службы или контейнера. Ограниченный процесс может упасть, пока на хосте ещё есть доступная память. Изучите настроенный лимит и время сбоя, прежде чем увеличивать размер VPS. Справочник ядра по файловой системе proc документирует поля памяти, лежащие в основе этих наблюдений.

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

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 МиБ в каждый из двух наблюдаемых дней. Файловая система имеет около 2 ГиБ доступного пространства. Деление оставшегося пространства на этот краткосрочный рост предполагает лишь около пяти дней при той же скорости, до учёта операционного запаса. Это плановая оценка, а не прогноз и не безопасный срок, до которого можно ждать; загрузки и временная работа могут поступать неравномерно.

Следующее действие — проверить хранение загрузок и ожидаемый спрос, запланировать дополнительное хранилище, если это оправдано, и настроить оповещение достаточно рано, чтобы успеть действовать. Больше RAM не решило бы эту находку. В другом случае сборка развёртывания может создать кратковременный пик памяти, пока обслуживание остаётся небольшим; перенос сборки с VPS мог бы быть полезнее, чем постоянное увеличение среды выполнения.

После обоснованного изменения повторите те же показания и одно действие приложения. Убедитесь, что пространство действительно доступно и нужные данные всё ещё работают. Оставляйте удаление и изменение размера плановыми операциями с шагами восстановления, а не автоматическими реакциями на красное число. Используйте руководство по бюджету ресурсов чтобы превратить доказанную потребность в выбор конфигурации, и отработайте восстановление прежде чем полагаться на очистку или миграцию.