If you are testing how your autoscaling policies respond to CPU load then a really simple way to test this is using the “stress” command. Note: this is a very crude mechanism to test and wherever possible you should try and generate synthetic application load.
#!/bin/bash # DESCRIPTION: After updating from the repo, installs stress-ng, a tool used to create various system load for testing purposes. yum update -y # Install stress-ng sudo apt install stress-ng # CPU spike: Run a CPU spike for 5 seconds uptime stress-ng --cpu 4 --timeout 5s --metrics-brief uptime # Disk Test: Start N (2) workers continually writing, reading and removing temporary files: stress-ng --disk 2 --timeout 5s --metrics-brief # Memory stress test # Populate memory. Use mmap N bytes per vm worker, the default is 256MB. # You can also specify the size as % of total available memory or in units of # Bytes, KBytes, MBytes and GBytes using the suffix b, k, m or g: # Note: The --vm 2 will start N workers (2 workers) continuously calling # mmap/munmap and writing to the allocated memory. Note that this can cause # systems to trip the kernel OOM killer on Linux systems if not enough # physical memory and swap is not available stress-ng --vm 2 --vm-bytes 1G --timeout 5s # Combination Stress # To run for 5 seconds with 4 cpu stressors, 2 io stressors and 1 vm # stressor using 1GB of virtual memory, enter: stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 5s --metrics-brief