[AWS] Chargez intentionnellement une instance Ubuntu EC2 et vérifiez les métriques sur CloudWatch
Vous souhaiterez peut-être charger intentionnellement une instance EC2 à des fins de vérification. Cette fois, j'ai eu l'occasion de l'essayer sur une instance Ubuntu, je vais donc résumer la procédure. L'article précédent (Lier l'utilisation de la mémoire à CloudWatch) était un long prélude à la résumer. .. ..
CPU
Il est possible d'appliquer une charge avec la commande stress-ng ou la commande openssl.
Procédure d'installation:
$ sudo apt-get update
$ sudo apt install stress-ng
$ sudo apt install openssl
Options d'exécution de la commande Stress-ng:
$ stress-ng --cpu <nombre de processeurs virtuels> -l <l'utilisation du processeur> -t <Temps d'exécution>
Lors de l'application de la charge du processeur
・-cpu: à spécifier lors de l'exécution d'un test de charge du processeur. Spécifiez le nombre de cœurs de processeur.
・-l: spécifiez le taux d'utilisation du processeur. Numéro spécifié(%)La charge est appliquée.
・-t: spécifiez l'heure d'exécution.
Pour les nombres uniquement, spécifiez le nombre de secondes, m après le nombre, h,Ajoutez d pour spécifier les minutes, les heures et les jours.
À titre d'exemple, le résultat de l'exécution de la commande sur l'instance t3a.medium (vCPU numéro 2) est le suivant. Vous pouvez voir que le taux d'utilisation a augmenté jusqu'à 90% spécifié.
$ stress-ng --cpu 2 -l 90 -t 15m
Une autre option consiste à utiliser la commande openssl. À l'origine, il mesure la vitesse de l'algorithme, mais comme il utilise 100% du processeur, il peut être utilisé à la place d'un test de charge.
$ openssl speed -multi <nombre de processeurs virtuels>
Quand je l'ai essayé avec une instance t3a.medium, le taux d'utilisation est devenu 100% pendant environ 25 minutes.
Mémoire
La mémoire peut également être chargée avec la commande stress-ng. Pour vérifier avec CloudWatch, définissez l'agent dans Procédure de l'article précédent à l'avance.
$ stress-ng -m <Nombre de travailleurs> --vm-bytes <Consommation de mémoire> -t <Temps d'exécution>
Lors de l'application d'une charge mémoire
・-m: nombre de travailleurs à charger. Si vous ne l'appelez pas soudainement, spécifiez 1.
・--vm-bytes：
Spécifiez la consommation de mémoire. Ajouter une unité après le numéro
b(Travail à temps partiel), k(キロTravail à temps partiel), m(メガTravail à temps partiel), g(ギガTravail à temps partiel), %(Pourcentage)Peut être spécifié avec.
Notez que si vous augmentez le nombre de travailleurs, la charge de cette spécification × nombre de travailleurs sera appliquée.
・-t: spécifiez l'heure d'exécution.
Pour les nombres uniquement, spécifiez le nombre de secondes, m après le nombre, h,Ajoutez d pour spécifier les minutes, les heures et les jours.
C'est le résultat d'essayer avec l'instance t3a.medium (mémoire 4 Go).
$ stress-ng -m 1 --vm-bytes 3072M --timeout 600
Même si j'ai spécifié 100% de la mémoire, cela n'a pas été enregistré à 100% sur CloudWatch. Si vous voulez tester à la dernière minute, il semble que vous deviez ajuster en spécifiant des octets.
$ 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)
Si le nombre de nœuds de calcul est 1, une erreur se produira si plus que la quantité de mémoire réelle est spécifiée. Si une charge supérieure à la taille de l'instance est appliquée, cela provoquera une anomalie (comme décrit dans le manuel: Notez que cela peut amener les systèmes à déclencher le kernel OOM killer sur les systèmes Linux si la mémoire physique n'est pas suffisante et si le swap n'est pas disponible.). Faites attention.
$ 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
disque
La commande stress-ng prend également en charge les disques.
$ stress-ng -d <Nombre de travailleurs> --hdd-bytes <Utilisation du disque> -t <Temps d'exécution> --temp-path <Directeur de travail>
Lors de l'application d'une charge de disque
・-m: nombre de travailleurs à charger. Si vous ne l'appelez pas soudainement, spécifiez 1.
・--vm-bytes：
Spécifiez la consommation de mémoire. Ajouter une unité après le numéro
b(Travail à temps partiel), k(キロTravail à temps partiel), m(メガTravail à temps partiel), g(ギガTravail à temps partiel), %(Pourcentage)Peut être spécifié avec.
Notez que si vous augmentez le nombre de travailleurs, la charge de cette spécification × nombre de travailleurs sera appliquée.
・-t: spécifiez l'heure d'exécution.
Pour les nombres uniquement, spécifiez le nombre de secondes, m après le nombre, h,Ajoutez d pour spécifier les minutes, les heures et les jours.
・--temp-chemin: répertoire pour créer des fichiers temporaires
S'il n'est pas spécifié, le répertoire de travail actuel sera consommé.
Quand je l'ai essayé sur la même instance, disk_io et disk_write ont augmenté, mais disk_read a augmenté moins.
$ stress-ng -d 1 --hdd-bytes 2048M -t 1200 --temp-path /tmp
En regardant l'utilisation du disque, vous pouvez voir qu'un fichier temporaire est en cours de création et de suppression.
réseau
Étant donné que la commande stress-ng ne prend pas en charge le réseau, cette fois j'ai créé un script qui répète PUT et GET du même fichier dans S3 et l'ai essayé.
* Créez un fichier factice de 1 Go
$ 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
* Script shell qui se répète le nombre de fois spécifié
$ cat stress_test.sh
#!/bin/bash
cnt=1
while [ $cnt -le $1 ]; do
aws s3 cp 1G.dummy s3://<Nom du godet>/1G.dummy
aws s3 cp s3://<Nom du godet>/1G.dummy .
cnt=`expr $cnt + 1`
done
$ ./stress_test.sh 10
upload: ./1G.dummy to s3://<Nom du godet>/1G.dummy
download: s3://<Nom du godet>/1G.dummy to ./1G.dummy
Completed 265.2 MiB/1000.0 MiB (86.6 MiB/s) with 1 file(s) remaining
* Omis ci-dessous *
Lorsque cela a été exécuté, il a été confirmé que NetworkIn et NetworkOut augmentaient.
Il s'agit du disque IO pour le moment. Vous pouvez voir que la moitié droite provient de ce script, et stress-ng est plus chargé.
c'est tout. Cette fois, la charge n'était pas autant que le test de résistance, mais il a été confirmé que la charge avait été augmentée jusqu'à la limite supérieure des métriques, mais il a été confirmé que les métriques CloudWatch pouvaient être augmentées respectivement.
Matériel de référence
Recommended Posts