5% de uso de CPU en reposo con el servicio ni siquiera ejecutándose
15-20 en reposo con el servicio ejecutándose
Este es un i7 de 8 núcleos de 9ª generación y está consumiendo un 20% en reposo?
La versión es 2.5 Beta 5 (sí, puedo actualizar pero si no hubo cambios relacionados con esto no veo el punto actualmente)
Estoy viendo lo mismo. Un volcado de hilo del problema en MCE Buddy usando el Process Explorer de Sysinternals parece mostrar que está bloqueado en algún tipo de conexión de red o búsqueda de DNS (por algo que no existirá en DNS, ¿como otro proceso en localhost u otro host en la LAN interna?). Obtengo este uso de CPU inexplicablemente alto además de “no se puede conectar al servidor”, y anoté los detalles en otro hilo.
Ahora si alguien con conocimiento sobre esto pudiera compartirlo.
Gracias por reportar esto. He replicado el problema y aislado la causa raíz. Está ocurriendo cuando el cliente GUI intenta determinar si se está ejecutando localmente o en una máquina remota (Windows termina realizando una búsqueda DNS de su nombre de host, lo que está causando un uso excesivo de CPU). Estamos trabajando en una solución.
El problema de la CPU se ha solucionado en la versión BETA 2.5.6 de hoy
Gracias, amigo, lo intentaré.
Puedo confirmar que está corregido en la versión beta 2.5.6 del 27-04-2021.
Tendré que discrepar :\
Supongo que algo de mejora… ya no promedia ~20, pero ahora oscila entre 10 y 16.
Edit: Después de sentarme a observar el proceso por unos minutos, parece haber un patrón. Se dispara y se mantiene durante un minuto o minuto y medio, luego cae a cero durante unos 10 segundos. Y repite eso una y otra vez. Así que parece que está intentando hacer algo, se agota el tiempo, y luego reintenta a los pocos segundos.
Intenta ejecutar SysInternals Process Explorer (descarga directamente desde Microsoft.com) y copia/pega el stack de hilos del hilo que está consumiendo CPU.
Sí, puedo si es necesario. Espero que los síntomas les arrojen algo de luz sobre el problema.
Supongo que por ahora simplemente mataré el servicio y lo iniciaré cuando haya un acumulado. En cierto modo anula el propósito, pero no cuando está consumiendo el uso así.
No veo que el servicio use ninguna CPU cuando está inactivo. ¿Has intentado desactivar la configuración de UPnP y el firewall?
Nunca estuvieron habilitados, amigo. Revisé cuando enviaste la captura de pantalla y ya estaban desmarcadas.
No puedo replicar el problema aquí, ¿estás monitoreando alguna carpeta de red?
Podría ayudar usar la herramienta mencionada por @mike808 para aislar exactamente dónde está gastando su tiempo de CPU, lo que podría dar pistas sobre los próximos pasos.
clr.dll!LogHelp_NoGuiOnAssert+0x5e8c9
clr.dll!LogHelp_NoGuiOnAssert+0x5e206
clr.dll!LogHelp_NoGuiOnAssert+0x5e3e8
clr.dll!LogHelp_NoGuiOnAssert+0x431a8
clr.dll!LogHelp_NoGuiOnAssert+0x43e06
clr.dll!LogHelp_NoGuiOnAssert+0x5b71c
clr.dll!LogHelp_NoGuiOnAssert+0x5c25f
clr.dll!LogHelp_NoGuiOnAssert+0x5c173
clr.dll!LogHelp_NoGuiOnAssert+0x5dfb7
clr.dll!LogHelp_NoGuiOnAssert+0x60207
clr.dll!LogHelp_NoGuiOnAssert+0x40108
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.String.InternalSubString+0x24
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ParseSetting+0x102
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.Parse+0x1b6
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ReadFromString+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Util.dll!MCEBuddy.Util.Ini..ctor+0x57
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.CheckAndAddFile+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.ScanForFiles+0xdf8
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.RunInternal+0x172
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x15
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x55
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ThreadHelper.ThreadStart+0x55
[Unmanaged to Managed Transition]
clr.dll!LogHelp_TerminateOnAssert+0x1b93
clr.dll!LogHelp_TerminateOnAssert+0x1aa4
clr.dll!LogHelp_TerminateOnAssert+0x2358
clr.dll!MetaDataGetDispenser+0x12a2f
clr.dll!LogHelp_TerminateOnAssert+0x2f50
clr.dll!LogHelp_TerminateOnAssert+0x2ec3
clr.dll!LogHelp_TerminateOnAssert+0x2e02
clr.dll!LogHelp_TerminateOnAssert+0x2fe7
clr.dll!MetaDataGetDispenser+0x12919
clr.dll!LogHelp_TerminateOnAssert+0x6835
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Así que esto es hacer clic en “Stack” en la pestaña “Threads” del explorador, que asumo es a lo que te refieres. Esto fue estando inactivo y usando ~16%
La ruta que monitorea está ubicada como parte de Drivepool. D:/MCEBuddy donde D es una instancia de drivepool. Sin embargo, las unidades del grupo están todas conectadas a la misma máquina, así que no, no es a través de una red con monitoreo.
Raro. Parece que está analizando el archivo de configuración para algo, y luego está haciendo algo que quizá requiera UAC o algún tipo de entrada del usuario pero no puede.
¿Podría ser algún problema de juego de caracteres o codificación? @AustinWBest ¿tienes configurado un teclado internacional, opciones del sistema de archivos, o quizá las rutas de archivo tienen caracteres de “comillas tipográficas” u otros caracteres no estadounidenses? ¿Se han establecido los valores predeterminados? Solo para descartar que no esté intentando obtener una selección del usuario que no puede, ya que Windows no puede obtener entrada de consola en algunos casos (principalmente controladores, pero puede que no sea esa la situación).
No causa problemas con mi MCEBuddy, pero a menudo aparecen con apóstrofes en ellos (“Cocina de Cook” o “Rory O’Connell”) que se analizan con una comilla simple de cierre en lugar de un apóstrofe (o viceversa), y terminan en directorios y nombres de archivo diferentes. También afecta los metadatos, pero eso es menor.
Quizá tus carpetas en el drivepool estén usando un juego de caracteres diferente al del archivo de configuración o esté ocurriendo algo igualmente extraño.
@Goose tendría que investigar si el uso de DrivePool cambia algo (¿las APIs?) que MCEBuddy necesita usar si esa es la fuente del problema. No uso DrivePool, así que no tengo comentarios al respecto.
Verifica tu archivo History, archivo manual y otros archivos de configuración de MCEBuddy. Uno de ellos puede estar dañado. Comienza borrando los archivos de historial y manual (simplemente elimínalos) y si eso no lo soluciona, entonces puede que necesites una instalación limpia.