5% CPU-gebruik in rust met de service zelfs niet actief
15-20% in rust met de service actief
Dit is een 8-core 9e generatie i7 en hij vreet 20% in rust?
Versie is 2.5 Beta 5 (ja, ik kan updaten maar als er niets is veranderd dat hiermee te maken heeft zie ik momenteel het nut niet in)
Ik zie hetzelfde. Een thread-dump van de problematische thread in MCE Buddy via Sysinternals’ Process Explorer toont dat deze vastzit in een soort netwerkverbinding of DNS-opzoeking (voor iets dat niet in DNS bestaat, zoals een ander proces op localhost of een andere host op het interne LAN?). Ik krijg deze onverklaarbaar hoge CPU-belasting naast “kan geen verbinding maken met server”, en heb de details in een andere thread genoteerd.
Als er nou eens iemand met inzicht hierin zou delen.
Bedankt voor het melden. Ik heb het probleem gereproduceerd en de oorzaak geïsoleerd. Het gebeurt wanneer de GUI-client probeert te bepalen of het lokaal of op een externe machine draait (Windows voert een DNS-opzoeking uit voor zijn hostnaam, wat leidt tot excessief CPU-gebruik). We werken aan een oplossing.
Het CPU-probleem is opgelost in de vandaag verschenen 2.5.6 BETA-release
Bedankt maat, ik zal het proberen.
Kan bevestigen dat het is opgelost in 2.5.6 BETA van 2021-04-27.
Zal het er niet mee eens zijn :\
Ik denk dat er wat verbetering is… Het gemiddelde is niet meer ~20, maar het schommelt nu tussen 10 en 16.
Edit: Nadat ik het proces een paar minuten heb gadegeslagen, lijkt er een patroon te zijn. Het piekt en blijft een minuut of anderhalve minuut hoog, daalt dan tot nul voor ongeveer 10 seconden. Daarna herhaalt het zich keer op keer. Het lijkt er dus op dat het iets probeert, een time-out krijgt, en dan na een paar seconden opnieuw probeert?
Probeer SysInternals Process Explorer te draaien (direct downloaden van Microsoft.com) en kopieer/plak de thread stack van de thread die CPU gebruikt.
Ja, dat kan ik zo nodig. Ik hoop dat de symptomen wat licht werpen op het probleem voor ze.
Ik zal de service voorlopig maar stopzetten en starten wanneer er een achterstand is. Dat gaat een beetje tegen het doel in, maar niet als het zo veel gebruik opslokt.
Ik zie dat de service geen CPU gebruikt in rust. Heb je geprobeerd de UPnP- en firewallinstellingen uit te schakelen?
Ze waren nooit ingeschakeld, maat. Ik controleerde toen je de screenshot stuurde en ze stonden al uitgevinkt.
Ik kan het probleem hier niet reproduceren, controleer je netwerkmappen?
Het kan helpen om de tool te gebruiken die @mike808 noemde om te isoleren waar precies de CPU-tijd wordt besteed, wat mogelijk aanwijzingen geeft voor de volgende stappen
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
Dus dit is wat er gebeurt als ik op “Stack” klik in het tabblad “Threads” van de verkenner, waarvan ik aanneem dat je dat bedoelt. Dit was tijdens het nietsdoen en gebruikte ongeveer 16%
Het pad dat het controleert maakt deel uit van Drivepool. D:/MCEBuddy waar D een drivepool-instantie is. De schijven in de pool zijn echter allemaal op dezelfde machine aangesloten, dus nee, het is geen controle via het netwerk.
Vreemd. Het lijkt alsof het het configuratiebestand ergens voor parseert en vervolgens iets doet dat mogelijk UAC of een andere vorm van gebruikersinvoer vereist, maar dat niet kan.
Zou het een tekenset- of coderingprobleem kunnen zijn? @AustinWBest gebruik je een internationaal toetsenbord, bestandssysteemopties of hebben de bestandspaden misschien “slimme aanhalingstekens” of andere niet-VS-karakters? Zijn de standaardinstellingen ingesteld? Gewoon om uit te sluiten dat het niet probeert een selectie van de gebruiker te krijgen die niet mogelijk is, aangezien Windows in sommige gevallen geen console-invoer kan krijgen (meestal drivers, maar dit is misschien niet die situatie).
Het veroorzaakt geen probleem met mijn MCEBuddy, maar vaak worden items met apostrofs weergegeven (“Cook’s Kitchen” of “Rory O’Connell”) geparseerd met een enkel sluithaakje in plaats van een apostrof (of andersom), en belanden ze in andere mappen en bestandsnamen. Het beïnvloedt ook de metadata, maar dat is minder belangrijk.
Misschien gebruiken je mappen op de drivepool een andere tekensetcodering dan het configuratiebestand, of gebeurt er iets vergelijkbaars raars.
@Goose zou moeten uitzoeken of het gebruik van DrivePool dingen verandert (de API’s?) die MCEBuddy nodig heeft als dat de bron van het probleem is. Ik gebruik geen DrivePool, dus geen feedback daarover.
Controleer je History-bestand, manual-bestand en andere MCEBuddy-configuratiebestanden. Een van hen kan beschadigd zijn. Begin met het wissen van de history- en manualbestanden (gewoon verwijderen) en als dat het probleem niet oplost, dan heb je mogelijk een schone installatie nodig.