Pourquoi Jellyfin génère-t-il des charges différentes lors des lectures et des écritures ?

Les lectures et écritures de Jellyfin créent des charges système différentes, car les transferts de médias volumineux, les petites mises à jour de la base de données, les pages mises en cache et les écritures durables suivent des chemins d’E/S différents.

Un serveur peut diffuser plusieurs films depuis un disque dur avec une faible charge apparente, puis devenir lent lorsqu’une analyse, une actualisation des métadonnées, une mise à jour de l’état de visionnage et une écriture dans le cache de transcodage se chevauchent. La variable importante n’est pas simplement « l’activité du disque » ; c’est de savoir si la charge de travail est séquentielle ou aléatoire, principalement orientée vers la lecture ou l’écriture, compatible avec la mise en cache ou sensible à la durabilité, et si elle entre en concurrence avec d’autres services pour la même file d’attente.

La lecture des médias est généralement une charge de travail de lecture séquentielle importante

La lecture directe lit généralement un fichier vers l’avant, à un débit proche du débit média transmis, les recherches n’intervenant que lorsque le client se déplace dans la vidéo. L’accès séquentiel permet aux périphériques de stockage et à la lecture anticipée du système d’exploitation de fonctionner efficacement. Ainsi, un disque mécanique peut souvent assurer une lecture ordinaire, même si sa latence d’accès aléatoire est bien plus élevée que celle d’un SSD. Dans le même temps, la charge CPU visible du serveur peut rester faible.

Les recommandations de Jellyfin en matière de stockage distinguent explicitement les fichiers multimédias des propres fichiers de Jellyfin : les médias ont principalement besoin d’un débit séquentiel supérieur à leur débit binaire, tandis que les fichiers de l’application sont soumis à de nombreux accès aléatoires. Cette séparation entre le stockage des médias et celui de l’application explique pourquoi un disque peut réussir un test de copie de plusieurs gigaoctets tout en restant un mauvais emplacement pour une base de données et une arborescence de métadonnées très sollicitées.

La limite tient aux pics de débit et à la concurrence. Plusieurs lectures à haut débit, la latence d’un système de fichiers distant, un stockage fragmenté ou des recherches concurrentes peuvent faire disparaître l’avantage du séquentiel. Mesurez le débit réellement transmis et la mise en file d’attente du périphérique pendant la combinaison de lectures réellement utilisée, au lieu de supposer que chaque flux de film se comporte comme une copie de fichier unique et ininterrompue.

Les opérations sur la base de données et les métadonnées produisent des E/S plus petites et moins séquentielles

Les analyses de bibliothèque, l’indexation des recherches, les mises à jour des illustrations, l’état des utilisateurs et les modifications de configuration touchent de nombreux enregistrements et fichiers, plutôt que de lire un seul objet volumineux du début à la fin. Les petites opérations rendent la latence d’accès et les IOPS plus visibles, surtout lorsque l’ensemble de travail dépasse la mémoire disponible. La même quantité de données transférées peut donc sembler bien plus coûteuse qu’une lecture de média.

Cette différence explique pourquoi le guide ZimaSpace sur la mise en mémoire tampon recommande de séparer l’état des applications à faible latence des médias volumineux lorsque les charges mixtes deviennent problématiques. Son explication des E/S mixtes décrit comment les analyses, les téléchargements, les sauvegardes et l’activité liée aux métadonnées peuvent perturber la lecture, même si chaque tâche semble raisonnable prise isolément.

La limite tient à la causalité : déplacer tous les fichiers sur un SSD est inutile si le délai observé provient d’une conversion effectuée par le CPU ou d’un réseau encombré. Commencez par comparer la latence de l’état des applications à celle de la lecture des médias pendant le même chevauchement de tâches. Seules les opérations de stockage qui suivent le symptôme doivent motiver un changement d’emplacement.

Le cache de pages rend les lectures et les écritures asymétriques

Les lectures tamponnées peuvent devenir des accès en mémoire une fois leurs pages récupérées, tandis que les écritures tamponnées sont souvent considérées comme terminées après la modification des pages en mémoire, le noyau se chargeant ensuite d’écrire ces pages modifiées. Les observations à court terme peuvent donc être trompeuses : une rafale d’écritures peut sembler peu coûteuse au début, puis provoquer une activité différée du périphérique, tandis que des lectures répétées peuvent sembler presque gratuites parce que le disque n’est plus sollicité.

Le modèle du cache de pages Linux décrit ces deux chemins : les lectures ordinaires alimentent les pages mises en cache, tandis que les écritures peuvent créer des pages modifiées dont la persistance est reportée jusqu’à l’écriture différée ou à un point de synchronisation explicite. Ce fonctionnement de l’écriture différée explique pourquoi Jellyfin peut afficher une activité de stockage en rafales après que l’opération visible pour l’utilisateur ayant créé les données est déjà terminée.

La limite tient à la durabilité et à la pression mémoire. Les logiciels de base de données peuvent demander des garanties de persistance plus fortes que les fichiers de cache ordinaires, et un hôte limité en mémoire peut être contraint d’écrire plus tôt les pages modifiées ou d’expulser les pages de lecture utiles. Ne déduisez pas les capacités du périphérique à partir d’une opération principalement exécutée en RAM.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les lectures et écritures simultanées se disputent la même file d’attente du périphérique

Un disque ou un SSD dispose en fin de compte d’une capacité de traitement limitée. Les lectures de lecture, les validations de la base de données, les téléchargements, les sauvegardes et les segments de transcodage peuvent donc se retrouver en file d’attente les uns derrière les autres. Sur un disque dur, les déplacements des têtes amplifient la pénalité lorsque des lectures séquentielles sont interrompues par de petites écritures sans rapport. Les SSD réduisent considérablement la latence de recherche, mais une file d’attente peut toujours apparaître lorsque l’amplification des écritures, les vidages ou d’autres conteneurs poussent le périphérique vers la saturation.

Le test de saturation du stockage présente cela comme un problème de ressource : l’utilisation seule ne suffit pas, car la longueur de la file d’attente et la latence montrent si la demande attend d’être traitée. Un disque affichant une bande passante moyenne modérée peut néanmoins être le goulot d’étranglement si de petites opérations synchrones restent assez longtemps en file pour retarder les demandes interactives de la base de données de Jellyfin.

La limite tient à la corrélation répétée. Un pic de latence ponctuel pendant une sauvegarde planifiée ne prouve pas que la conception du stockage est inadéquate pour la lecture habituelle. Reproduisez le même chevauchement, mettez un écrivain en pause et vérifiez si la latence de Jellyfin diminue ; si c’est le cas, planifier cette écriture à un autre moment ou l’isoler peut résoudre le problème sans remplacer toute la couche de stockage.

Établissez une matrice de lectures et d’écritures avant de modifier le stockage

Testez quatre états avec les mêmes médias et le même client : lecture seule, lecture avec une analyse de bibliothèque, lecture avec une écriture externe soutenue, puis le pic normal complet. Enregistrez le débit des médias, la latence de l’état des applications, la profondeur de la file d’attente du périphérique, l’activité des pages modifiées ou de l’écriture différée lorsqu’elle est disponible, ainsi que le délai d’affichage de la première image ou de recherche. Cette matrice montre si le problème suit les lectures, les écritures ou uniquement leur chevauchement.

Un contrôle avec cache chaud est également nécessaire, car la navigation répétée dans la bibliothèque peut ne plus solliciter le périphérique. Le contrôle à froid et à chaud garantit une comparaison fiable : exécutez un cas à froid et un cas répété afin de ne pas confondre un accès au cache avec une marge disponible du stockage, ni un défaut de cache avec une sous-performance permanente.

Conservez la disposition actuelle lorsque la lecture reste stable, que la mise en file d’attente demeure maîtrisée et que la latence de l’état des applications n’augmente pas sensiblement pendant le chevauchement habituel. Séparez les données de l’application, le cache ou les tâches fortement orientées vers l’écriture sur une autre couche lorsque la même interférence se reproduit systématiquement. Cherchez une cause autre que le stockage lorsque la file d’attente reste saine, mais que les indicateurs de calcul, de mémoire ou de réseau se dégradent.