0960e43a45
**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)
89 lines
2.9 KiB
Markdown
89 lines
2.9 KiB
Markdown
# 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:**
|
|
```yaml
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "curl -f http://localhost:8999/api/v1/backend-info | grep -q . || exit 1"]
|
|
```
|
|
|
|
**Après:**
|
|
```yaml
|
|
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:
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
docker inspect mempool_api_1 --format='{{.State.Health.Status}}'
|
|
```
|
|
|
|
### Vérification des logs du healthcheck
|
|
|
|
```bash
|
|
docker inspect mempool_api_1 --format='{{json .State.Health}}' | python3 -m json.tool
|
|
```
|
|
|
|
### Test manuel du healthcheck
|
|
|
|
```bash
|
|
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
|