[AWS] Intentionally load an Ubuntu EC2 instance and check the metrics with CloudWatch
You may want to intentionally load an EC2 instance for verification purposes. This time, I had the opportunity to try it on an Ubuntu instance, so I will summarize the procedure. Last article (Linking memory usage to CloudWatch) was a long prelude to summarizing this. .. ..
CPU
You can apply the load with the stress-ng command or the openssl command.
Installation procedure:
$ sudo apt-get update
$ sudo apt install stress-ng
$ sudo apt install openssl
Stress-ng command execution options:
$ stress-ng --cpu <vCPU count> -l <CPU usage> -t <Execution time>
When applying CPU load
・-cpu: Specify when performing a CPU load test. Specify the number of CPU cores.
・-l: Specify the CPU usage rate. Specified number(%)Load is applied.
・-t: Specify the execution time.
If only numbers, specify the number of seconds, m after the number, h,Add d to specify minutes, hours, and days.
As an example, the result of executing the command on the t3a.medium instance (vCPU number 2) is as follows. You can see that the usage rate has increased to the specified 90%.
$ stress-ng --cpu 2 -l 90 -t 15m
Another option is to use the openssl command. Originally it measures the algorithm speed, but since it uses 100% of the CPU, it can be used instead of a load test.
$ openssl speed -multi <vCPU count>
When I tried it with a t3a.medium instance, the usage rate became 100% for about 25 minutes.
memory
Memory can also be loaded with the stress-ng command. To check with CloudWatch, set the agent in Procedure of the previous article in advance.
$ stress-ng -m <Number of workers> --vm-bytes <Memory consumption> -t <Execution time>
When applying memory load
・-m: Number of workers to load. If you don't call it suddenly, specify 1.
・--vm-bytes：
Specify memory consumption. Add a unit after the number
b(Part-Time Job), k(キロPart-Time Job), m(メガPart-Time Job), g(ギガPart-Time Job), %(Percentage)Can be specified with.
Note that if the number of workers is increased, the load of this specification x number of workers will be applied.
・-t: Specify the execution time.
If only numbers, specify the number of seconds, m after the number, h,Add d to specify minutes, hours, and days.
This is the result of trying with t3a.medium instance (memory 4GiB).
$ stress-ng -m 1 --vm-bytes 3072M --timeout 600
Even if I specified 100% of the memory, it was not recorded up to 100% on CloudWatch. If you want to test at the last minute, it seems that you need to adjust by specifying bytes.
$ stress-ng -m 1 --vm-bytes 100% --timeout 1200
stress-ng: info: [9730] dispatching hogs: 1 vm
stress-ng: info: [9730] successful run completed in 1200.02s (20 mins, 0.02 secs)
If the number of workers is 1, an error will occur if more than the actual memory amount is specified. If you apply a load larger than the instance size, it will cause an abnormality (as described in the manual: 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.). be careful.
$ stress-ng -m 1 --vm-bytes 3889M --timeout 120
stress-ng: info: [9215] dispatching hogs: 1 vm
stress-ng: error: [9233] stress-ng-vm: gave up trying to mmap, no available memory
stress-ng: info: [9215] successful run completed in 10.01s
disk
The stress-ng command also supports disks.
$ stress-ng -d <Number of workers> --hdd-bytes <Disk usage> -t <Execution time> --temp-path <Working directory>
When applying a disk load
・-m: Number of workers to load. If you don't call it suddenly, specify 1.
・--vm-bytes：
Specify memory consumption. Add a unit after the number
b(Part-Time Job), k(キロPart-Time Job), m(メガPart-Time Job), g(ギガPart-Time Job), %(Percentage)Can be specified with.
Note that if the number of workers is increased, the load of this specification x number of workers will be applied.
・-t: Specify the execution time.
If only numbers, specify the number of seconds, m after the number, h,Add d to specify minutes, hours, and days.
・--temp-path: Directory to create temporary files
If not specified, the current working directory will be consumed.
When I tried it on the same instance, disk_io and disk_write went up, but disk_read went up less.
$ stress-ng -d 1 --hdd-bytes 2048M -t 1200 --temp-path /tmp
Looking at the disk usage, you can see that temporary files are being created and deleted.
network
Since the stress-ng command does not support the network, this time I created a script that repeats PUT and GET of the same file in S3 and tried it.
* Create a dummy 1GB file
$ dd if=/dev/zero of=1G.dummy bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.81233 s, 373 MB/s
$ ls -la 1G.dummy
-rw-r--r-- 1 ubuntu ubuntu 1048576000 Nov 16 02:59 1G.dummy
* Shell script that repeats the specified number of times
$ cat stress_test.sh
#!/bin/bash
cnt=1
while [ $cnt -le $1 ]; do
aws s3 cp 1G.dummy s3://<Bucket name>/1G.dummy
aws s3 cp s3://<Bucket name>/1G.dummy .
cnt=`expr $cnt + 1`
done
$ ./stress_test.sh 10
upload: ./1G.dummy to s3://<Bucket name>/1G.dummy
download: s3://<Bucket name>/1G.dummy to ./1G.dummy
Completed 265.2 MiB/1000.0 MiB (86.6 MiB/s) with 1 file(s) remaining
* Omitted below *
When this was executed, it was confirmed that NetworkIn and NetworkOut were rising.
This is the disk IO at this time. You can see that the right half is from this script, and stress-ng is more loaded.
that's all. This time, the load was not as much as the stress test, but it was confirmed that the load was increased to the upper limit of the metric, but it was confirmed that each CloudWatch metric can be increased.
Reference material
Recommended Posts