Utilisation des Ressources

Le conteneur Docker Apprise API utilise-t-il plus de RAM ou de mémoire que prévu ? Le tableau ci-dessous associe votre niveau d’utilisation aux réglages adaptés. Pour la plupart des déploiements personnels et hobbyistes, quelques variables d’environnement suffisent.

Référence rapide

Profil	Notifications quotidiennes	APPRISE_WORKER_COUNT	APPRISE_WORKER_MAX_REQUESTS	RAM attendue
Hobbyiste	1 – 50	1	50	~150–180 MB
Léger	51 – 500	1	200	~180–220 MB
Moyen	501 – 5,000	2	500	~330–400 MB
Lourd	5,001 – 20,000	3–4	1000 (par défaut)	~500–700 MB
Très élevé	20,000+	(auto)	1000 (par défaut)	variable

Hobbyiste / serveur perso

APPRISE_WORKER_COUNT=1 avec APPRISE_WORKER_MAX_REQUESTS=50 permet de garder une consommation mémoire faible. ~150–180 MB est le minimum réaliste pour cette pile : c’est le coût fixe d’exécution de Python, Django et de la suite complète de plugins Apprise, et ce plancher ne peut pas être réduit davantage par du simple tuning.

Appliquer ces réglages

Voici un exemple de la manière dont vous pouvez appliquer ces paramètres à votre déploiement. Choisissez l’onglet correspondant à votre configuration.

Docker

docker run --name apprise \
  -e APPRISE_WORKER_COUNT=1 \
  -e APPRISE_WORKER_MAX_REQUESTS=50 \
  -p 8000:8000 \
  -v ./config:/config \
  -d caronc/apprise:latest

Docker Compose

services:
  apprise:
    image: caronc/apprise:latest
    environment:
      APPRISE_WORKER_COUNT: 1
      APPRISE_WORKER_MAX_REQUESTS: 50
    ports:
      - "8000:8000"
    volumes:
      - ./config:/config

Pour plafonner la RAM du conteneur et éviter une croissance sans borne, ajoutez une limite mémoire :

mem_limit: 256m # plancher sûr pour un déploiement à 1 worker

Attention

Si le conteneur atteint sa limite mémoire, Docker le terminera avec une erreur d’out-of-memory (OOM). 256 MB constitue un plancher sûr pour les déploiements à un seul worker ; 384 MB offre une marge plus confortable.

Pourquoi ~150 MB est le minimum ?

Le conteneur exécute toujours trois processus, quels que soient les réglages :

Processus	RAM	Notes
Nginx	~25 MB	Reverse proxy
Supervisord	~10 MB	Gestionnaire de processus
Gunicorn worker	~115–145 MB	Python + Django + tous les plugins Apprise

Le worker est le principal poste de dépense. Apprise charge les 137 services de notification au démarrage même ceux que vous n’utiliserez jamais. C’est ce qui crée ce socle fixe. Le cœur Python, Django et l’infrastructure de services sont toujours chargés ; en revanche, certaines bibliothèques tierces optionnelles utilisées uniquement par des services spécifiques peuvent être évincées au démarrage si ces services sont désactivés (voir Réduire davantage la mémoire avec le filtrage de services).

Le nombre de workers par défaut vaut (2 × nombre de cœurs CPU) + 1. Sur une machine à 2 cœurs, cela fait 5 workers, ce qui peut pousser l’utilisation mémoire à 700 MB ou plus avant même l’envoi d’une seule notification. Réduire à APPRISE_WORKER_COUNT=1 est le levier le plus efficace.

Pourquoi la mémoire augmente-t-elle avec le temps ?

L’allocateur interne de Python conserve une partie de la mémoire libérée au lieu de la rendre immédiatement au système d’exploitation. C’est normal, pas forcément une fuite. La mémoire n’est complètement relâchée que lorsqu’un worker redémarre.

APPRISE_WORKER_MAX_REQUESTS contrôle combien de requêtes un worker traite avant de redémarrer. Avec la valeur par défaut 1000 et seulement quelques notifications par jour, les workers peuvent rester actifs pendant des mois sans recyclage. Définir une valeur plus basse (par exemple 50) garantit des redémarrages périodiques qui maintiennent la mémoire plus proche du niveau initial.

Avancé : Jitter

APPRISE_WORKER_MAX_REQUESTS_JITTER ajoute un décalage aléatoire au seuil de redémarrage de chaque worker afin d’éviter qu’ils se recyclent tous en même temps.

• Déploiements à un seul worker : le jitter n’a pas d’effet. La valeur par défaut 50 est sans danger, ou vous pouvez la fixer à 0.
• Déploiements à plusieurs workers : laissez le jitter à sa valeur par défaut 50, ou réduisez-le proportionnellement si vous baissez fortement APPRISE_WORKER_MAX_REQUESTS (par ex. MAX_REQUESTS=50 → JITTER=10).

Le jitter n’affecte pas l’usage mémoire ; seuls APPRISE_WORKER_COUNT et APPRISE_WORKER_MAX_REQUESTS ont un impact direct.

Variables d’environnement liées

Variable	Défaut	Description
APPRISE_WORKER_COUNT	(2×CPUs) + 1	Nombre de workers Gunicorn. Réglez à 1 pour les déploiements à faibles ressources.
APPRISE_WORKER_MAX_REQUESTS	1000	Nombre de requêtes avant redémarrage d’un worker et libération de la mémoire accumulée.
APPRISE_WORKER_MAX_REQUESTS_JITTER	50	Décalage aléatoire par worker pour étaler les redémarrages. Sans importance avec un seul worker.
APPRISE_WORKER_TIMEOUT	300	Timeout du worker en secondes.

Consultez la référence des variables d’environnement pour la liste complète.

Avancé : réduire davantage la mémoire avec le filtrage de services

Si vous n’utilisez qu’un petit ensemble de services de notification, vous pouvez récupérer encore un peu de mémoire en indiquant à l’API quels services vous utilisez réellement. L’API Apprise évincera alors au démarrage les bibliothèques optionnelles utilisées exclusivement par les plugins désactivés.

APPRISE_ALLOW_SERVICES=tgram,ntfy

Les bibliothèques dont plus aucun plugin activé n’a besoin sont automatiquement supprimées du cache de modules Python (sys.modules). Les gains s’additionnent avec APPRISE_WORKER_COUNT=1 :

Bibliothèque	Utilisée Par	Mémoire Libérée
slixmpp	xmpp://	~20 MB
paho	mqtt://	~4 MB
gntp	growl://	~2 MB
smpplib	smpp://, smpps://	~2 MB
hid	blink1://	~2 MB
pgpy	mailto://, mailtos:// (PGP uniquement)	~10 MB
cryptography	simplepush://, fcm://, vapid://	partielle†

†cryptography s’appuie nativement sur OpenSSL. Les objets d’encapsulation Python sont libérés, mais la bibliothèque partagée sous-jacente reste chargée par le système d’exploitation pendant toute la durée de vie du processus.

Pour tous les détails sur le fonctionnement et des exemples de configuration, consultez Impact mémoire du filtrage de services.