perf(ram) : plafond de tas Node — 197 Mo de RSS pour un addon qui n'en a pas besoin #39
No reviewers
Labels
No labels
montee-majeure
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
foXaCe/UltraMax!39
Loading…
Reference in a new issue
No description provided.
Delete branch "passe-20261018-164000-plafond-tas"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[M]Mesuré le 2026-10-18 sur le LXC 112 :ultramaxtenait 197 Mo de RSS pour un service quisert des catalogues, sans aucun réglage de tas. Node 24 prend le défaut du système (≈2 Go sur ce
conteneur) et le tas monte à ce que l'application alloue, pas à ce dont elle a besoin.
Le plafond ne coupe rien : il force le ramasse-miettes à travailler avant que le tas ne gonfle.
La mesure, avant/après, sur le service vivant
⚠ Ce qui prouve que le service vit encore
Le port publié est 7002 (
PORT=7002dans.env), pas 7000 : 7000 est le port interne.Pourquoi 128 Mo, et pas moins
Le tas observé tournait autour de 120–150 Mo avant le plafond. Descendre plus bas ferait
travailler le GC pour rien et rapprocherait du
out of memorysur une bibliothèque chaude. 128laisse de la marge sous le pic observé tout en supprimant le gonflement.
⚠ Ce chiffre se remesure si les catalogues grossissent : un plafond qu'on ne relit pas devient un
plafond qui coupe. La même passe a mesuré que le total du conteneur n'était pas une fuite —
882→893 Mo sur cinq minutes, plat, avant tout réglage.
Ce que cette PR ne fait pas
Elle ne touche pas
aiostreams(déjà réglé :--max-semi-space-size=8), niwacustom(63 Mo, trèsactif), ni la plomberie Docker (130 Mo, incompressible à quatre conteneurs).
`[M]` Mesuré le 2026-10-18 sur le LXC 112 : `ultramax` tenait **197 Mo** de RSS pour un service qui sert des catalogues, sans aucun réglage de tas. Node 24 prend le défaut du système (≈2 Go sur ce conteneur) et le tas monte à ce que l'application ALLOUE, pas à ce dont elle a besoin. Le plafond ne coupe rien : il force le ramasse-miettes à travailler avant que le tas ne gonfle. NODE_OPTIONS=--max-old-space-size=128 ## La mesure, avant/après, sur le service vivant ``` RSS avant : 197 156 Ko RSS après 45 s : 135 156 Ko RSS sur 4 min : 138 828 · 158 080 · 99 356 · 99 356 Ko (le GC travaille) total du LXC 112 : 897 Mo → 782 Mo ``` ⚠ **CE QUI PROUVE QUE LE SERVICE VIT ENCORE** : ``` $ curl -o /dev/null -w "%{http_code} %{size_download}" http://127.0.0.1:7002/manifest.json 200 64671 journal : « Ultra MAX v8.0.0 running on port 7000 » · « Total catalog defs: 570 » « [home-rows-warm] 9/9 page(s) posée(s) » · 0 erreur, 0 « out of memory » ``` ## Pourquoi 128 Mo, et pas moins Le tas observé tournait autour de 120–150 Mo avant le plafond. Descendre plus bas ferait travailler le GC pour rien et rapprocherait du `out of memory` sur une bibliothèque chaude. 128 laisse de la marge sous le pic observé tout en supprimant le gonflement. ⚠ Ce chiffre se **remesure** si les catalogues grossissent : un plafond qu'on ne relit pas devient un plafond qui coupe.