Paillasse/docs/capacite.md

Capacité du serveur Syllabus

Mesuré le 2026-10-09 (étape 13) sur le serveur de production : Scaleway Dedibox Start-2-L, Xeon D-1531 (6 cœurs, 12 fils), 32 Go de RAM, OpenStack Kolla 2025.2 tout-en-un. Script : openstack/tests/capacite.py ; données brutes sur le serveur : /root/capacite-20261009/ (hote.csv toutes les 2 s, demarrage.csv, resume.json).

Capacité retenue : 22 VM eleve.petit en même temps

Sessions d'élèves et stock chaud compris. Choisie par Adam d'après les mesures ci-dessous. Elle est appliquée à deux endroits, à garder alignés :

Où	Réglage
Nova (refus au-delà, propre : « No valid host » → session en échec visible du prof)	reserved_host_memory_mb = 15000 dans kolla/config/nova/nova-compute.conf → Placement : (31993 − 15000) Mo / 768 Mo = 22 VM
Portail (plafond du stock chaud)	LABS_CAPACITE_VM, défaut 22 (portail/config/labs.php)
Quota du projet (filet de sécurité, au-dessus)	40 instances, 40 vCPU, 30 Go (rôle openstack-projet)

Ce que ça permet : une classe de 22 sur un lab à 1 VM ; 7 élèves sur le lab 08 (3 VM chacun). Moins le stock en attente (1 stack par lab hors séance).

Mesures

Mémoire

Situation	Mémoire disponible sur l'hôte
Sans VM (Kolla, portail, supervision)	≈ 16,5 Go (Kolla seul occupe ≈ 15,5 Go)
3 VM du stock au repos	15,1 Go
+ 20 VM démarrées, au repos	10,1 Go → ≈ 250 Mo par VM (RSS moyen 269 Mo)
+ 350 Mo occupés dans chacune des 20 VM	3,4 Go → +332 Mo par VM, soit ≈ 600 Mo par VM active ; swap utilisé : 264 Mo

Coût d'une VM eleve.petit (768 Mo) sur l'hôte :

Usage	Coût réel	VM possibles (16,3 Go − 2 Go de marge)
Au repos	≈ 250 Mo	≈ 57
Élève actif (mesuré ci-dessus)	≈ 600 Mo	≈ 23
Pire cas (VM pleine + QEMU)	≈ 870 Mo	≈ 16

À 22 VM, si toutes remplissaient entièrement leur mémoire en même temps (cas improbable dans un lab réseau ou système), l'hôte dépasserait sa mémoire d'environ 2 Go et puiserait dans le swap (4 Go) : ralentissement plutôt que panne. Le test n'a pas cherché à le provoquer.

Démarrage de 20 VM lancées en même temps

20 sur 20, aucune erreur.

	min	médiane	p95	max
Passage à ACTIVE	23,7 s	48,8 s	67,6 s	71,1 s
Système démarré (agent invité qui répond)	27,8 s	53,2 s	74,7 s	78,2 s

Pendant la rafale : CPU de l'hôte jusqu'à 86 %. D'où l'intérêt du stock chaud et du pré-remplissage 10 minutes avant une séance : une classe entière qui démarre à froid attendrait plus d'une minute.

CPU

20 VM avec un cœur à 100 % chacune pendant 60 s (20 vCPU pour 12 fils) : CPU de l'hôte à 89 % en moyenne, charge 14,5 au maximum. Une commande de correction par l'agent invité répond tout de même en 0,6 s. Le CPU n'est pas la limite : la mémoire l'est. (Ratio par défaut de Nova : 4 vCPU par fil, soit 48 vCPU.)

Ouverture d'un lab pris dans le stock (critère < 5 s)

Mesurée de bout en bout par https://syllabuslab.fr comme un navigateur (portail/tests/Reels/parcours-lab.py) : 2,80 s, 2,85 s, 2,85 s.

Décomposition (portail/tests/Reels/decomposer-ouverture.py) :

Morceau	Durée
La page élève voit l'état « actif » (interrogation chaque seconde)	0 à 1 s
Rechargement de la page	0,03 s
Jetons des consoles (appel Nova remote-consoles, ≈ 1,1 s chacun, demandés en parallèle)	1,1 s
WebSocket jusqu'à l'invite login:	1,0 s

Le poste le plus coûteux est l'appel Nova pour obtenir l'adresse de la console : piste d'optimisation si besoin (préparer ces jetons à l'attribution plutôt qu'à l'affichage).

Quand refaire ces mesures

Après une montée de version de Kolla, un changement d'image ou de gabarit, l'ajout d'un service lourd, ou un changement de serveur. Commande :

sudo python3 /root/capacite.py --vm 20 --sortie /root/capacite-AAAAMMJJ

Le script s'arrête de lui-même si la mémoire disponible passe sous 3 Go. Il crée un réseau capacite-test et des VM capacite-N à supprimer ensuite.