perf : forks=20 et creation des VM en parallele
Choisis sur le chronometrage d'une reconstruction complete (1 h 12 min 48 s, phase par phase), pas sur l'intuition. FORKS ETAIT AU DEFAUT (5) POUR 14 HOTES. Chaque play qui balaie la flotte — socle, durcissement, enrolement PKI, les cinq agents — tournait en TROIS vagues. Les gros roles n'en profitent pas : Nextcloud (10 min 55 s), Forgejo, Grafana et Keycloak sont sur UN hote. Ce sont les couches larges qui payaient. forks = 20 laisse de la marge au-dela des 14 actuels ; chaque fork est un processus sur le controleur, pas sur les cibles. LA CREATION DES VM SE FAISAIT UNE PAR UNE : 14 x 1 min 35 s = 22 min 08 s, 30 % du total, et surtout de l'ATTENTE (clone, demarrage, SSH, verrou dpkg) sans le moindre recouvrement. flotte-creer en lance quatre a la fois, ajustable par PARALLELE=n. La sortie de chaque hote va dans SON fichier, recopiee ordonnee a la fin : quatre clones ecrivant en meme temps donneraient un journal illisible, ce qui serait un comble apres une journee a traquer des diagnostics masques. Le marqueur `=== Creation VM: <hote> ===` reste emis en direct. Et un echec n'est pas avale : le code de retour de chaque hote est relu, et la cible sort en erreur si l'un a echoue — sinon _attendre-flotte partirait sur une flotte incomplete. Gains ESTIMES, a verifier par la prochaine mesure : ~15 min sur les clones, ~5 min sur les couches larges. Le troisieme levier identifie — l'archive Nextcloud en .tar.bz2, decompressee sur un seul coeur — attend d'etre mesure. Verifie : ansible-config confirme forks=20, make -n passe, prouver.py 35 OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
19871894ed
commit
d0b0e80b55
3 changed files with 76 additions and 2 deletions
35
CHANGELOG.md
35
CHANGELOG.md
|
|
@ -1,5 +1,40 @@
|
|||
# CHANGELOG — Set-OPS
|
||||
|
||||
## 2026-08-10 — Deux optimisations, choisies sur la mesure et non sur l'intuition
|
||||
|
||||
Le chronométrage d'une reconstruction complète (`1 h 12 min 48 s`, phase par phase) a
|
||||
désigné où part le temps. Deux leviers, pris dans l'ordre du gain mesuré.
|
||||
|
||||
### `forks = 20` — les plays multi-hôtes tournaient en trois vagues
|
||||
|
||||
`ansible.cfg` ne déclarait pas `forks` : **défaut 5**, pour **14 hôtes**. Chaque couche qui
|
||||
balaie la flotte — socle, durcissement, enrôlement PKI, les cinq agents — s'exécutait donc
|
||||
en trois vagues successives.
|
||||
|
||||
Les gros rôles n'en profitent pas : Nextcloud (10 min 55 s), Forgejo, Grafana et Keycloak
|
||||
sont sur **un seul** hôte. C'est bien les couches larges qui payaient.
|
||||
|
||||
### La création des VM se faisait une par une
|
||||
|
||||
14 clones × 1 min 35 s = **22 min 08 s**, soit **30 %** d'une reconstruction — et ce temps
|
||||
est surtout de l'**attente** : clone, démarrage, SSH, verrou `dpkg`, quatorze fois sans
|
||||
recouvrement. `flotte-creer` en lance désormais **quatre à la fois** (`PARALLELE=n` pour
|
||||
ajuster).
|
||||
|
||||
**La sortie de chaque hôte va dans son propre fichier**, recopiée en bloc à la fin. Quatre
|
||||
clones écrivant simultanément sur la même sortie donneraient un journal illisible — un
|
||||
comble après une journée passée à traquer des diagnostics masqués. Le marqueur
|
||||
`=== Creation VM: <hôte> ===` reste émis en direct pour suivre l'avancement ; le détail
|
||||
arrive ordonné.
|
||||
|
||||
**Et un échec n'est pas avalé** : le code de retour de chaque hôte est relu, et la cible sort
|
||||
en erreur si l'un d'eux a échoué — sinon `_attendre-flotte` partirait sur une flotte
|
||||
incomplète.
|
||||
|
||||
**Gains estimés, à vérifier par la prochaine mesure** : ~15 min sur les clones, ~5 min sur
|
||||
les couches larges. Le troisième levier identifié — l'archive Nextcloud en `.tar.bz2`,
|
||||
décompressée sur un seul cœur — est laissé de côté tant qu'il n'est pas mesuré.
|
||||
|
||||
## 2026-08-10 — Le jeton Keycloak vivait 60 s, et Grafana rendait son échec illisible
|
||||
|
||||
Technolibre remonté depuis zéro une seconde fois — `14 hôtes · 2 588 tâches ok · 0 failed`.
|
||||
|
|
|
|||
34
Makefile
34
Makefile
|
|
@ -568,7 +568,22 @@ deployer-tout: _instance-requise ## Deploie TOUTE la flotte dans l'ordre des cou
|
|||
# --- Reconstruction from-zero : creer TOUTES les VM (2a) puis deployer (2b) ---
|
||||
|
||||
.PHONY: flotte-creer
|
||||
flotte-creer: _instance-requise ## Cree les VM manquantes de la flotte depuis le plan
|
||||
# CREATION EN PARALLELE, `PARALLELE=n` pour ajuster (defaut 4).
|
||||
#
|
||||
# Mesure du 2026-08-10 : 14 VM creees une par une, 1 min 35 s chacune, 22 min 08 s au
|
||||
# total — soit 30 % d'une reconstruction complete. Et ce temps est surtout de l'ATTENTE :
|
||||
# clone, demarrage, SSH, verrou dpkg. Quatorze fois de suite, sans recouvrement.
|
||||
#
|
||||
# LA SORTIE DE CHAQUE HOTE VA DANS SON PROPRE FICHIER, recopiee en bloc a la fin. Quatre
|
||||
# clones ecrivant en meme temps sur la meme sortie donneraient un journal illisible — et
|
||||
# apres une journee passee a traquer des diagnostics masques, ce serait un comble. On
|
||||
# garde donc le marqueur `=== Creation VM: <hote> ===` en direct pour suivre l'avancement,
|
||||
# et le detail arrive ordonne.
|
||||
#
|
||||
# Un echec n'est pas avale : le code de retour de chaque hote est relu, et la cible sort
|
||||
# en erreur si l'un d'eux a echoue — sinon `_attendre-flotte` partirait sur une flotte
|
||||
# incomplete.
|
||||
flotte-creer: _instance-requise ## Cree les VM manquantes de la flotte depuis le plan — PARALLELE=n
|
||||
@set -e; \
|
||||
if [[ "$(CONFIRMER)" != "true" ]]; then \
|
||||
printf '%s\n' 'Refus: creation de TOUTES les VM actives du plan (clone Proxmox).'; \
|
||||
|
|
@ -577,10 +592,25 @@ flotte-creer: _instance-requise ## Cree les VM manquantes de la flotte depuis le
|
|||
fi; \
|
||||
hotes="$$(python3 scripts/inventory_host.py --inventaire $(INVENTAIRE_PRODUCTION) lister-actifs)"; \
|
||||
if [[ -z "$$hotes" ]]; then printf '%s\n' 'Refus: aucun hote actif dans le plan.'; exit 2; fi; \
|
||||
par="$(PARALLELE)"; par="$${par:-4}"; \
|
||||
tmp="$$(mktemp -d)"; trap 'rm -rf "$$tmp"' EXIT; \
|
||||
printf 'Creation de %s VM, %s a la fois.\n' "$$(echo $$hotes | wc -w)" "$$par"; \
|
||||
n=0; \
|
||||
for h in $$hotes; do \
|
||||
printf '\n=== Creation VM: %s ===\n' "$$h"; \
|
||||
$(MAKE) creer-vm HOTE="$$h"; \
|
||||
( $(MAKE) creer-vm HOTE="$$h" > "$$tmp/$$h.log" 2>&1; printf '%s' "$$?" > "$$tmp/$$h.rc" ) & \
|
||||
n=$$((n+1)); \
|
||||
if (( n >= par )); then wait -n || true; n=$$((n-1)); fi; \
|
||||
done; \
|
||||
wait; \
|
||||
echec=0; \
|
||||
for h in $$hotes; do \
|
||||
printf '\n----- journal de %s -----\n' "$$h"; \
|
||||
cat "$$tmp/$$h.log" 2>/dev/null || printf '(aucune sortie)\n'; \
|
||||
rc="$$(cat "$$tmp/$$h.rc" 2>/dev/null || printf 1)"; \
|
||||
if [[ "$$rc" != 0 ]]; then printf '!! %s a ECHOUE (code %s)\n' "$$h" "$$rc"; echec=1; fi; \
|
||||
done; \
|
||||
if (( echec )); then printf '\nAu moins une VM n a pas ete creee — rien ne continue.\n'; exit 2; fi; \
|
||||
printf '\nToutes les VM actives sont creees.\n'
|
||||
|
||||
.PHONY: _attendre-flotte
|
||||
|
|
|
|||
|
|
@ -1,4 +1,13 @@
|
|||
[defaults]
|
||||
# 14 hotes contre 5 forks par defaut : chaque play multi-hote tournait en TROIS vagues.
|
||||
# Mesure du 2026-08-10 sur une reconstruction complete — les couches qui balaient toute
|
||||
# la flotte (socle, durcissement, enrolement PKI, les cinq agents) en portaient le cout,
|
||||
# pendant que les gros roles (Nextcloud, Forgejo, Grafana, Keycloak) ne sont que sur UN
|
||||
# hote et n'en profitent pas.
|
||||
#
|
||||
# 20 laisse de la marge au-dela des 14 actuels sans devenir absurde : chaque fork est un
|
||||
# processus Python sur le controleur, pas sur les cibles.
|
||||
forks = 20
|
||||
inventory = instance/inventories/lab/hosts.yml
|
||||
roles_path = roles
|
||||
filter_plugins = filter_plugins
|
||||
|
|
|
|||
Loading…
Reference in a new issue