CPU load tests (stress-ng)

stress-ng generates controlled load on the CPU, memory, and other subsystems. On a HolyCloud Performance VPS, it helps validate vCPU allocation after migration, compare two plan sizes, or detect thermal/logical instability before production.

Prerequisites

• Linux VPS (Debian/Ubuntu recommended) with sudo access
• Maintenance window: load can impact services hosted on the same VPS
• Implicit authorization: do not run prolonged tests on a shared VPS without agreement (fair-use)
• stress-ng installable from official repositories

Installation

sudo apt update
sudo apt install -y stress-ng
stress-ng --version

On RHEL/Alma:

sudo dnf install -y epel-release
sudo dnf install -y stress-ng

Short CPU test (baseline)

Run a 60-second test on all logical vCPUs:

nproc
stress-ng --cpu $(nproc) --cpu-method all --timeout 60s --metrics-brief

Interpretation:

| Indicator | Reading |

|------------|---------|

| cpu BogoOps/s | Relative value — compare between identical runs |

| Exit code 0 | No error reported by stress-ng |

| Load average | Should reflect vCPU count under load |

Extended stability test

For a compute server or self-hosted CI:

stress-ng --cpu $(nproc) --timeout 3600s --verify \
  --temp-path /tmp --metrics

The --verify option enables integrity checks on some workers (extra CPU cost).

On a cloud VPS, one hour at 100% CPU may trigger throttling at the hypervisor — stay reasonable (15–30 minutes is often enough).

Useful load methods

# intensive floating point
stress-ng --cpu 4 --cpu-method fft --timeout 120s

# integer / crypto-like
stress-ng --cpu 4 --cpu-method matrixprod --timeout 120s

# memory + CPU mix
stress-ng --cpu $(nproc) --vm 2 --vm-bytes 70% --timeout 120s

Measure in parallel

During the test, observe:

# terminal 2
mpstat -P ALL 1
vmstat 1

Also monitor temperature if exposed (sensors) — rare on VPS, useful on dedicated servers.

Export a simple report

stress-ng --cpu $(nproc) --timeout 300s --metrics \
  2>&1 | tee /tmp/stress-ng-$(date +%F).log

Keep the log with date, VPS plan, and kernel:

uname -r
lscpu | grep -E 'Model name|CPU\(s\)|MHz'

HolyCloud best practices

• Prefer tests off peak hours for production sites on the same VPS.
• Do not run multiple stress-ng instances in parallel “to go faster” — that skews the measurement.
• Always compare same duration, same method, same worker count.
• If you change Performance plan, rerun a reference test and archive the log.

Troubleshooting

| Problem | Approach |

|----------|-------|

| Process killed (OOM) | Reduce --vm-bytes or workers |

| Very low performance | Noisy neighbor temporarily — retry at another time |

| stress-ng: command not found | Package not installed or restricted PATH |

| Load >> vCPU | Normal under stress; abnormal at idle → investigate |

Benchmark limits

stress-ng measures sustained load tolerance, not application throughput (PHP, MySQL, Redis). Complement with HTTP tests (wrk, hey) and I/O (fio) for a complete picture.

Need help?

If performance is structurally below the expected plan after several reproducible measurements, open a HolyCloud ticket with the stress-ng log, lscpu, plan, and test time window.