Problema de rendimiento de Scan/compare

Soporte general / Preguntas
1

Hola! He estado usando MCEBuddy durante algunos años. Actualmente estoy usando MCEBuddy Premium 2.6.6.

Utilizo MCEBuddy para mantener sincronizados conjuntos de directorios de origen (que mantengo en el disco duro local de una PC que ejecuta MCEBuddy) y directorios de destino (que están en un servidor de archivos y se accede a ellos a través de SMB), utilizando las opciones “Omitir reconversión” y “Comprobar historial”. Los directorios de destino en el servidor de archivos se utilizan para servir medios convertidos a los clientes. MCEBuddy está configurado para convertir archivos de ciertos directorios de origen y simplemente replicar archivos de otros sin convertir (usando la opción “Renombrar sin convertir”). La idea principal aquí es que los directorios de origen nunca se vacían; los archivos “viven” en los directorios de origen todo el tiempo, y los cambios se replican en los directorios “visibles” en el servidor de archivos a medida que cambian los directorios de origen. Actualmente tengo 9,589 archivos en los directorios de origen.

Todo esto funciona. Mi problema es que el rendimiento del escaneo es pésimo y empeora a medida que agrego archivos. El recorrido inicial de los árboles de directorios y la construcción de la lista de archivos es bastante rápido, encontrando todos los archivos en unos 22 segundos y procesando hasta 1,000 archivos por segundo. (Durante esta etapa, veo los archivos enumerados en mcebuddy.log como “xxx está siendo monitoreado para sincronización con el archivo de salida”). Sin embargo, el análisis de archivos y la comparación con lo que hay en el archivo de historial continúan durante otros 49 minutos, procesando solo de 3 a 4 archivos por segundo. (En este punto, veo los archivos enumerados en mcebuddy.log como “xxx ya convertido con estado Convertido”). Este proceso parece estar limitado principalmente por la CPU, ya que MCEBuddy.Service.exe promedia un uso de CPU del 24-25% en un sistema de 4 núcleos (obviamente no es una bestia, con un Intel Core i5-7600 a 3.5 GHz y 16 GB de RAM). Si asigno afinidad de CPU a 1 núcleo de CPU para ese proceso, utiliza el 100% de ese núcleo. Por supuesto, no conozco los internos de MCEBuddy, pero tengo que imaginar que toda esta sobrecarga de CPU es MCEBuddy comparando los archivos en el árbol de directorios de origen con los registros en el archivo de historial, que tiene 7.36 MB en este momento. Sé lo suficiente como para darme cuenta de que un archivo INI de este tamaño es muy costoso de analizar. Así que intenté deshabilitar la opción “Comprobar historial” en todas mis tareas de conversión, pensando que eso haría que MCEBuddy ignorara el archivo de historial y solo verificara la existencia del nombre del archivo de destino en el servidor para cada nombre de archivo de origen en la unidad local. Pero no cambió las características de rendimiento en absoluto; de hecho, agregó 12 segundos al escaneo (aunque esa desviación es tan menor en contexto que el cambio de configuración podría ser irrelevante).

He usado Process Monitor para examinar lo que está sucediendo, e incluso con “Comprobar historial” deshabilitado, veo que MCEBuddy.Service.exe verifica cada archivo de origen una vez y realiza literalmente cientos de lecturas en el archivo de historial por cada uno, pero sin tocar el servidor de archivos en absoluto. Supongo que tiene sentido por qué necesitaría leer el archivo de historial de todos modos para averiguar cuál es la ruta del archivo de destino, pero esperaba algún cambio en el comportamiento aquí. Independientemente, esto no parece ser mi panacea.

¿Puede sugerir algún otro cambio de configuración que pueda mejorar el rendimiento, o estoy simplemente superando los límites prácticos de la arquitectura de MCEBuddy? Me imagino que este tipo de caso de uso funcionaría mucho mejor con una base de datos real (por ejemplo, SQLite) y creo que el archivo de historial es el cuello de botella aquí, pero estoy abierto a sugerencias.

Ya intenté recrear el archivo de historial (Mostrar historial → Borrar historial, me aseguré de que “C:\\Program Files\\MCEBuddy2x\\config\\history” haya desaparecido, reinicié el servicio MCEBuddy2x, comencé la conversión y permití que se reconstruyera). Eso tampoco marcó ninguna diferencia.

Ya cargué los registros de MCEBuddy en el servidor FTP, en dos subdirectorios: “scan - check history” y “scan - no check history”. Para crear cada uno, actualicé la configuración, detuve el servicio MCEBuddy2x, eliminé mcebuddy.log, inicié el servicio, comencé las conversiones, esperé hasta que el escaneo se completó y detuve el servicio MCEBuddy2x, por lo que cada registro debería estar muy limpio.

Comprobar historial habilitado: 14:18:20 - 15:08:06 = 49m:46s
Comprobar historial deshabilitado: 13:09:50 - 13:59:48 = 49m:58s

¡Gracias por leer!

2

Hola, toasterking. Gracias por la descripción detallada del problema y los registros. Parece que te estás encontrando con un cuello de botella en el rendimiento con el archivo de historial, especialmente con una cantidad tan grande de archivos.

Tienes razón en que el formato de archivo INI para el historial puede volverse ineficiente con una cantidad muy grande de entradas. Si bien no puedo cambiar directamente la arquitectura del software para usar una base de datos, veamos si hay otras configuraciones o soluciones alternativas que puedan ayudar.

Dado tu caso de uso, en el que los directorios de origen nunca se vacían y básicamente estás sincronizando cambios, las opciones „Omitir reconversión“ („Skip reconversion“) y „Comprobar historial“ („Check history“) son fundamentales. Sin embargo, el impacto en el rendimiento que estás viendo es significativo.

Intentemos explorar algunos enfoques alternativos o confirmar algunas suposiciones:

  1. „Omitir reconversión“ con „Comprobar historial“ desactivado: Mencionaste que desactivar „Comprobar historial“ no ayudó. Tengo entendido que „Omitir reconversión“ se basa en el archivo de historial para saber si un archivo ya ha sido convertido previamente y cuál era su destino. Por lo tanto, incluso si „Comprobar historial“ está explícitamente desactivado, es posible que el sistema siga consultando el archivo de historial para la lógica de „Omitir reconversión“. Esto explicaría por qué sigues viendo cientos de lecturas en el archivo de historial.

  2. Optimización del archivo de historial: ¿Existe alguna posibilidad de archivar o dividir el archivo de historial si ciertos directorios de origen son „estables“ y rara vez cambian? Si tienes contenido antiguo y estático que no necesita una comprobación constante, tal vez esas entradas podrían trasladarse a un archivo de historial separado y al que se acceda con menos frecuencia. Esto es más bien una solución alternativa manual, pero podría reducir el tamaño del historial analizado activamente.

  3. Métodos de sincronización alternativos: Aunque MCEBuddy es excelente para las conversiones, para la sincronización de archivos pura, especialmente con un conjunto de datos tan grande, las herramientas especializadas de sincronización de archivos podrían ser más eficientes. Sin embargo, esto significaría separar tus flujos de trabajo de conversión y sincronización, lo cual podría no ser ideal para tu configuración.

¿Podrías aclarar si experimentas problemas de rendimiento similares si desativas temporalmente „Omitir reconversión“ además de „Comprobar historial“ (en un conjunto de prueba, por supuesto, para evitar reconversiones innecesarias)? Esto nos ayudaría a aislar si la lógica de „Omitir reconversión“ en sí misma depende en gran medida del análisis del archivo de historial.

Además, ¿has considerado usar una CPU más potente o un SSD para la instalación de MCEBuddy y la ubicación del archivo de historial si actualmente está en un HDD? Aunque puede que no resuelva el cuello de botella arquitectónico, podría aliviar parte de la sobrecarga de E/S y procesamiento.

También buscaré en el foro para ver si otros usuarios se han encontrado con problemas de rendimiento similares con archivos de historial grandes o han encontrado alguna solución alternativa.

Parece que has hecho una investigación exhaustiva sobre el cuello de botella del rendimiento, y tus observaciones sobre el tamaño del archivo de historial y su impacto en el rendimiento del análisis son muy perspicaces. De hecho, es posible que con casi 10 000 archivos y un archivo de historial de 7,36 MB, MCEBuddy esté encontrando limitaciones con su arquitectura actual, especialmente si analiza repetidamente el archivo INI.

Dado que desactivar „Comprobar historial“ no alteró significativamente el comportamiento y sigues viendo numerosas lecturas en el archivo de historial, esto refuerza tu hipótesis de que el archivo de historial en sí mismo es el problema principal.

Aunque no puedo sugerir directamente cambios arquitectónicos internos como cambiar a una base de datos SQLite, puedo ofrecer algunos pasos generales de solución de problemas y consideraciones que podrían ayudar, o al menos proporcionar más datos:

  1. Examina el archivo mcebuddy.log más de cerca: Ya has hecho un gran trabajo usando los registros, pero a veces una inmersión más profunda puede revelar patrones sutiles. Busca cualquier error o advertencia recurrente durante la fase de „análisis y comparación“ („parsing and comparing“). ¿Hay algún archivo específico o tipo de archivo que parezca tardar más en procesarse?
  2. Reduce temporalmente el número de archivos monitoreados: Como prueba, ¿podrías reducir temporalmente el número de directorios o archivos de origen que MCEBuddy está monitoreando? Si el tiempo de análisis se reduce proporcionalmente, confirmaría aún más que la cantidad de archivos y el tamaño del archivo de historial son los principales impulsores del problema de rendimiento.
  3. Monitorea la E/S del disco: Aunque mencionaste el uso de la CPU, vale la pena comprobar la E/S del disco durante la fase de „análisis y comparación“. Si el archivo de historial se lee cientos de veces por archivo, incluso con almacenamiento en caché, podría haber un componente significativo de E/S de disco, especialmente si la unidad no es un SSD. Process Monitor puede mostrarte las operaciones de lectura/escritura en el archivo de historial.
  4. Considera dividir tus tareas: Si es posible, ¿podrías dividir tus 9589 archivos en conjuntos múltiples más pequeños y crear tareas separadas de MCEBuddy para cada uno? Esto no resolvería el problema subyacente del archivo de historial, pero podría permitir que MCEBuddy procese fragmentos más pequeños de manera más eficiente, reduciendo potencialmente el impacto de analizar repetidamente un solo archivo de historial grande. Luego podrías programar estas tareas para que se ejecuten secuencialmente.
  5. Comprueba si hay actualizaciones de MCEBuddy: Mencionaste que estás usando MCEBuddy Premium 2.6.6. Siempre es una buena idea asegurarse de estar en la versión absolutamente más reciente disponible. Si bien es posible que un cambio arquitectónico importante no esté en una actualización menor, las optimizaciones de rendimiento a menudo se incluyen.
  6. Ponte en contacto directamente con el soporte de MCEBuddy: Dadas tus observaciones detalladas y los registros que has subido a su servidor FTP, te recomiendo encarecidamente que te pongas en contacto directamente con los canales de soporte oficiales de MCEBuddy. Ellos tendrían la mayor perspectiva sobre el funcionamiento interno de la aplicación y podrían confirmar si realmente estás llevando al límite su diseño actual para tu caso de uso específico. También podrían tener versiones beta con mejoras de rendimiento o recomendaciones específicas para bibliotecas grandes.

Está claro que has puesto mucho esfuerzo en diagnosticar esto, y tus observaciones son valiosas. Espero que estas sugerencias te ayuden a encontrar una solución alternativa o a obtener una respuesta definitiva de los desarrolladores de MCEBuddy.

3

Vaya, esta bot es de gran ayuda. Esencialmente ha sugerido estas opciones:

  1. Conseguir una CPU más rápida (lo cual es solo una solución temporal en el mejor de los casos, ya que el requisito de CPU aumentará exponencialmente con la longitud del INI).
  2. Cambiar todo el enfoque de servicio de medios para que se adapte mejor a MCEBuddy.
  3. Reestructurar MCEBuddy. (No, el código fuente no está abierto de todos modos).
  4. Realizar cambios que harían que MCEBuddy dejara de funcionar, lo que requeriría el punto #3.
  5. Investigar cosas que ya he investigado.

Preferiría escribir mi propia aplicación que hacer algo de esto. Puede que termine haciendo eso, ¡pero espero poder hacer que MCEBuddy siga sirviendo a mi flujo de trabajo!

4

Configuración interesante. Hemos probado MCEBuddy aquí en nuestros laboratorios con hasta 500.000 archivos en una estructura de directorios y no hemos visto ninguna degradación de rendimiento particular al escanear archivos.

Intentaré abordar algunas de sus preguntas.

  • Cuando se utiliza la afinidad de CPU limitada o se cambia la prioridad de la CPU desde la página de estado, esto solo afecta a las conversiones reales y no al motor principal que escanea archivos, supervisa el estado general de las conversiones, maneja la GUI, etc. Por lo tanto, si limita la CPU, ralentizará las conversiones, pero el motor principal debería seguir funcionando a toda velocidad.
  • La base de datos de archivos INI está muy optimizada y ajustada para el rendimiento y la escalabilidad, y no hemos visto problemas con ella con más de un millón de entradas (por lo que el archivo de historial tampoco debería añadir ninguna sobrecarga).

Si tuviera que adivinar basándome en mi experiencia, apostaría a que su disco es el cuello de botella probable. Dado que solo está haciendo renombrar, es básicamente muy poca CPU pero MUCHA actividad del disco duro. Así que, mientras la tarea de conversión está ocupada copiando y moviendo archivos de un disco a otro, el motor principal que monitoriza nuevos archivos también está intentando usar el disco duro para buscar nuevos archivos y ese choque entre los dos probablemente está sobrecargando su disco y ralentizando todo.

¿Está utilizando una unidad de estado sólido (SSD) o un disco duro de plato normal?

5

¡Muchas gracias por tu respuesta, Goose!

  • Normalmente no asigno afinidad de CPU. Solo lo hice como prueba para ver si MCEBuddy.Service.exe saturaría todo el núcleo de la CPU si le asignaba un núcleo durante el escaneo. Y lo hizo.
  • No se estaban produciendo conversiones durante mis pruebas, ya que MCEBuddy solo estaba escaneando archivos que ya habían sido convertidos/renombrados, ya existían en el archivo de historial y ya tenían archivos convertidos/renombrados existentes en el destino.
  • Quizás lo entendiste mal, pero no estoy solo renombrando. Algunas tareas de conversión solo renombran, pero otras convierten. Cada tarea está vinculada a una única ubicación de monitoreo.
  • Comprobé el uso del disco durante el escaneo usando el Administrador de Tareas de Windows y, después de la enumeración inicial de archivos de 22 segundos, MCEBuddy estaba utilizando un 0-1% de tiempo de disco durante los 49 minutos restantes, pero utilizando un 25% de CPU. De nuevo, durante esta tarea, no hubo conversión ni renombrado/copia. MCEBuddy solo estaba escaneando archivos que ya habían sido convertidos/renombrados, ya existían en el archivo de historial y ya tenían archivos convertidos/renombrados existentes en el destino. Windows y MCEBuddy están instalados en una SSD, pero los archivos multimedia que se están procesando están en un disco duro mecánico. Pero si el disco fuera el cuello de botella, esperaría ver un alto uso del disco y un bajo uso de la CPU en el Administrador de Tareas, pero en cambio, veo lo contrario. Solo estaba procesando de 3 a 4 archivos por segundo, y nada entró en la cola de conversión.
  • Olvidé mencionar antes, pero también intenté deshabilitar el antivirus en la PC y en el servidor de archivos y no vi ninguna diferencia en el rendimiento.

Si crees que el análisis del archivo INI definitivamente no es el cuello de botella, dejaré de centrarme en eso. Pero ¿qué está haciendo MCEBuddy.Service.exe con todo ese tiempo de CPU? ¿Cómo puedo averiguarlo?

6

Eso podría ser esperando a que Windows enumere todos los archivos en el directorio. El servicio no debería consumir mucha CPU durante un período prolongado. La CPU debería ser consumida principalmente por los otros procesos que utiliza (como ffmpeg, handbrake, etc.). Si el servicio en sí está consumiendo CPU durante un período prolongado, básicamente está invocando algo en Windows y Windows está dando vueltas en círculos con ello. Un ejemplo sería como si mcebuddy le pidiera a Windows que enumerara todos los archivos en el directorio y por alguna razón Windows tarda mucho en hacerlo (normalmente eso sucedería cuando el disco está muy ocupado). Dado que en su caso el disco no está ocupado, necesitaría ver dónde está gastando todos sus ciclos de CPU.

Intente esto, inicie MCEBuddy y las conversiones, pero presione el botón de pausa. Luego, la única CPU que debería consumirse es la del escaneo. Cómo se comporta entonces me dirá algo nuevo, si las conversiones en sí están teniendo un impacto en el escaneo. Por sus registros puedo ver que solo tiene una conversión activa.

7

Gracias, Goose.

Lo intenté de nuevo e hice clic en Iniciar y luego en Pausar tan pronto como se inició el servicio MCEBuddy2x. Windows Defender está activo, pero las carpetas de origen están configuradas como exclusión y también desactivé la Protección en Tiempo Real antes de iniciar el servicio MCEBuddy2x. Desafortunadamente, obtuve el mismo resultado. El escaneo aún tardó unos 48 minutos.

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

El mcebuddy.log se encuentra en la carpeta “scan - check history on, conversion paused” bajo mi nombre de usuario en el servidor FTP.

¿Hay alguna manera de habilitar el registro de depuración adicional para ver exactamente en qué parte de las consultas de archivos está esperando más tiempo el servicio MCEBuddy?

8

De acuerdo, pudimos investigar esto más a fondo y replicar el problema que estás experimentando. Resultó que el archivo de historial estaba causando el cuello de botella en algunos casos al volver a escanear las carpetas después del escaneo inicial, cuando el archivo de historial crece más allá de cierto tamaño. Hemos reelaborado esto en nuestras pruebas y estamos viendo un aumento de rendimiento de 50x a 100x ahora para los escaneos posteriores. El escaneo inicial después de hacer clic en el botón de inicio llevará tiempo, ya que extrae metadatos de cada archivo además de escanear el directorio, lo cual es un proceso lento. Gracias por reportar esto.

Prueba la compilación beta 2.7.1 de hoy y dime qué tal va.

9

¡Lo arreglaste, @Goose! :clap: :partying_face: ¡Son héroes! :smiling_face_with_three_hearts:

El escaneo ahora tarda 26 segundos, menos de 49 minutos. ¡Definitivamente puedo vivir con eso! ¡Esta es la vez más rápida que ha sido desde que configuré esto hace 3 años!

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

Supongo que mi configuración es un caso extremo, o al menos la primera vez que alguien la configura de esta manera con una colección grande y se queja del rendimiento. De todos modos, me alegro de que hayan podido mejorar el producto y estoy muy contento con mi configuración de nuevo. ¡Un brindis por ti y por los otros desarrolladores que hicieron esto posible! :clinking_beer_mugs:

10

He eliminado mis registros del servidor FTP.