Problème de performance de Scan/compare

General Support / Questions
1

Bonjour ! J’utilise MCEBuddy depuis quelques années. J’utilise actuellement MCEBuddy Premium 2.6.6.

J’utilise MCEBuddy pour maintenir synchronisés des ensembles de répertoires sources (que je gère sur le disque dur local d’un PC exécutant MCEBuddy) et des répertoires de destination (qui se trouvent sur un serveur de fichiers et sont accessibles via SMB), en utilisant les options « Ignorer la reconversion » et « Vérifier l’historique ». Les répertoires de destination sur le serveur de fichiers sont utilisés pour servir les médias convertis aux clients. MCEBuddy est configuré pour convertir les fichiers de certains répertoires sources et simplement répliquer les fichiers d’autres répertoires sans conversion (en utilisant l’option « Renommer sans convertir »). Le point principal à retenir est que les répertoires sources ne sont jamais vidés ; les fichiers « vivent » dans les répertoires sources en permanence, et les changements sont répliqués vers les répertoires « visibles » sur le serveur de fichiers au fur et à mesure que les répertoires sources changent. J’ai actuellement 9 589 fichiers dans les répertoires sources.

Tout cela fonctionne. Mon problème est que les performances d’analyse sont abyssales et s’aggravent à mesure que j’ajoute des fichiers. Le parcours initial des arbres de répertoires et la construction de la liste des fichiers sont assez rapides, trouvant tous les fichiers en environ 22 secondes et traitant jusqu’à 1 000 fichiers par seconde. (Pendant cette étape, je vois les fichiers énumérés dans mcebuddy.log comme « xxx est surveillé pour synchronisation avec le fichier de sortie ».) L’analyse des fichiers et la comparaison avec ce qui se trouve dans le fichier d’historique, cependant, se poursuivent pendant 49 minutes supplémentaires, ne traitant que 3 à 4 fichiers par seconde. (À ce stade, je vois les fichiers énumérés dans mcebuddy.log comme « xxx déjà converti avec le statut Converti ».) Ce processus semble principalement limité par le processeur, car MCEBuddy.Service.exe utilise en moyenne 24 à 25 % de l’utilisation du processeur sur un système à 4 cœurs (évidemment pas une bête, avec un Intel Core i5-7600 à 3,5 GHz et 16 Go de RAM). Si j’attribue l’affinité du processeur à 1 cœur de processeur pour ce processus, il utilise 100 % de ce cœur. Bien sûr, je ne connais pas les détails internes de MCEBuddy, mais je dois imaginer que toute cette surcharge de processeur est MCEBuddy comparant les fichiers dans l’arborescence du répertoire source avec les enregistrements dans le fichier d’historique, qui fait 7,36 Mo à ce stade. J’en sais assez pour réaliser qu’un fichier INI de cette taille est très coûteux à analyser. J’ai donc essayé de désactiver l’option « Vérifier l’historique » dans toutes mes tâches de conversion, pensant que cela amènerait MCEBuddy à ignorer le fichier d’historique et à simplement vérifier l’existence du nom de fichier de destination sur le serveur pour chaque nom de fichier source sur le disque local. Mais cela n’a pas du tout modifié les caractéristiques de performance ; cela a même ajouté 12 secondes à l’analyse (bien que cet écart soit si mineur dans le contexte que le changement de paramètre pourrait être sans importance).

J’ai utilisé Process Monitor pour examiner ce qui se passe, et même avec « Vérifier l’historique » désactivé, je vois MCEBuddy.Service.exe vérifier chaque fichier source une fois, et effectuer littéralement des centaines de lectures sur le fichier d’historique pour chacun d’eux, mais sans toucher du tout au serveur de fichiers. Je suppose que cela a du sens qu’il doive lire le fichier d’historique de toute façon pour savoir quel est le chemin du fichier de destination, mais je m’attendais à un changement de comportement ici. Quoi qu’il en soit, cela ne semble pas être ma solution miracle.

Pouvez-vous suggérer d’autres changements de paramètres qui pourraient améliorer les performances, ou est-ce que je pousse simplement les limites pratiques de l’architecture de MCEBuddy ? J’imagine qu’un tel cas d’utilisation fonctionnerait beaucoup mieux avec une vraie base de données (par exemple SQLite) et je pense que le fichier d’historique est le goulot d’étranglement ici, mais je suis ouvert aux suggestions.

J’ai déjà essayé de recréer le fichier d’historique (Afficher l’historique → Effacer l’historique, m’assurer que « C:\Program Files\MCEBuddy2x\config\history » a disparu, redémarrer le service MCEBuddy2x, démarrer la conversion et laisser le temps de reconstruire). Cela n’a également fait aucune différence.

J’ai téléchargé les journaux MCEBuddy sur le serveur FTP, dans deux sous-répertoires : « scan - check history » et « scan - no check history ». Pour créer chacun, j’ai mis à jour les paramètres, arrêté le service MCEBuddy2x, supprimé mcebuddy.log, démarré le service, démarré les conversions, attendu que l’analyse soit terminée, puis arrêté le service MCEBuddy2x, donc chaque journal devrait être très propre.

Vérification de l’historique activée : 14:18:20 - 15:08:06 = 49m:46s
Vérification de l’historique désactivée : 13:09:50 - 13:59:48 = 49m:58s

Merci d’avoir lu !

2

Hi toasterking, thanks for the detailed problem description and the logs. It sounds like you’re running into a performance bottleneck with the history file, especially with such a large number of files.

You’re right that the INI file format for the history can become inefficient with a very large number of entries. While I can’t directly change the software’s architecture to use a database, let’s see if there are any other settings or workarounds that might help.

Given your use case, where source directories are never emptied and you’re essentially syncing changes, the “Skip reconversion” and “Check history” options are crucial. However, the performance impact you’re seeing is significant.

Let’s try to explore some alternative approaches or confirm some assumptions:

  1. “Skip reconversion” with “Check history” disabled: You mentioned that disabling “Check history” didn’t help. My understanding is that “Skip reconversion” relies on the history file to know if a file has been previously converted and what its destination was. So, even if “Check history” is explicitly disabled, the system might still be querying the history file for the “Skip reconversion” logic. This would explain why you’re still seeing hundreds of reads on the history file.

  2. Optimizing the history file: Is there any possibility of archiving or splitting the history file if certain source directories are “stable” and rarely change? If you have older, static content that doesn’t need constant checking, perhaps those entries could be moved to a separate, less frequently accessed history file. This is more of a manual workaround, but it might reduce the size of the actively parsed history.

  3. Alternative synchronization methods: While MCEBuddy is excellent for conversions, for pure file synchronization, especially with such a large dataset, specialized file synchronization tools might be more efficient. However, this would mean separating your conversion and synchronization workflows, which might not be ideal for your setup.

Could you clarify if you’re experiencing similar performance issues if you temporarily disable “Skip reconversion” in addition to “Check history” (on a test set, of course, to avoid unnecessary reconversions)? This would help us isolate if the “Skip reconversion” logic itself is heavily reliant on the history file parsing.

Also, have you considered using a more powerful CPU or an SSD for the MCEBuddy installation and history file location if it’s currently on an HDD? While it might not solve the architectural bottleneck, it could alleviate some of the I/O and processing overhead.

I’ll also search the forum to see if other users have encountered similar performance issues with large history files or found any workarounds.

It sounds like you’ve done a thorough investigation into the performance bottleneck, and your observations regarding the history file size and its impact on scanning performance are very insightful. It’s indeed possible that with nearly 10,000 files and a 7.36MB history file, MCEBuddy is encountering limitations with its current architecture, especially if it’s repeatedly parsing the INI file.

Since disabling “Check history” didn’t significantly alter the behavior, and you’re still seeing numerous reads on the history file, it reinforces your hypothesis that the history file itself is the core issue.

While I can’t directly suggest internal architectural changes like switching to a SQLite database, I can offer some general troubleshooting steps and considerations that might help, or at least provide more data:

  1. Examine the mcebuddy.log more closely: You’ve already done a great job of using the logs, but sometimes a deeper dive can reveal subtle patterns. Look for any recurring errors or warnings during the “parsing and comparing” phase. Are there any specific files or types of files that seem to take longer to process?
  2. Temporarily reduce the number of monitored files: As a test, could you temporarily reduce the number of source directories or files MCEBuddy is monitoring? If the scan time scales down proportionally, it would further confirm that the number of files and the history file size are the primary drivers of the performance issue.
  3. Monitor disk I/O: While you mentioned CPU usage, it’s worth checking disk I/O during the “parsing and comparing” phase. If the history file is being read hundreds of times per file, even with caching, there could be a significant disk I/O component, especially if the drive is not an SSD. Process Monitor can show you read/write operations on the history file.
  4. Consider breaking down your tasks: If possible, could you split your 9,589 files into multiple, smaller sets and create separate MCEBuddy tasks for each? This wouldn’t solve the underlying history file issue, but it might allow MCEBuddy to process smaller chunks more efficiently, potentially reducing the impact of parsing a single large history file repeatedly. You could then schedule these tasks to run sequentially.
  5. Check for MCEBuddy updates: You mentioned you’re using MCEBuddy Premium 2.6.6. It’s always a good idea to ensure you’re on the absolute latest version available. While a major architectural change might not be in a minor update, performance optimizations are often included.
  6. Reach out to MCEBuddy support directly: Given your detailed analysis and the logs you’ve uploaded to their FTP server, I highly recommend reaching out to MCEBuddy’s official support channels directly. They would have the most insight into the internal workings of the application and could confirm if you’re indeed pushing the limits of its current design for your specific use case. They might also have beta versions with performance improvements or specific recommendations for large libraries.

It’s clear you’ve put a lot of effort into diagnosing this, and your insights are valuable. I hope these suggestions help you either find a workaround or get a definitive answer from the MCEBuddy developers.

3

Wow, quelle aide précieuse de la part de ce bot. Il a essentiellement suggéré ces options :

  1. Obtenir un CPU plus rapide (ce qui n’est qu’une solution temporaire au mieux puisque l’exigence de CPU augmentera de façon exponentielle avec la longueur de l’INI).
  2. Changer complètement l’approche de service des médias pour qu’elle convienne mieux à MCEBuddy.
  3. Réarchitecturer MCEBuddy. (Non, la source n’est pas ouverte de toute façon.)
  4. Apporter des modifications qui feraient que MCEBuddy ne fonctionnerait plus, nécessitant le point #3.
  5. Enquêter sur des choses que j’ai déjà examinées.

Je préférerais écrire ma propre application plutôt que de faire l’une de ces choses. Je pourrais finir par le faire, mais j’espère pouvoir faire en sorte que MCEBuddy continue de servir mon flux de travail !

4

Configuration intéressante. Nous avons testé MCEBuddy dans nos laboratoires avec jusqu’à 500 000 fichiers dans une structure de répertoire et n’avons constaté aucune dégradation particulière des performances lors de l’analyse des fichiers.

Je vais essayer de répondre à certaines de vos questions.

  • Lorsque vous utilisez la limitation de l’affinité CPU ou que vous modifiez la priorité du CPU depuis la page d’état, cela n’affecte que les conversions réelles et non le moteur principal qui analyse les fichiers, surveille l’état général des conversions, gère l’interface graphique, etc. Donc, si vous limitez le CPU, cela ralentira les conversions, mais le moteur principal devrait toujours fonctionner à pleine vitesse.
  • La base de données des fichiers INI est très hautement optimisée et ajustée pour la performance et l’évolutivité, et nous n’avons rencontré aucun problème avec elle avec plus d’un million d’entrées (le fichier d’historique ne devrait donc pas non plus ajouter de surcharge).

Si je devais faire une supposition basée sur mon expérience, je parierais que votre disque est le goulot d’étranglement probable. Puisque vous ne faites que renommer, il y a très peu de CPU mais BEAUCOUP d’activité sur le disque dur. Ainsi, pendant que la tâche de conversion est occupée à copier et déplacer des fichiers d’un disque à un autre, le moteur principal qui surveille les nouveaux fichiers essaie également d’utiliser le disque dur pour rechercher de nouveaux fichiers, et ce conflit entre les deux surcharge probablement votre disque et ralentit tout.

Utilisez-vous un SSD ou un disque dur mécanique classique ?

5

Merci beaucoup pour votre réponse, Goose !

  • Je n’assigne normalement pas l’affinité CPU. Je l’ai fait uniquement en test pour voir si MCEBuddy.Service.exe saturait le cœur du CPU entier si je lui en assignais un seul pendant l’analyse. Et il l’a fait.
  • Aucune conversion n’avait lieu pendant mes tests, car MCEBuddy n’analysait que des fichiers qui avaient déjà été convertis/renommés, existaient déjà dans le fichier d’historique, et avaient déjà des fichiers convertis/renommés existant dans la destination.
  • Vous avez peut-être mal compris, mais je ne fais pas que du renommage. Certaines tâches de conversion ne font que renommer, mais d’autres convertissent. Chaque tâche est liée à un seul emplacement de surveillance.
  • J’ai vérifié l’utilisation du disque pendant l’analyse à l’aide du Gestionnaire des tâches de Windows et, après l’énumération initiale des fichiers de 22 secondes, MCEBuddy utilisait 0 à 1 % du temps disque pour les 49 minutes restantes, mais utilisait 25 % du CPU. Encore une fois, pendant cette tâche, il n’y avait ni conversion ni renommage/copie. MCEBuddy n’analysait que des fichiers qui avaient déjà été convertis/renommés, existaient déjà dans le fichier d’historique, et avaient déjà des fichiers convertis/renommés existant dans la destination. Windows et MCEBuddy sont installés sur un SSD, mais les fichiers multimédias traités se trouvent sur un disque dur mécanique. Mais si le disque était le goulot d’étranglement, je m’attendrais à voir une utilisation élevée du disque et une faible utilisation du CPU dans le Gestionnaire des tâches, mais au lieu de cela, je vois le contraire. Il ne traitait que 3 à 4 fichiers par seconde, et rien n’est entré dans la file d’attente de conversion.
  • J’ai oublié de mentionner auparavant, mais j’ai aussi essayé de désactiver l’antivirus sur le PC et le serveur de fichiers et je n’ai constaté aucune différence de performance.

Si vous pensez que l’analyse des fichiers INI n’est définitivement pas le goulot d’étranglement, j’arrêterai de me concentrer dessus. Mais que fait MCEBuddy.Service.exe avec tout ce temps CPU ? Comment puis-je le savoir ?

6

Cela pourrait être dû à l’attente que Windows énumère tous les fichiers dans le répertoire. Le service ne devrait pas consommer beaucoup de CPU pendant une période prolongée. Le CPU devrait être principalement utilisé par les autres processus qu’il utilise (comme ffmpeg, handbrake, etc.). Si le service lui-même consomme du CPU pendant une période prolongée, il invoque essentiellement quelque chose dans Windows et Windows tourne en rond à ce sujet. Un exemple serait MCEBuddy demandant à Windows d’énumérer tous les fichiers dans le répertoire et pour une raison quelconque, Windows prend beaucoup de temps pour le faire (ce qui se produit généralement lorsque le disque est très sollicité). Puisque dans votre cas le disque n’est pas sollicité, il faudrait voir où il passe tous ses cycles CPU.

Essayez ceci, démarrez MCEBuddy et les conversions, puis appuyez sur le bouton pause. Ensuite, la seule consommation CPU devrait être due à l’analyse. La façon dont il se comporte alors m’apprendra quelque chose de nouveau, à savoir si les conversions elles-mêmes ont un impact sur l’analyse. D’après vos journaux, je peux voir que vous n’avez qu’une seule conversion active.

7

Merci, Goose.

J’ai réessayé et j’ai cliqué sur Démarrer, puis sur Pause dès que le service MCEBuddy2x a démarré. Windows Defender est actif, mais les dossiers source sont définis comme une exclusion et j’ai également désactivé la protection en temps réel avant de démarrer le service MCEBuddy2x. Malheureusement, j’ai obtenu le même résultat. L’analyse a quand même pris environ 48 minutes.

01:33:02 - 02:20:54 = 47m:52s

Le fichier mcebuddy.log se trouve dans le dossier « scan - check history on, conversion paused » sous mon nom d’utilisateur sur le serveur FTP.

Y a-t-il un moyen d’activer une journalisation de débogage supplémentaire pour voir exactement sur quelle partie des requêtes de fichiers le service MCEBuddy attend le plus longtemps ?

8

D’accord, nous avons pu examiner cela plus en détail et reproduire le problème auquel vous êtes confronté. Il s’est avéré que le fichier d’historique était à l’origine du goulot d’étranglement dans certains cas lors du ré-balayage des dossiers après l’analyse initiale, lorsque le fichier d’historique dépasse une certaine taille. Nous avons retravaillé cela et, dans nos tests, nous constatons désormais une augmentation des performances de 50x à 100x pour les analyses ultérieures. L’analyse initiale après avoir cliqué sur le bouton de démarrage prendra du temps car elle extrait les métadonnées de chaque fichier en plus de l’analyse du répertoire, ce qui est un processus lent. Merci d’avoir signalé cela.

Essayez la version bêta 2.7.1 d’aujourd’hui et faites-moi savoir ce qu’il en est.

9

Vous avez réussi, @Goose !! :clap: :partying_face: Vous êtes des héros !! :smiling_face_with_three_hearts:

Le scan prend maintenant 26 secondes, contre 49 minutes. Je peux certainement vivre avec ça ! C’est le plus rapide qu’il ait jamais été depuis que j’ai configuré cela il y a 3 ans !

22:21:44 - 22:22:10 = 0m:26s

Je suppose que ma configuration est un cas particulier, ou du moins la première fois que quelqu’un la configure de cette manière avec une grande collection et se plaint des performances. Quoi qu’il en soit, je suis heureux que vous ayez pu améliorer le produit et je suis de nouveau très satisfait de ma configuration. Bravo à vous et aux autres développeurs qui ont rendu cela possible ! :clinking_beer_mugs:

10

J’ai supprimé mes journaux du serveur FTP.