[AWS] Laden Sie absichtlich eine Ubuntu EC2-Instanz und überprüfen Sie die Metriken in CloudWatch
Möglicherweise möchten Sie absichtlich eine EC2-Instanz zu Überprüfungszwecken laden. Dieses Mal hatte ich die Gelegenheit, es auf einer Ubuntu-Instanz zu versuchen, also werde ich das Verfahren zusammenfassen. Vorheriger Artikel (Verknüpfen der Speichernutzung mit CloudWatch) war ein langer Auftakt zur Zusammenfassung. .. ..
CPU
Es ist möglich, die Last mit dem Befehl stress-ng oder dem Befehl openssl anzuwenden.
Installationsverfahren:
$ sudo apt-get update
$ sudo apt install stress-ng
$ sudo apt install openssl
Ausführungsoptionen für Stress-ng-Befehle:
$ stress-ng --cpu <vCPU-Anzahl> -l <CPU auslastung> -t <Ausführungszeit>
Beim Anwenden der CPU-Last
・-CPU: Geben Sie an, wann ein CPU-Auslastungstest durchgeführt werden soll. Geben Sie die Anzahl der CPU-Kerne an.
・-l: Geben Sie die CPU-Auslastungsrate an. Angegebene Nummer(%)Last wird angewendet.
・-t: Geben Sie die Ausführungszeit an.
Geben Sie nur für Zahlen die Anzahl der Sekunden an, m nach der Zahl, h,Fügen Sie d hinzu, um Minuten, Stunden und Tage anzugeben.
Das Ergebnis der Ausführung des Befehls auf der Instanz t3a.medium (vCPU Nummer 2) lautet beispielsweise wie folgt. Sie können sehen, dass die Nutzungsrate auf die angegebenen 90% gestiegen ist.
$ stress-ng --cpu 2 -l 90 -t 15m
Eine andere Möglichkeit ist die Verwendung des Befehls openssl. Ursprünglich misst es die Algorithmusgeschwindigkeit, aber da es 100% der CPU verbraucht, kann es anstelle eines Auslastungstests verwendet werden.
$ openssl speed -multi <vCPU-Anzahl>
Als ich es mit einer t3a.medium-Instanz versuchte, wurde die Nutzungsrate für etwa 25 Minuten 100%.
Erinnerung
Der Speicher kann auch mit dem Befehl stress-ng geladen werden. Um dies mit CloudWatch zu überprüfen, legen Sie den Agenten im Voraus unter Verfahren des vorherigen Artikels fest.
$ stress-ng -m <Anzahl der Arbeiter> --vm-bytes <Speicherverbrauch> -t <Ausführungszeit>
Beim Anwenden einer Speicherlast
・-m: Anzahl der zu ladenden Arbeiter. Wenn Sie es nicht plötzlich aufrufen, geben Sie 1 an.
・--vm-bytes：
Geben Sie den Speicherverbrauch an. Fügen Sie nach der Nummer eine Einheit hinzu
b(Teilzeitstelle), k(キロTeilzeitstelle), m(メガTeilzeitstelle), g(ギガTeilzeitstelle), %(Prozentsatz)Kann mit angegeben werden.
Beachten Sie, dass, wenn Sie die Anzahl der Arbeiter erhöhen, die Last dieser Spezifikation × Anzahl der Arbeiter angewendet wird.
・-t: Geben Sie die Ausführungszeit an.
Geben Sie nur für Zahlen die Anzahl der Sekunden an, m nach der Zahl, h,Fügen Sie d hinzu, um Minuten, Stunden und Tage anzugeben.
Dies ist das Ergebnis eines Versuchs mit der Instanz t3a.medium (Speicher 4GiB).
$ stress-ng -m 1 --vm-bytes 3072M --timeout 600
Selbst wenn ich 100% des Speichers angegeben habe, wurde er nicht zu 100% in CloudWatch aufgezeichnet. Wenn Sie in letzter Minute testen möchten, müssen Sie anscheinend Anpassungen vornehmen, indem Sie Bytes angeben.
$ 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)
Wenn die Anzahl der Worker 1 beträgt, tritt ein Fehler auf, wenn mehr als die tatsächliche Speichermenge angegeben wird. Wenn eine Last angewendet wird, die größer als die Instanzgröße ist, führt dies zu einer Abnormalität (wie im Handbuch beschrieben: Beachten Sie, dass dies dazu führen kann, dass Systeme den Kernel-OOM-Killer auf Linux-Systemen auslösen, wenn nicht genügend physischer Speicher und Swap verfügbar sind .). Achtung.
$ 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
Scheibe
Der Befehl stress-ng unterstützt auch Festplatten.
$ stress-ng -d <Anzahl der Arbeiter> --hdd-bytes <Festplattennutzung> -t <Ausführungszeit> --temp-path <Arbeitsverzeichnis>
Beim Anwenden einer Festplattenlast
・-m: Anzahl der zu ladenden Arbeiter. Wenn Sie es nicht plötzlich aufrufen, geben Sie 1 an.
・--vm-bytes：
Geben Sie den Speicherverbrauch an. Fügen Sie nach der Nummer eine Einheit hinzu
b(Teilzeitstelle), k(キロTeilzeitstelle), m(メガTeilzeitstelle), g(ギガTeilzeitstelle), %(Prozentsatz)Kann mit angegeben werden.
Beachten Sie, dass, wenn Sie die Anzahl der Arbeiter erhöhen, die Last dieser Spezifikation × Anzahl der Arbeiter angewendet wird.
・-t: Geben Sie die Ausführungszeit an.
Geben Sie nur für Zahlen die Anzahl der Sekunden an, m nach der Zahl, h,Fügen Sie d hinzu, um Minuten, Stunden und Tage anzugeben.
・--temp-Pfad: Verzeichnis zum Erstellen temporärer Dateien
Wenn nicht angegeben, wird das aktuelle Arbeitsverzeichnis verwendet.
Als ich es auf derselben Instanz versuchte, nahmen disk_io und disk_write zu, aber disk_read nahm weniger zu.
$ stress-ng -d 1 --hdd-bytes 2048M -t 1200 --temp-path /tmp
Wenn Sie sich die Festplattennutzung ansehen, sehen Sie, dass eine temporäre Datei erstellt und gelöscht wird.
Netzwerk
Da der Befehl stress-ng das Netzwerk nicht unterstützt, habe ich dieses Mal ein Skript erstellt, das PUT und GET derselben Datei in S3 wiederholt, und es ausprobiert.
* Erstellen Sie eine Dummy-1-GB-Datei
$ 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-Skript, das die angegebene Anzahl von Malen wiederholt
$ cat stress_test.sh
#!/bin/bash
cnt=1
while [ $cnt -le $1 ]; do
aws s3 cp 1G.dummy s3://<Eimername>/1G.dummy
aws s3 cp s3://<Eimername>/1G.dummy .
cnt=`expr $cnt + 1`
done
$ ./stress_test.sh 10
upload: ./1G.dummy to s3://<Eimername>/1G.dummy
download: s3://<Eimername>/1G.dummy to ./1G.dummy
Completed 265.2 MiB/1000.0 MiB (86.6 MiB/s) with 1 file(s) remaining
* Unten weggelassen *
Als dies ausgeführt wurde, wurde bestätigt, dass NetworkIn und NetworkOut anstiegen.
Dies ist die Festplatten-E / A zu diesem Zeitpunkt. Sie können sehen, dass die rechte Hälfte aus diesem Skript stammt und Stress-ng stärker geladen ist.
das ist alles. Diesmal war die Last nicht so hoch wie der Stresstest, aber es wurde bestätigt, dass die Last bis zur Obergrenze der Metriken erhöht wurde, aber es wurde bestätigt, dass die CloudWatch-Metriken jeweils erhöht werden können.
Referenzmaterial
Recommended Posts