Read memory and disk warnings before upgrading.

Capture a small baseline with context

Use a Linux account allowed to inspect the application you operate. The commands here inspect state; they do not remove files or resize storage. Some directories and journals need elevated access. Replace /var/lib/field-api, /opt/field-api and /opt/first-api with real application paths, and confirm those paths exist before interpreting the results.

Record the time, current release and activity: ordinary traffic, an upload, a report job or a deployment build. Take another reading during comparable activity. Two unrelated screenshots can make a healthy machine look inconsistent. If users are already affected, capture the first useful clue from the application failure guide before making several changes at once.

Read available memory, then inspect the workload

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

In free, available memory estimates what could be used for new applications without swapping. It accounts for reclaimable cache, so it answers a different question from completely unused “free” memory. See the upstream free manual. Linux uses memory for file caching; a large cache alone is not evidence of a leak. The kernel memory overview explains why cache and application memory coexist.

Illustrative reading, not a server measurement: a small host has about 1.9 GiB usable memory, 80 MiB free and 850 MiB available. The low free figure alone does not justify an upgrade. If available memory repeatedly falls near zero during a report, requests slow down and relevant allocation or out-of-memory messages appear, that combined evidence deserves investigation.

The ps command lists process RSS in KiB, largest first. RSS describes resident memory, not a complete accounting of exclusive ownership; shared pages can appear in multiple processes. Do not add every RSS figure and treat the result as exact host usage. The upstream ps reference defines RSS and sorting. Record the process name and whether its footprint returns toward its earlier level after the workload ends.

Swap in use can reflect earlier activity; it does not prove current pressure by itself. Also distinguish host capacity from service or container limits. A constrained process can fail while the host still has available memory. Inspect the configured limit and the time of failure before increasing the VPS size. The kernel's proc filesystem reference documents the memory fields behind these observations.

Find the filesystem that is actually filling

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

The first command reports space on the filesystems containing those paths. The second reports inodes, which are filesystem records needed for files and directories. A workload with many tiny files may exhaust inodes while byte capacity remains. Check the mount and both kinds of capacity rather than using the size of the whole VPS as your only number. See the GNU df manual.

A path on a separate mounted volume can fill independently from the root filesystem. Conversely, two listed paths may belong to the same filesystem, so their available space is not additive. Filesystem reservations, quotas and storage layers can also affect what the app can write. A single displayed percentage does not identify the owner of the growth.

Attribute growth to logs, uploads or artifacts

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

GNU du estimates allocated space under each directory. Here -x avoids crossing into another filesystem, -h uses readable units and -d1 limits the displayed depth. Large trees can still take time and disk activity to scan. Permission errors mean the view is incomplete. See the GNU du manual. The journal command reports journal storage, including active and archived files, as documented by journalctl.

Compare the largest directories with their purpose:

• Logs: did a repeated error increase volume, and is rotation configured?
• Uploads: are retained user files growing as expected, and are abandoned partial uploads accounted for?
• Release artifacts: are old builds accumulating beyond the rollback policy?
• Database files: does the database's own tooling explain the growth and maintenance needs?

Do not delete an unfamiliar database directory or use a broad container-volume cleanup as an investigation step. Identify ownership, retention requirements and a recoverable copy first. If df and directory totals disagree substantially, inspect mount boundaries, access errors and files still held open after deletion with an experienced operator; repeatedly deleting visible files may miss the occupied space.

Turn the readings into a specific next action

Illustrative case: available memory stays comfortable, but an upload directory grows by roughly 400 MiB on each of two observed days. The filesystem has about 2 GiB available. Dividing remaining space by that short-term growth suggests only about five days at the same rate, before allowing operating headroom. That is a planning estimate, not a forecast or a safe deadline to wait until; uploads and temporary work may arrive unevenly.

The next action is to check upload retention and expected demand, plan additional storage if justified, and set an alert early enough to act. More RAM would not address this finding. In a different case, a deployment build might create a brief memory peak while serving remains small; moving the build off the VPS could be more useful than permanently enlarging the runtime.

After a justified change, repeat the same readings and one application action. Confirm that space is actually available and the intended data still works. Keep deletion and resizing as planned operations with recovery steps, not automatic responses to a red number. Use the resource budget guide to turn a demonstrated need into configuration choices, and practice restoration before depending on a cleanup or migration.