2026-10-09 20:12:11 +02:00
|
|
|
|
# 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`).
|
|
|
|
|
|
|
2026-10-12 12:35:35 +02:00
|
|
|
|
## 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)
|
2026-10-09 20:12:11 +02:00
|
|
|
|
|
|
|
|
|
|
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`) |
|
|
|
|
|
|
|
2026-10-12 12:35:35 +02:00
|
|
|
|
Ce que ça permet (20 VM) : une classe de 20 sur un lab à 1 VM ; 6 élèves sur le
|
2026-10-09 20:12:11 +02:00
|
|
|
|
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.
|