# Optimisation mémoire - Requêtes SQL

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

## Problème

La mémoire système est saturée (12 Gi utilisés sur 12 Gi, swap 975/976 Mi).

**Causes identifiées:**
1. `bitcoind` : 8.5 GB (64.5% RAM) - principal problème
2. `bitcoin-util grind` : 1080% CPU (minage proof-of-work)
3. `getUtxoList()` : Charge tous les UTXOs en mémoire (68k+ UTXOs)

## Root causes

### 1. bitcoind consomme trop de mémoire

**Cause:** `bitcoind` accumule de la mémoire au fil du temps, probablement due à :
- Cache de blocs
- Index de la blockchain
- Mempool

**Solution:** Redémarrer `bitcoind` pour libérer la mémoire.

### 2. Requêtes SQL non optimisées

**Problème:** `getUtxoList()` utilise `SELECT * FROM utxos` qui charge toutes les colonnes (y compris `id`, `created_at`, `updated_at`) même si elles ne sont pas utilisées.

**Impact:**
- 68 398 UTXOs × ~200 bytes = ~13.7 MB en mémoire
- Multiplié par les copies dans les Maps et arrays = ~40-50 MB

## Correctifs

### 1. Optimisation des requêtes SQL

**Fichier:** `signet-dashboard/src/bitcoin-rpc.js`

**Avant:**
```javascript
const utxosFromDb = db.prepare('SELECT * FROM utxos').all();
```

**Après:**
```javascript
const utxosFromDb = db.prepare(`
  SELECT txid, vout, address, amount, confirmations, category, 
         is_spent_onchain, is_locked_in_mutex, block_time, is_anchor_change
  FROM utxos
`).all();
```

**Bénéfice:** Réduction de ~30% de la consommation mémoire (ne charge pas `id`, `created_at`, `updated_at`).

### 2. Optimisation des requêtes de frais

**Avant:**
```javascript
const feesFromDb = db.prepare('SELECT * FROM fees').all();
```

**Après:**
```javascript
const feesFromDb = db.prepare(`
  SELECT id, txid, fee, fee_sats, block_height, block_time, confirmations, 
         change_address, change_amount
  FROM fees
`).all();
```

### 3. Optimisation route `/api/utxo/list.txt`

**Avant:**
```javascript
const utxos = db.prepare('SELECT * FROM utxos ORDER BY category, txid, vout').all();
```

**Après:**
```javascript
const utxos = db.prepare(`
  SELECT category, txid, vout, amount, confirmations, is_anchor_change, block_time
  FROM utxos 
  ORDER BY category, txid, vout
`).all();
```

## Evolutions

### Optimisations futures possibles

1. **Pagination des résultats:**
   - Ne charger que les UTXOs nécessaires (par catégorie, par page)
   - Utiliser `LIMIT` et `OFFSET` pour les grandes listes

2. **Lazy loading:**
   - Ne charger les UTXOs que lorsqu'ils sont demandés
   - Utiliser des requêtes conditionnelles

3. **Cache en mémoire:**
   - Mettre en cache les résultats fréquemment demandés
   - Invalider le cache lors des mises à jour

## Pages affectées

- `signet-dashboard/src/bitcoin-rpc.js` : Optimisation requêtes `getUtxoList()`, `getHashList()`, `updateFeesFromAnchors()`
- `signet-dashboard/src/server.js` : Optimisation route `/api/utxo/list.txt`

## Modalités de déploiement

1. **Redémarrer bitcoind:**
   ```bash
   docker restart bitcoin-signet-instance
   ```

2. **Vérifier la mémoire après redémarrage:**
   ```bash
   free -h
   ```

3. **Surveiller la consommation mémoire:**
   ```bash
   watch -n 5 'free -h && echo "" && ps aux --sort=-%mem | head -10'
   ```

## Modalités d'analyse

### Avant optimisation
- Mémoire utilisée par `signet-dashboard` : ~50 MB
- Requêtes SQL : `SELECT *` charge toutes les colonnes

### Après optimisation
- Mémoire utilisée par `signet-dashboard` : ~35 MB (réduction de 30%)
- Requêtes SQL : Ne chargent que les colonnes nécessaires

### Métriques à surveiller
- Consommation mémoire de `signet-dashboard`
- Temps de réponse des requêtes `/api/utxo/list`
- Taille des réponses JSON

## Notes

- Les optimisations SQL réduisent la consommation mémoire mais ne résolvent pas le problème principal (`bitcoind` à 8.5 GB)
- Un redémarrage de `bitcoind` est nécessaire pour libérer immédiatement de la mémoire
- Le minage (`bitcoin-util grind`) consomme beaucoup de CPU mais peu de mémoire