5 % CPU-Auslastung im Leerlauf, obwohl der Dienst gar nicht läuft
15–20 % im Leerlauf, wenn der Dienst läuft
Das ist ein 8-Kern-i7 der 9. Generation, und er verbraucht 20 % im Leerlauf?
Version ist 2.5 Beta 5 (ja, ich könnte updaten, aber wenn sich daran nichts geändert hat, sehe ich gerade keinen Grund dafür).
Ich sehe dasselbe. Ein Thread-Dump des betreffenden Threads in MCE Buddy mit dem Process Explorer von Sysinternals scheint zu zeigen, dass er in einer Art Netzwerkverbindung oder DNS-Lookup feststeckt (für etwas, das nicht in DNS existiert, wie ein anderer Prozess auf localhost oder ein anderer Host im internen LAN?). Ich erhalte diese unerklärlich hohe CPU-Auslastung zusätzlich zu „kann keine Verbindung zum Server herstellen“ und habe die Details in einem anderen Thread beschrieben.
Wenn nur jemand mit Einblick dazu seinen Teil davon teilen würde.
Danke fürs Melden. Ich konnte das Problem reproduzieren und die Ursache isolieren. Es tritt auf, wenn der GUI-Client versucht zu bestimmen, ob er lokal oder auf einem Remote-Rechner läuft (Windows führt dabei eine DNS-Abfrage für seinen Hostnamen durch, was zu übermäßiger CPU-Auslastung führt). Wir arbeiten an einer Lösung.
Das CPU-Problem wurde im heutigen 2.5.6-BETA-Release behoben
Danke, Kumpel, ich werde es versuchen.
Kann bestätigen, dass es in 2.5.6 BETA vom 27.04.2021 behoben wurde.
Muss widersprechen :\
Ich schätze, es gibt einige Verbesserung… Ich habe nicht mehr durchschnittlich ~20, sondern schwankt jetzt zwischen 10-16
Bearbeitung: Nachdem ich ein paar Minuten zugesehen habe, scheint es ein Muster zu geben. Es schießt hoch und bleibt für eine Minute oder eineinhalb Minuten, fällt dann für etwa 10 Sekunden auf null. Dann wiederholt sich das immer wieder. Es scheint also, dass es versucht, etwas zu tun, läuft in ein Timeout und versucht es ein paar Sekunden später erneut?
Versuchen Sie, den SysInternals Process Explorer (direkt von Microsoft.com herunterladen) auszuführen und den Thread-Stack des Threads, der die CPU auslastet, zu kopieren/einfügen.
Ja, ich kann das, falls nötig. Ich hoffe, die Symptome werfen etwas Licht auf das Problem für sie.
Ich werde den Service wohl vorerst einfach beenden und bei Stau wieder starten. Macht die Idee irgendwie zunichte – aber nicht, wenn er so fleißig mein Kontingent verbraucht.
Ich sehe, dass der Dienst im Leerlauf keine CPU nutzt. Hast du versucht, die UPnP- und Firewall-Einstellungen zu deaktivieren?
Sie waren nie aktiviert, Kumpel. Ich habe nachgeschaut, als du den Screenshot geschickt hast, und sie waren bereits deaktiviert.
Ich kann das Problem hier nicht reproduzieren, überwachen Sie Netzwerkordner?
Es könnte helfen, das von @mike808 erwähnte Tool zu verwenden, um genau zu isolieren, wo es seine CPU-Zeit verbringt, was Hinweise auf die nächsten Schritte geben könnte
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
Das ist also ein Klick auf „Stack“ im Tab „Threads“ des Explorers, was ich annehme, ist das, worauf Sie sich beziehen. Dies entstand im Leerlauf bei etwa 16 % Auslastung.
Der überwachte Pfad befindet sich als Teil von Drivepool. D:/MCEBuddy, wobei D eine Drivepool-Instanz ist. Die Laufwerke im Pool sind jedoch alle an denselben Rechner angeschlossen, also nein, es handelt sich nicht um eine Netzwerküberwachung.
Seltsam. Sieht so aus, als würde es die Konfigurationsdatei nach etwas durchsuchen und dann etwas tun, das möglicherweise UAC oder eine Art Benutzereingabe erfordert, aber nicht kann.
Könnte es ein Zeichensatz- oder Kodierungsproblem sein? @AustinWBest – verwendest du eine internationale Tastatur, Dateisystemoptionen oder haben die Dateipfade vielleicht „schlaue Anführungszeichen“ oder andere Nicht-US-Zeichen? Sind die Standardwerte gesetzt? Nur um auszuschließen, dass nicht versucht wird, eine Auswahl vom Benutzer zu holen, die nicht möglich ist, da Windows in manchen Fällen keine Konsoleneingabe entgegennehmen kann (hauptsächlich Treiber, aber das ist hier vielleicht nicht der Fall).
Bei meinem MCEBuddy verursacht es kein Problem, aber oft werden Titel mit Apostroph („Cook’s Kitchen“ oder „Rory O’Connell“) mit einem schließenden einfachen Anführungszeichen statt einem Apostroph geparst (oder umgekehrt) und landen dann in anderen Verzeichnissen und Dateinamen. Die Metadaten betrifft das auch, ist aber nebensächlich.
Möglicherweise verwenden deine Ordner auf dem DrivePool einen anderen Zeichensatz als die Konfigurationsdatei, oder es passiert etwas ähnlich Merkwürdiges.
@Goose müsste herausfinden, ob die Verwendung von DrivePool Dinge ändert (die APIs?), die MCEBuddy benötigt, falls das die Ursache des Problems ist. Ich verwende kein DrivePool, also kann ich dazu nichts sagen.
Überprüfe deine History-Datei, manual-Datei und andere MCEBuddy-Konfigurationsdateien. Eine von ihnen könnte beschädigt sein. Beginne damit, die History- und Manual-Dateien zu löschen (einfach entfernen), und wenn das nicht hilft, mus du möglicherweise eine saubere Neuinstallation durchführen.