Quand la RAM de votre NAS Synology baisse jour après jour, la cause n’est pas toujours évidente. Dans beaucoup de cas, ce sont des conteneurs Docker qui finissent par devenir plus gourmands avec le temps. La bonne nouvelle : un redémarrage un conteneur Docker peut remettre d’aplomb votre système, et vous pouvez même automatiser l’opération.
Dans ce guide, je vous montre une méthode simple : repérer ce qui consomme le plus, confirmer au niveau projet/containeur, puis redémarrer manuellement ou planifier le redémarrage pour éviter la dérive.
1) Commencez par identifier le plus gros consommateur de RAM
Avant de redémarrer quoi que ce soit, il faut savoir qui consomme. Sur DSM, le point de départ le plus efficace reste le Moniteur de ressources.
Procédez ainsi :
- Ouvrez Moniteur de ressources depuis le menu principal.
- Allez dans Performances.
- Dans le menu de gauche, sélectionnez Gestionnaire des tâches.
- Ouvrez l’onglet Processus.
- Cliquez deux fois sur la colonne Mémoire privée pour trier par ordre décroissant.
Vous obtenez alors une vue claire : application native, paquet installé… ou conteneur Docker.

2) Confirmez au niveau Projet / Conteneur (Docker)
Une fois que vous avez repéré un acteur “suspect” dans le Moniteur de ressources, l’étape suivante consiste à confirmer précisément le conteneur responsable.
Tout dépend de votre déploiement :
Cas A : votre conteneur fait partie d’un projet
Si votre application Docker est organisée en projet (par exemple via Container Manager), vous pouvez vérifier la consommation directement au bon niveau.
- Ouvrez Container Manager.
- Dans le menu de gauche, allez sur Projets.
- Recherchez le projet concerné (ex. votre stack).
- Ouvrez le projet, puis allez dans l’onglet Statistiques.
- Par défaut, l’affichage est souvent sur CPU. Basculez sur RAM pour voir la consommation mémoire des conteneurs du projet.
Cas B : votre conteneur tourne “tout seul”
Si vous n’avez pas de notion de projet (conteneur isolé), le contrôle se fait directement sur l’objet conteneur.
- Dans Container Manager, allez dans Conteneur.
- Sélectionnez le conteneur concerné.
- Ouvrez l’onglet Statistiques pour vérifier la consommation mémoire.
À ce stade, vous savez exactement quel conteneur redémarrer.
3) Redémarrer un conteneur Docker manuellement (le plus simple)
Quand un conteneur devient trop gourmand, le redémarrage manuel est souvent la solution la plus rapide. Sur DSM, l’interface Container Manager permet de le faire en quelques clics.
Procédure :
- Dans Container Manager, ouvrez le menu Conteneur.
- Sélectionnez le conteneur concerné (ou faites un clic droit).
- Cliquez sur le bouton Action (en haut à droite).
- Choisissez Redémarrer.
Si vous préférez repartir sur l’ensemble d’une stack, vous pouvez aussi redémarrer un projet complet : ouvrez le projet, puis Action > Redémarrer.
Astuce : observez ensuite la RAM dans le Moniteur de ressources pour vérifier que le “pic” retombe.
4) Automatiser : planifier un redémarrage hebdomadaire
Si vous constatez une dérive régulière (par exemple “après quelques jours”), l’automatisation peut vous faire gagner du temps. L’idée : redémarrer un conteneur Docker une fois par semaine, à un moment où l’impact est minimal.
Mais il faut être prudent : un redémarrage peut interrompre un service (envoi de documents, lecture vidéo, etc.). Choisissez donc un horaire “creux”. L’exemple classique est 5h du matin.
Le chemin dans DSM
Pour créer la tâche planifiée :
- Allez dans Panneau de configuration > Planificateur de tâche.
- Cliquez sur Créer.
- Choisissez Tâche planifiée > Script défini par l’utilisateur.
- Donnez un nom personnalisé (sans caractères spéciaux ni accent).
- Choisissez root comme utilisateur.
- Dans l’onglet Programmer, configurez Répéter sur Toutes les semaines.
- Sélectionnez le jour souhaité.
Ensuite, vous ajoutez le script qui déclenche le redémarrage.
Anticipez les notifications
Un redémarrage programmé peut générer une notification d’arrêt dans DSM. Selon vos réglages, cela peut aussi déclencher des notifications par e-mail ou via l’application mobile. Autrement dit : vérifiez vos paramètres pour éviter d’être noyé de messages.
5) Bonnes pratiques pour éviter de “masquer” un vrai problème
Redémarrer un conteneur est une mesure de stabilisation. C’est utile, mais ça ne remplace pas une analyse si la RAM continue de grimper rapidement.
Voici comment garder une approche saine :
- Surveillez : observez la RAM après redémarrage et notez la durée avant la prochaine dérive.
- Vérifiez la stack : si votre application est composée de plusieurs conteneurs, identifiez celui qui “prend” la mémoire.
- Planifiez intelligemment : un redémarrage hebdomadaire à heure fixe limite l’impact utilisateur.
- Évitez de redémarrer “au hasard” : commencez toujours par trier par Mémoire privée dans le Moniteur de ressources.

Checklist rapide : la méthode en 5 minutes
Si vous voulez une procédure “terrain”, gardez cette checklist sous la main :
- Ouvrez Moniteur de ressources > Gestionnaire des tâches > Processus.
- Trier par Mémoire privée (ordre décroissant).
- Repérez le conteneur ou l’application suspecte.
- Confirmez dans Container Manager (Projet > Statistiques sur RAM, ou Conteneur > Statistiques).
- Redémarrez manuellement, puis observez l’effet. Si c’est récurrent, planifiez un redémarrage hebdomadaire.
Conclusion : stabiliser, puis comprendre
Quand un conteneur Docker devient gourmand en RAM sur Synology, redémarrer un conteneur Docker est souvent la solution la plus rapide pour retrouver de la marge. En combinant tri des processus, vérification dans Container Manager et planification, vous reprenez le contrôle sans subir la dérive.
Et si la consommation revient trop vite, utilisez ces mêmes étapes pour affiner : vous saurez exactement quel composant surveiller en priorité.
Source : https://www.cachem.fr/synology-redemarre-conteneur/