L’utilisation mémoire de Plex peut rester élevée après la fin d’une tâche, car Linux conserve un cache du système de fichiers réutilisable et les applications gardent de la mémoire allouée pour les tâches ultérieures.
Une mémoire « utilisée » élevée n’est pas automatiquement le signe d’une fuite. Comparez la mémoire résidente des processus, le cache récupérable, la pression sur le swap et la capacité de l’hôte à restituer de la mémoire lorsqu’une autre charge de travail en a besoin. N’effectuez des recherches que lorsque l’empreinte continue d’augmenter au fil de cycles répétés ou provoque une réelle pression et une instabilité.
Faites la distinction entre la mémoire des processus et le cache du système de fichiers
Linux utilise la mémoire vive autrement inactive pour mettre en cache les fichiers et les pages de base de données, ce qui peut faire paraître les valeurs de mémoire libre faibles après des analyses ou la lecture de contenus. Le cache récupérable est différent d’une croissance irrécupérable de l’application.
La mémoire vive utilisée seule est un mauvais indicateur de fuite, car le cache Linux par rapport à la mémoire de l’application peut rester élevé même lorsque la mémoire est toujours récupérable.
Relevez le RSS de Plex, le cache de l’hôte, la mémoire disponible et le swap avant et après la charge de travail. Si la mémoire disponible reste suffisante, ne procédez pas à des réglages dans le seul but de maximiser la colonne de mémoire libre.
Un cache chaud peut être utile après la fin de la tâche
Conserver les métadonnées et les pages de la base de données en mémoire peut accélérer la navigation ultérieure. Le cache doit être évalué selon la capacité du noyau à le récupérer sous pression, et non selon son retour immédiat à zéro.
Les pages mises en cache peuvent rester utiles jusqu’à ce qu’une demande concurrente modifie leur valeur, conformément au fonctionnement du cache de pages Linux.
Lancez une charge de travail contrôlée consommant de la mémoire et observez si le cache diminue avant le recours au swap ou l’arrêt de processus. Une récupération normale confirme l’hypothèse du cache.
Recherchez une croissance au fil de cycles répétés
Une véritable fuite se manifeste généralement par une empreinte mémoire du processus qui augmente continuellement après la même charge de travail terminée et ne se stabilise pas. Un seul plateau élevé après une analyse importante ne constitue pas une preuve suffisante.
Suivez l’utilisation et la saturation sur plusieurs cycles identiques afin de relier la pression mémoire à une charge de travail reproductible plutôt qu’à un instantané unique.
Exécutez trois fois la même tâche sur la bibliothèque et relevez le RSS de Plex après chaque stabilisation. N’allez plus loin que si la référence stabilisée continue d’augmenter ou si l’hôte commence à récupérer la mémoire de manière insuffisante. Évaluez la mémoire dans la topologie globale du serveur multimédia domestique, car le cache de pages, les services associés et le comportement du stockage peuvent modifier la référence saine une fois stabilisée.
Les conteneurs partagés peuvent modifier l’interprétation
Un autre service peut consommer du cache ou provoquer l’utilisation du swap, donnant l’impression que Plex est responsable d’un problème de mémoire à l’échelle de l’hôte. Inspectez l’ensemble de la machine avant de définir une limite plus basse pour Plex.
Les hôtes exécutant plusieurs services créent des dépendances entre conteneurs partagés autour de la même mémoire physique, même lorsque les processus sont isolés.
Répétez la charge de travail avec le plus grand conteneur associé en pause. Si la pression mémoire disparaît, ajustez le budget partagé de l’hôte avant de modifier Plex lui-même.
Assistance et conseils
Plus à lire

Faut-il sauvegarder Jellyfin à chaud ou arrêter le service au préalable ?
Privilégiez les sauvegardes lorsque le service est arrêté pour plus de simplicité ; n’utilisez des instantanés à chaud que lorsque l’état de l’application est...

Pourquoi Jellyfin chauffe-t-il ou est-il bruyant lorsque personne ne regarde de contenu en streaming ?
La chaleur au repos indique généralement une activité en arrière-plan ou une charge de travail d’hébergement partagé. Identifiez donc le processus actif et la...

Quand faut-il reconstruire Jellyfin plutôt que le réparer ?
Choisissez la reconstruction plutôt que la réparation lorsque la dérive de l’environnement d’exécution est à l’origine du problème et que l’état persistant est sauvegardé...

