stress-ng
always hits systems hard. For example, the --cpu-method
option has documentation for the best one to "make a CPU run hot". "It was designed to exercise various physical subsystems of a computer as well as the various operating system kernel interfaces."
Profile what exactly it does if you are curious. Easy on Linux, installing debug symbols then perf top
is a good start. Both on the stress tests, and other applications.
Regarding -vm
, mmap()
, touching pages, and munmap()
in a tight loop is going to be brutal to the virtual memory system, and be memory bottlenecked. Instructions per clock is probably going to be terrible, and not show what the CPU can do when kept fed with data. Symptoms at the host metrics level will include a very large % of system CPU time.
stress-ng -vm 1 --vm-hang 0
will sleep virtual memory (VM) workers indefinitely, after touching the memory. Try this if you want to allocate a large anonymous memory area, but not do anything with it. Questionable utility, I suspect, but you can do it.
This will not perform like practical applications do:
stress-ng
does not do useful work; this is not a benchmark.
- Memory or CPU workers are not I/O bound waiting for slow disks or network.
- CPU method algorithms, while diverse and real world, are not what you might see from say a transactional database.
- No file I/O, if relevant to this application.
stress-ng
has file stressors, but not surprisingly they will hit the system hard.
Still useful to be sure hosts don't fall over under stress.