Høj CPU-udnyttelse i tomgang i service

5 % CPU-brug i tomgang uden at tjenesten overhovedet kører
15-20 % i tomgang med tjenesten kørende

Det her er en 8-kerne 9. gen i7, og den æder 20 % i tomgang?

Versionen er 2.5 Beta 5 (ja, jeg kan opdatere, men hvis der ikke er ændret noget i forhold til dette, ser jeg ikke pointen lige nu)

Jeg ser det samme. En tråd-dump af den problematiske tråd i MCE Buddy ved hjælp af Sysinternals’ Process Explorer viser, at den er låst i en form for netværksforbindelse eller DNS-opslag (efter noget, der ikke findes i DNS, som f.eks. en anden proces på localhost eller en anden vært på det interne LAN?). Jeg oplever denne uforklarligt høje CPU-brug samt “kan ikke oprette forbindelse til server”, og jeg har beskrevet detaljerne i en anden tråd.

Nu hvis bare nogen med indsigt i dette ville dele noget af den.

Prøv at deaktivere UPnP- og fjernadgangsfunktionerne. Det er Windows’/tredjeparts firewallen, der forårsager problemet.

Tak for at have rapporteret dette. Jeg har genskabt problemet og isoleret den grundlæggende årsag. Det sker, når GUI-klienten forsøger at afgøre, om den kører lokalt eller på en fjernmaskine (Windows foretager en DNS-opslag på sit værtsnavn, hvilket forårsager overdreven CPU-brug). Vi arbejder på en løsning.

CPU-problemet er blevet løst i dagens 2.5.6 BETA-udgivelse

Tak, ven, jeg vil give det et forsøg.

Kan bekræftes rettet i 2.5.6 BETA fra 2021-04-27.

Er nødt til at være uenig :\

Jeg gætter på, der er en smule forbedring… jeg ligger ikke længere og gennemsnitligt ~20, men nu svinger det mellem 10-16.

Edit: Efter at have stået og kigget på processen i et par minutter, ser der ud til at være et mønster. Den springer op og holder i et minut eller halvandet, falder så helt ned til ingenting i cirka 10 sekunder og gentager det igen og igen. Det ligner altså, at den forsøger at gøre noget, timouter, og prøver så igen et par sekunder senere?

Prøv at køre SysInternals Process Explorer (download direkte fra Microsoft.com) og kopier/indsæt thread-stakken fra den tråd, der bruger CPU.

Ja, det kan jeg, hvis det er nødvendigt. Jeg håber, at symptomerne kaster lys over problemet for dem.

Jeg gætter på, at jeg indtil videre bare slukker for servicen og starter den igen, når der er en opbakning. Det undergraver lidt formålet, men ikke når den sluger forbrug på denne måde.

Jeg kan ikke se, at tjenesten bruger nogen CPU, når den er inaktiv. Har du prøvet at deaktivere UPnP- og firewallindstillingerne?

De var aldrig aktiveret, ven. Jeg tjekkede, da du sendte skærmbilledet, og de var allerede fravalgt.

Jeg kan ikke genskabe problemet her, overvåger du nogen netværksmapper?

Det kan hjælpe at bruge det værktøj, som @mike808 nævnte, til at isolere, hvor det præcist bruger sin cpu-tid, hvilket kan give fingerpeg om de næste skridt.

Det er at klikke på “Stack” i “Threads” fanen i exploreren, som jeg antager du henviser til. Dette var fra at sidde idle og bruge ~16%.

Den sti den overvåger er placeret som en del af Drivepool. D:/MCEBuddy hvor D er en drivepool instans. Dog er drevene i poolen alle tilsluttet samme maskine, så nej, det er ikke overvågning på tværs af et netværk.

Mærkeligt. Det ligner, at den parser konfigurationsfilen efter noget og derefter gør noget, der måske kræver UAC eller en form for brugerinput, men som ikke kan få det.

Kan det være et tegnsæt- eller kodningsproblem? @AustinWBest – har du et internationalt tastatur, filsystemindstillinger, eller måske indeholder stierne “smarte anførselstegn” eller andre ikke-US-ASCII-tegn? Er standarderne blevet sat? Bare for at udelukke, at den ikke forsøger at få et valg fra brugeren, som den ikke kan, da Windows ikke kan hente konsolinput i visse tilfælde (hovedsageligt drivere, men dette er måske ikke den situation).

Det giver ikke problemer med min MCEBuddy, men ofte vises navne med apostroffer i dem (“Cook’s Kitchen” eller “Rory O’Connell”), som bliver parset med en enkelt lukket anførselstegn i stedet for en apostrof (eller omvendt), og ender i forskellige mapper og filnavne. Det påvirker også metadata, men det er mindre vigtigt.

Måske bruger dine mapper på drivepoolen et andet tegnsæt end konfigurationsfilen, eller der foregår noget lignende underligt.

@Goose må undersøge, om brug af DrivePool ændrer noget (API’er?) som MCEBuddy skal bruge, hvis det er kilden til problemet. Jeg bruger ikke DrivePool, så ingen feedback der.

Tjek din History-fil, manual-fil og andre MCEBuddy-konfigurationsfiler. En af dem kan være beskadiget. Start med at rydde history- og manual-filerne (slet dem bare), og hvis det ikke løser problemet, kan det være nødvendigt med en ren installation.