Four SSH Commands for Checking a Linux WordPress Server

2026-02-15

When a WordPress site starts responding slowly, check available memory and disk space before changing plugins or themes. A small cloud instance can run short of either, leaving the database slow to respond or services unable to write files.

The Bitnami WordPress image on Lightsail runs on Linux. Connect over SSH to check the operating system’s view of its resources. These four commands inspect the system without changing it.

1. Check available memory

Memory is a good place to start. The database and PHP workers both use it, and concurrent work can raise demand quickly on a small instance.

Run this command after connecting over SSH.

free -h


Example output:

              total        used        free      shared  buff/cache   available
Mem:          976Mi       812Mi        64Mi        21Mi       100Mi        89Mi
Swap:         1.0Gi       120Mi       904Mi

What the memory columns mean

  • total: RAM visible to the operating system
  • used: memory counted as in use
  • free: memory currently unused
  • buff/cache: buffers and caches, some of which the system can reclaim
  • available: estimated memory available to new work without swapping

A low free figure is common because Linux uses idle memory for caching. Look at available, which is an estimate of how much memory new work can use without swapping. A reading near 100 MiB is a useful signal on the example instance, especially if it stays low or the system is swapping. It is not a universal threshold.

On a 1 GB instance, there may be little headroom left for a burst of database or PHP activity. If timeouts coincide with low available memory, compare readings over time and check the logs for evidence.

2. See which processes are using memory

Check which processes are using resources while the slowdown is happening.

top

The summary is at the top, with individual processes below. On a WordPress server you might see the following names.

  • mysqld or mariadbd, the database server
  • php-fpm, the PHP worker processes that execute WordPress code
  • apache2, httpd or nginx, depending on the web server

A database process using a lot of memory may simply be using its cache. If usage changes during a slowdown, compare the process list with application and access logs before attributing it to comments, crawlers or repeated login attempts.

Press q to quit.

3. Check free disk space

WordPress writes uploads, logs and cache files, and its database needs room for writes too. If the relevant filesystem fills up, uploads and updates can fail and the site may return errors.

Run the following command.

df -h


Example output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   17G  2.1G  90% /
tmpfs           487M     0  487M   0% /dev/shm

What the disk columns mean

  • Size: capacity of the filesystem
  • Used: space in use
  • Avail: space still available
  • Use%: percentage in use

In this example, the root filesystem mounted at / is 90 percent full. Use% tells you where to investigate, while Avail tells you how much room remains. Look at the rate of growth as well. A filesystem with two gigabytes left can be fine one day and full the next if a runaway log is writing to it.

4. Find the directories using space

Once you know which filesystem is filling up, check which directories use the space. This command prints a human-readable total for each immediate subdirectory of /opt/bitnami, along with the total for that directory.

du -h --max-depth=1 /opt/bitnami

Check the paths for your Bitnami image. Some layouts use different locations or point into /bitnami.

  • /opt/bitnami/wordpress/wp-content/uploads is a common location for WordPress media.
  • /opt/bitnami/apache/logs contains Apache logs on many Bitnami images.
  • MariaDB data may be under /bitnami/mariadb/data. Confirm the database’s actual data directory before inspecting it.

Access logs can grow quickly on a busy site. Check their size and the log rotation configuration before deciding what to do with them.

Build a baseline before trouble

The dashboard may show you that an upload failed or that a request took too long. The operating system can show whether the machine had room to write or memory to do the work.

Run free -h and df -h when the server is healthy as well as when it is slow. You will have a baseline to compare with the next unusual reading.

These checks give you a place to start. Once you know which resource is under pressure, use the process list and logs to find what changed.

Search stories