Buying a bigger plan is quick, and sometimes right. It is also the most common way to spend money on a problem that was a missing index or a single slow API call. Ten minutes of measurement decides it.

Are you actually out of memory

free -h\nvmstat 1 5

In vmstat, read the si and so columns: pages swapped in and out per second. Sustained non-zero numbers mean the machine is genuinely short of memory. Zeros mean it is not, whatever the free column says.

Linux uses free memory for disk cache on purpose. A machine reporting almost no free memory and no swapping is healthy - see RAM, swap and when swap is a symptom.

What it is instead, usually

  • A slow query. One unindexed query on a growing table. See the slow query log.
  • Waiting on something else - a payment API, a mail server, a remote feed - where the server is idle, not busy.
  • Disk. High iowait in top means the storage is the limit; more memory only helps by caching around it.
  • One CPU core pinned by a single-threaded job while the others sit idle.

Read them apart

top -b -n1 | head -15        # load, iowait, what is busy\niostat -x 1 3               # disk latency and utilisation\nss -s                       # connection counts

When more RAM IS the answer

  • Steady swapping under normal traffic.
  • A database working set larger than what you can give the buffer pool - see innodb_buffer_pool_size.
  • A PHP pool you cannot size large enough for your traffic without exceeding memory.
Measure first, upgrade second. A plan change is easy to make and awkward to unwind, and the slow query is still there afterwards - now on a more expensive machine.