Tests charge CPU (stress-ng)

stress-ng génère des charges contrôlées sur le processeur, la mémoire et d'autres sous-systèmes. Sur un VPS Performance HolyCloud, il sert à valider l'allocation vCPU après migration, comparer deux tailles d'offre ou détecter une instabilité thermique/logique avant mise en production.

Prérequis

• VPS Linux (Debian/Ubuntu recommandé) avec accès sudo
• Fenêtre de maintenance : la charge peut impacter les services hébergés sur le même VPS
• Autorisation implicite : n'exécutez pas de tests prolongés sur un VPS partagé sans accord (fair-use)
• stress-ng installable via les dépôts officiels

Installation

sudo apt update
sudo apt install -y stress-ng
stress-ng --version

Sur RHEL/Alma :

sudo dnf install -y epel-release
sudo dnf install -y stress-ng

Test CPU court (baseline)

Lancez un test de 60 secondes sur tous les vCPU logiques :

nproc
stress-ng --cpu $(nproc) --cpu-method all --timeout 60s --metrics-brief

Interprétation :

| Indicateur | Lecture |

|------------|---------|

| cpu BogoOps/s | Valeur relative — comparez entre runs identiques |

| Code sortie 0 | Pas d'erreur signalée par stress-ng |

| Load average | Doit refléter le nombre de vCPU sous charge |

Test de stabilité prolongé

Pour un serveur de calcul ou CI self-hosted :

stress-ng --cpu $(nproc) --timeout 3600s --verify \
  --temp-path /tmp --metrics

L'option --verify active des contrôles d'intégrité sur certains workers (coût CPU supplémentaire).

Sur VPS cloud, une heure à 100 % CPU peut déclencher une limitation côté hyperviseur — restez raisonnable (15–30 min suffisent souvent).

Méthodes de charge utiles

# flottants intensifs
stress-ng --cpu 4 --cpu-method fft --timeout 120s

# entiers / crypto-like
stress-ng --cpu 4 --cpu-method matrixprod --timeout 120s

# mix mémoire + CPU
stress-ng --cpu $(nproc) --vm 2 --vm-bytes 70% --timeout 120s

Mesurer en parallèle

Pendant le test, observez :

# terminal 2
mpstat -P ALL 1
vmstat 1

Surveillez aussi la température si exposée (sensors) — rare sur VPS, mais utile sur dédié.

Exporter un rapport simple

stress-ng --cpu $(nproc) --timeout 300s --metrics \
  2>&1 | tee /tmp/stress-ng-$(date +%F).log

Conservez le log avec la date, le plan VPS et le noyau :

uname -r
lscpu | grep -E 'Model name|CPU\(s\)|MHz'

Bonnes pratiques HolyCloud

• Préférez les tests hors heures de pointe pour les sites en production sur le même VPS.
• Ne lancez pas plusieurs instances stress-ng en parallèle « pour aller plus vite » — cela fausse la mesure.
• Comparez toujours même durée, même méthode, même nombre de workers.
• Si vous changez d'offre Performance, refaites un run de référence et archivez le log.

Dépannage

| Symptème | Piste |

|----------|-------|

| Process tué (OOM) | Réduisez --vm-bytes ou workers |

| Performance très basse | Voisin bruyant temporaire — réessayez à un autre créneau |

| stress-ng: command not found | Paquet non installé ou PATH restreint |

| Load >> vCPU | Normal sous stress ; anormal au repos → investiguer |

Limites du benchmark

stress-ng mesure la tenue à la charge, pas le débit applicatif (PHP, MySQL, Redis). Complétez avec des tests HTTP (wrk, hey) et I/O (fio) pour une vue complète.

Besoin d'aide ?

Si les performances sont structurellement inférieures à l'offre attendue après plusieurs mesures reproductibles, ouvrez un ticket HolyCloud avec le log stress-ng, lscpu, plan et fenêtre horaire du test.