Test : load-test/soak.js
Durée : 58 minutes (5 min montée + 48 min plateau + 5 min descente)
VUs : 30 (21 casual / 6 active / 3 power — répartition 70/20/10)
Résultat k6 : dépassement de seuil (exit 99)
Le test s’est exécuté jusqu’au bout. Le dépassement de seuil est le même artefact que le Test 3
(todos-realistic.js) : le seuil de lecture p(95)<300ms est structurellement inatteignable
depuis la zone de charge US de Grafana vers le VPS de Francfort (~130 ms de RTT de référence).
C’est un problème de géographie réseau, pas de dégradation serveur. Aucune erreur 5xx n’a été
observée dans les logs des services.
Mémoire VPS : service par service (échantillons cron toutes les 5 min)
| Service | Début | Fin | Delta | Limite | % en fin |
|---|---|---|---|---|---|
| project1_kong | 221 MB | 244 MB | +23 MB | 512 MB | 47,7% |
| project1_realtime | 165 MB | 165 MB | 0 MB | 512 MB | 32,3% |
| project1_db | 76 MB | 75 MB | -1 MB | 1024 MB | 7,4% |
| project1_meta | 70 MB | 69 MB | -1 MB | 256 MB | 27,2% |
| project1_rest | 16 MB | 16 MB | 0 MB | 256 MB | 6,5% |
| project1_auth | 12 MB | 13 MB | +1 MB | 256 MB | 5,3% |
| project1_storage | 57 MB | 57 MB | 0 MB | 256 MB | 22,5% |
| project1_studio | 148 MB | 147 MB | -1 MB | 512 MB | 28,7% |
RAM hôte VPS : oscillation entre 2166 et 2272 MB utilisés sur 3819 MB au total. Aucune croissance soutenue.
Constat principal : croissance mémoire de Kong
Kong (project1) a augmenté régulièrement de 221 MB → 244 MB (+23 MB, +10,4%) sur 60 minutes.
Progression détaillée :
| Intervalle | Kong mem (MB) | Δ depuis le début |
|---|---|---|
| 0 min (référence) | 221 | — |
| 5 min | 223 | +2 |
| 10 min | 224 | +3 |
| 15 min | 225 | +4 |
| 20 min | 226 | +5 |
| 25 min | 228 | +7 |
| 30 min | 229 | +8 |
| 35 min | 232 | +11 |
| 40 min | 234 | +13 |
| 45 min | 237 | +16 |
| 50 min | 240 | +19 |
| 55 min | 242 | +21 |
| 60 min | 244 | +23 |
Rythme : ~2 MB par intervalle de 5 minutes = ~24 MB/heure sous charge.
A ce rythme : la limite de 512 MB serait atteinte en ~12 heures de charge continue. Kong au repos tourne autour de ~221 MB (référence avant le test) ; la mémoire est revenue dans cette plage après le redémarrage de Kong effectué en fin de test pour restaurer le rate limit. La croissance semble liée à la mémoire partagée Lua de nginx dans Kong, qui accumule les compteurs de rate limiting (relevé à 10000/min pour le test), l’état des connexions actives ou les données de santé des upstreams — le tout est purgé au redémarrage.
Verdict : la croissance mémoire de Kong est réelle mais lente. Sous une charge réaliste (sans rate limit à 10000/min), l’accumulation des compteurs serait bien moindre. Aucun risque d’OOM pour une journée de travail classique de 8 heures. Envisager un suivi sur 24h+ en production pour établir une référence sur une durée plus longue.
Pics CPU de Kong
Les conteneurs Kong de project1 et project2 ont affiché des lectures CPU élevées à partir de 11h20 (12–17% sur échantillon ponctuel) :
| Intervalle | p1_kong CPU | p2_kong CPU |
|---|---|---|
| 0 min | 0,04% | 0,04% |
| 15 min | 14,1% | 0,04% |
| 35 min | 2,7% | 3,2% |
| 40 min | 14,3% | 17,4% |
| 45 min | 14,5% | 14,2% |
| 50 min | 14,2% | 16,0% |
| 55 min | 16,9% | 14,7% |
| 60 min | 12,6% | 12,6% |
Project2 n’était pas sous charge pendant le test, mais affiche le même profil CPU. Cela
exclut le trafic comme cause. L’explication la plus probable : le snapshot docker stats --no-stream
de 5 secondes capture le worker nginx de Kong au moment d’un health check Lua ou d’un
timer callback (les health checks de Kong se déclenchent toutes les ~10 s). C’est le même
schéma que le bruit des règles Falco lié aux health checks de Kong. Le CPU est en rafales
mais les pics sont courts.
Aucune fuite mémoire détectée
Tous les services suspectés sont restés stables :
- Realtime (BEAM VM) : bloqué à 165 MB tout au long du test — aucune fuite
- PostgREST : bloqué à 16 MB — aucune fuite
- Postgres DB : 75–81 MB, légères fluctuations sans tendance — aucune fuite
- GoTrue (auth) : 11–13 MB — aucune fuite
La préoccupation principale en amont de ce test (croissance de la BEAM VM de Realtime sous charge soutenue) ne s’est pas concrétisée.
État des services après le test
Les 8 services de project1 à 1/1 réplicas après la fin du test. Zéro redémarrage.
project1_auth 1/1
project1_db 1/1
project1_kong 1/1
project1_meta 1/1
project1_realtime 1/1
project1_rest 1/1
project1_storage 1/1
project1_studio 1/1
Synthèse
| Question | Réponse |
|---|---|
| Fuites mémoire dans Realtime ? | Non — stable à 165 MB |
| Fuites mémoire dans la DB ? | Non — stable à 75–81 MB |
| Fuites mémoire dans Kong ? | Croissance lente (~24 MB/h sous charge) — pas de risque OOM sous 12h |
| Épuisement du pool de connexions DB ? | Non — le CPU de la DB n’a jamais dépassé 0,71% |
| Taux d’erreur pendant le test ? | 0% (le dépassement de seuil ne concerne que la latence, identique au Test 3) |
| Pression RAM sur le VPS ? | Non — l’hôte a utilisé 2,1–2,3 GB sur 3,8 GB tout au long du test |
| Redémarrages ou OOM de services ? | Aucun |
| Upgrade CX32 nécessaire ? | Non — le cluster gère confortablement une charge réaliste soutenue |
Décision d’upgrade CX32 : reportée indéfiniment. Le CX22 encaisse 30 VUs de charge réaliste soutenue avec de la marge. A réévaluer si le nombre d’utilisateurs simultanés dépasse 50 ou si un troisième projet est ajouté.
Actions à mener
- Surveiller la mémoire de Kong sur une fenêtre de 24h en production au repos pour distinguer la croissance liée à la charge de l’accumulation en arrière-plan
- Envisager l’ajout de la mémoire de Kong à une alerte cron hebdomadaire (ex. notification si >400 MB)
- Ajuster le seuil de lecture p(95)<300ms dans soak.js à p(95)<500ms, ou basculer sur une zone de charge européenne, pour éviter les faux dépassements de seuil liés à la latence US→DE