anchorage_layer_simple/fixKnowledge/mempool-api-healthcheck-fix.md
ncantu 0960e43a45 Optimisation mémoire api-anchorage avec base de données SQLite
**Motivations:**
- Réduction drastique de la consommation mémoire lors des ancrages
- Élimination du chargement de 173k+ UTXOs à chaque requête
- Stabilisation de la mémoire système sous charge élevée (50+ ancrages/minute)

**Root causes:**
- api-anchorage chargeait tous les UTXOs (173k+) via listunspent RPC à chaque ancrage
- Filtrage et tri de 173k+ objets en mémoire pour sélectionner un seul UTXO
- Croissance mémoire de ~16 MB toutes les 12 secondes avec 50 ancrages/minute
- Saturation mémoire système en quelques minutes

**Correctifs:**
- Création du module database.js pour gérer la base de données SQLite partagée
- Remplacement de listunspent RPC par requête SQL directe avec LIMIT 1
- Sélection directe d'un UTXO depuis la DB au lieu de charger/filtrer 173k+ objets
- Marquage des UTXOs comme dépensés dans la DB après utilisation
- Fermeture propre de la base de données lors de l'arrêt

**Evolutions:**
- Utilisation de la base de données SQLite partagée avec signet-dashboard
- Réduction mémoire de 99.999% (173k+ objets → 1 objet par requête)
- Amélioration des performances (requête SQL indexée vs filtrage en mémoire)
- Optimisation mémoire de signet-dashboard (chargement UTXOs seulement si nécessaire)
- Monitoring de lockedUtxos dans api-anchorage pour détecter les fuites
- Nettoyage des intervalles frontend pour éviter les fuites mémoire

**Pages affectées:**
- api-anchorage/src/database.js (nouveau)
- api-anchorage/src/bitcoin-rpc.js
- api-anchorage/src/server.js
- api-anchorage/package.json
- signet-dashboard/src/bitcoin-rpc.js
- signet-dashboard/public/app.js
- features/optimisation-memoire-applications.md (nouveau)
- features/api-anchorage-optimisation-base-donnees.md (nouveau)
2026-01-27 21:12:22 +01:00

2.9 KiB

Fix: Mempool API Healthcheck - curl not found

Date: 2026-01-27 Auteur: Équipe 4NK

Problème

Le conteneur Docker mempool_api_1 était marqué comme "unhealthy" avec un FailingStreak de 2963 échecs consécutifs.

Symptômes

  • Statut Docker: unhealthy
  • Erreur répétée: /bin/sh: 1: curl: not found
  • Le healthcheck ne pouvait pas s'exécuter car curl n'est pas installé dans l'image mempool/backend:latest

Impact

  • Le conteneur fonctionnait normalement (les logs montraient une synchronisation correcte des index Bitcoin)
  • Le statut "unhealthy" générait des alertes et masquait l'état réel du service
  • Pas d'impact fonctionnel direct, mais confusion sur l'état réel du service

Root cause

Le healthcheck dans docker-compose.signet.yml utilisait la commande curl qui n'est pas disponible dans l'image Docker mempool/backend:latest. L'image ne contient que les dépendances minimales nécessaires au backend Node.js.

Correctifs

Modification du healthcheck

Fichier modifié: mempool/docker-compose.signet.yml

Avant:

healthcheck:
  test: ["CMD-SHELL", "curl -f http://localhost:8999/api/v1/backend-info | grep -q . || exit 1"]

Après:

healthcheck:
  test: ["CMD-SHELL", "node -e \"require('http').get('http://localhost:8999/api/v1/backend-info', (r) => { process.exit(r.statusCode === 200 ? 0 : 1); }).on('error', () => process.exit(1));\""]

Justification

  • node est disponible dans l'image (backend Node.js)
  • Utilisation de l'API HTTP native de Node.js au lieu de curl
  • Même logique de vérification: requête HTTP vers /api/v1/backend-info avec vérification du code de statut 200

Modifications

  • mempool/docker-compose.signet.yml: Modification du healthcheck du service api

Modalités de déploiement

  1. Modifier le fichier docker-compose.signet.yml
  2. Recréer le conteneur pour appliquer la nouvelle configuration:
    cd /srv/4NK/mempool1.4nkweb.com
    docker-compose -f docker-compose.signet.yml up -d --force-recreate api
    
  3. Vérifier que le healthcheck passe à "healthy" après le délai de démarrage (40s)

Modalités d'analyse

Vérification du statut

docker inspect mempool_api_1 --format='{{.State.Health.Status}}'

Vérification des logs du healthcheck

docker inspect mempool_api_1 --format='{{json .State.Health}}' | python3 -m json.tool

Test manuel du healthcheck

docker exec mempool_api_1 node -e "require('http').get('http://localhost:8999/api/v1/backend-info', (r) => { console.log('Status:', r.statusCode); process.exit(r.statusCode === 200 ? 0 : 1); }).on('error', (e) => { console.error('Error:', e.message); process.exit(1); });"

Résultat

  • Le conteneur mempool_api_1 est maintenant marqué comme "healthy"
  • Le healthcheck fonctionne correctement avec Node.js
  • Aucun impact sur le fonctionnement du service