# 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 : 20 VM `eleve.petit` en même temps

Ramenée de 22 à 20 le 2026-10-12 pour la visio (Jitsi) : après une visio à
trois, Jitsi occupe ≈ 710 Mo (JVB 459, Jicofo 206, Prosody 28, web 16) ; JVB est
plafonné à 1 Go et Jicofo à 512 Mo, soit 1,5 Go réservés en plus
(`reserved_host_memory_mb` 15000 → 16500 ; (31993 − 16500) / 768 = 20).

### Historique : 22 VM (étape 13)

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 (20 VM) : une classe de 20 sur un lab à 1 VM ; 6 é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.