Pourquoi Plex utilise-t-il beaucoup de ressources processeur après une mise à jour ?

Une utilisation élevée du processeur immédiatement après une mise à jour de Plex peut être due temporairement à une migration ou à une analyse, mais il ne faut pas considérer cela comme normal indéfiniment.

Le diagnostic le plus sûr est limité dans le temps. Notez la version de la mise à jour, l’heure de démarrage, les processus Plex actifs et l’activité du disque. Attendez la fin explicite de la migration ou de l’analyse, puis comparez l’utilisation du processeur lors d’un deuxième redémarrage propre. Si la charge persiste sans que la même tâche soit active, passez de l’hypothèse d’une « transition après mise à jour » à celle d’une régression ou d’un problème lié à la charge de travail.

Recherchez d’abord une migration de la base de données avant de modifier les paramètres

Certaines versions de Plex doivent analyser ou transformer les données existantes de la base de données avant que le serveur soit entièrement prêt. Cette opération peut consommer du processeur et générer des E/S dans les données de l’application pendant une durée limitée.

Certaines versions nécessitent une analyse complète des enregistrements existants de la base de données avant la fin du démarrage. L’utilisation temporaire du processeur et les E/S dans les données de l’application doivent donc être évaluées en fonction de la fin de cette migration, plutôt que par rapport au comportement normal au repos.

Consultez les journaux pour repérer l’activité de migration et vérifiez si l’utilisation du processeur diminue lorsque le serveur redevient prêt. N’interrompez pas une migration connue simplement parce que le premier redémarrage est plus lent que d’habitude.

Distinguez une nouvelle analyse d’un processus bloqué

Une mise à jour peut également déclencher une nouvelle analyse ou la répétition d’analyses des médias, des aperçus ou des métadonnées. Cette charge de travail peut se poursuivre après que l’interface web est redevenue accessible et donner l’impression d’une régression du serveur.

Une analyse postérieure à la mise à jour peut consommer du processeur pendant une période prolongée. Considérez les ensembles de travail froids et en cours de reconstruction comme l’une des raisons pour lesquelles le comportement lors de la première exécution peut différer de celui observé ensuite au repos, pendant que vous identifiez la tâche Plex réellement active.

Mettez en pause les tâches planifiées facultatives ou attendez la fin de la tâche active, puis répétez la même observation au repos. Si l’utilisation du processeur diminue, reprogrammez la tâche au lieu de modifier les limites globales du processeur.

Comparez le deuxième redémarrage

Une opération ponctuelle ne devrait pas se reproduire exactement à chaque démarrage propre. Un deuxième redémarrage après la fin de l’opération constitue le test de contrôle le plus rapide pour distinguer une migration d’un comportement persistant.

Conservez le chemin des données de l’application inchangé pendant la comparaison et surveillez les mêmes noms de processus et les mêmes métriques. Le chemin persistant des données de l’application doit rester constant afin que la seule variable volontaire soit la mise à jour terminée.

Si le deuxième démarrage mobilise toujours fortement le processeur, recueillez les journaux et déterminez si la charge de travail concerne la recherche, l’analyse, le transcodage ou un autre processus. Poursuivez le diagnostic à partir de cette charge de travail concrète, et non de la date de mise à jour seule.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

N’effectuez une restauration à une version antérieure qu’avec un état sûr

Une restauration binaire à une version antérieure peut être risquée si la version la plus récente a modifié l’état enregistré d’une manière que l’ancienne version ne comprend pas. Protégez la base de données d’avant la mise à jour avant d’utiliser une restauration comme raccourci de diagnostic.

Une restauration doit rétablir une copie d’état correspondante, car des points de récupération propres protègent contre les modifications qu’un ancien binaire pourrait ne pas interpréter correctement.

Lorsque la restauration à une version antérieure est nécessaire, rétablissez l’état connu comme fiable avant la mise à jour avec la version correspondante. N’alternez pas entre d’anciens et de nouveaux binaires sur une même base de données active pour tenter d’isoler une utilisation élevée du processeur.