Scan/Vergleich Leistungsproblem

Allgemeiner Support / Fragen
1

Hallo! Ich benutze MCEBuddy seit einigen Jahren. Ich verwende derzeit MCEBuddy Premium 2.6.6.

Ich verwende MCEBuddy, um Quellverzeichnisse (die ich auf der lokalen Festplatte eines PCs mit MCEBuddy pflege) und Zielverzeichnisse (die sich auf einem Dateiserver befinden und über SMB zugänglich sind) synchronisiert zu halten, indem ich die Optionen „Konvertierung überspringen“ und „Verlauf prüfen“ verwende. Die Zielverzeichnisse auf dem Dateiserver werden verwendet, um konvertierte Medien an Clients bereitzustellen. MCEBuddy ist so konfiguriert, dass Dateien aus bestimmten Quellverzeichnissen konvertiert werden, und aus anderen einfach repliziert werden, ohne sie zu konvertieren (mithilfe der Option „Umbenennen ohne Konvertierung“). Die Hauptsache hierbei ist, dass die Quellverzeichnisse niemals geleert werden; Dateien „leben“ die ganze Zeit in den Quellverzeichnissen, und Änderungen werden in die „sichtbaren“ Verzeichnisse auf dem Dateiserver repliziert, wenn sich die Quellverzeichnisse ändern. Ich habe derzeit 9.589 Dateien in den Quellverzeichnissen.

Das alles funktioniert. Mein Problem ist, dass die Scan-Leistung miserabel ist und mit der Zunahme der Dateien immer schlechter wird. Der anfängliche Durchlauf der Verzeichnisbäume und das Erstellen der Dateiliste ist recht schnell, es werden alle Dateien in etwa 22 Sekunden gefunden und bis zu 1.000 Dateien pro Sekunde verarbeitet. (Während dieser Phase sehe ich die Dateien in mcebuddy.log als „xxx wird auf Synchronisierung mit Ausgabedatei überwacht“ aufgeführt.) Die Analyse der Dateien und der Vergleich mit dem, was sich in der Verlaufsdatei befindet, dauert jedoch weitere 49 Minuten und verarbeitet nur 3 bis 4 Dateien pro Sekunde. (Zu diesem Zeitpunkt sehe ich die Dateien in mcebuddy.log als „xxx bereits mit Status Konvertiert konvertiert“ aufgeführt.) Dieser Vorgang scheint hauptsächlich CPU-gebunden zu sein, da MCEBuddy.Service.exe durchschnittlich 24–25 % CPU-Auslastung auf einem 4-Kern-System (offensichtlich kein Biest, mit einem Intel Core i5-7600 @ 3,5 GHz und 16 GB RAM) aufweist. Wenn ich die CPU-Affinität für diesen Prozess auf einen CPU-Kern festlege, verwendet er 100 % dieses Kerns. Natürlich kenne ich die Interna von MCEBuddy nicht, aber ich muss mir vorstellen, dass dieser ganze CPU-Overhead darauf zurückzuführen ist, dass MCEBuddy die Dateien im Quellverzeichnisbaum mit den Einträgen in der Verlaufsdatei vergleicht, die zu diesem Zeitpunkt 7,36 MB groß ist. Ich weiß genug, um zu erkennen, dass eine INI-Datei dieser Größe sehr teuer in der Analyse ist. Also habe ich versucht, die Option „Verlauf prüfen“ in allen meinen Konvertierungsaufgaben zu deaktivieren, in der Annahme, dass MCEBuddy dadurch die Verlaufsdatei ignoriert und nur prüft, ob die Zieldateiname auf dem Server für jeden Quelldateinamen auf dem lokalen Laufwerk existiert. Aber das hat die Leistungseigenschaften überhaupt nicht verändert; es hat dem Scan sogar 12 Sekunden hinzugefügt (obwohl diese Abweichung im Kontext so gering ist, dass die Einstellungsänderung irrelevant sein könnte).

Ich habe Process Monitor verwendet, um zu untersuchen, was vor sich geht, und selbst wenn „Verlauf prüfen“ deaktiviert ist, sehe ich, wie MCEBuddy.Service.exe jede Quelldatei einmal überprüft und buchstäblich Hunderte von Lesevorgängen auf der Verlaufsdatei für jede einzelne durchführt, aber den Dateiserver überhaupt nicht berührt. Ich schätze, es ist sinnvoll, dass es die Verlaufsdatei trotzdem lesen muss, um herauszufinden, was der Zielpfad der Datei ist, aber ich hatte hier eine Verhaltensänderung erwartet. Unabhängig davon scheint dies nicht mein Allheilmittel zu sein.

Können Sie andere Einstellungsänderungen vorschlagen, die die Leistung verbessern könnten, oder stoße ich gerade an die praktischen Grenzen der Architektur von MCEBuddy? Ich stelle mir vor, dass eine solche Nutzung mit einer echten Datenbank (z. B. SQLite) viel besser funktionieren würde, und ich denke, die Verlaufsdatei ist hier der Engpass, aber ich bin offen für Vorschläge.

Ich habe bereits versucht, die Verlaufsdatei neu zu erstellen (Verlauf anzeigen → Verlauf löschen, sicherstellen, dass „C:\\Program Files\\MCEBuddy2x\\config\\history“ nicht mehr vorhanden ist, den MCEBuddy2x-Dienst neu gestartet, die Konvertierung gestartet und zugelassen, dass er sich neu aufbaut). Das hat auch keinen Unterschied gemacht.

Ich habe MCEBuddy-Protokolle auf den FTP-Server hochgeladen, in zwei Unterverzeichnissen: „scan - check history“ und „scan - no check history“. Um jedes zu erstellen, habe ich die Einstellungen aktualisiert, den MCEBuddy2x-Dienst gestoppt, mcebuddy.log gelöscht, den Dienst gestartet, Konvertierungen gestartet, gewartet, bis das Scannen abgeschlossen war, und den MCEBuddy2x-Dienst gestoppt, sodass jedes Protokoll sehr sauber sein sollte.

Verlauf prüfen aktiviert: 14:18:20 - 15:08:06 = 49m:46s
Verlauf prüfen deaktiviert: 13:09:50 - 13:59:48 = 49m:58s

Danke fürs Lesen!

2

Hi toasterking, danke für die ausführliche Problembeschreibung und die Protokolle. Es klingt so, als wärst du bei der Historiendatei auf einen Leistungsengpass gestoßen, insbesondere bei einer so großen Anzahl von Dateien.

Du hast recht mit der Annahme, dass das INI-Dateiformat für die Historie bei einer sehr großen Anzahl von Einträgen ineffizient werden kann. Zwar kann ich die Architektur der Software nicht direkt so ändern, dass eine Datenbank verwendet wird, aber lass uns mal schauen, ob es andere Einstellungen oder Workarounds gibt, die helfen könnten.

Angesichts deines Anwendungsfalls, bei dem Quellverzeichnisse niemals geleert werden und du im Wesentlichen Änderungen synchronisierst, sind die Optionen „Konvertierung überspringen“ und „Historie prüfen“ von entscheidender Bedeutung. Die Auswirkungen auf die Leistung, die du feststellst, sind jedoch beträchtlich.

Probieren wir doch mal, einige alternative Ansätze zu untersuchen oder bestimmte Annahmen zu bestätigen:

  1. „Konvertierung überspringen“ bei deaktivierter „Historie prüfen“: Du hast erwähnt, dass das Deaktivieren von „Historie prüfen“ nicht geholfen hat. Meinem Verständnis nach stützt sich „Konvertierung überspringen“ auf die Historiendatei, um zu wissen, ob eine Datei bereits konvertiert wurde und wie ihr Zielort war. Selbst wenn also „Historie prüfen“ explizit deaktiviert ist, fragt das System möglicherweise immer noch die Historiendatei für die Logik von „Konvertierung überspringen“ ab. Dies würde erklären, warum du immer noch hunderte von Lesevorgängen in der Historiendatei siehst.

  2. Optimierung der Historiendatei: Besteht irgendeine Möglichkeit, die Historiendatei zu archivieren oder aufzuteilen, wenn bestimmte Quellverzeichnisse „stabil“ sind und sich selten ändern? Wenn du ältere, statische Inhalte hast, die nicht ständig überprüft werden müssen, könnten diese Einträge vielleicht in eine separate, seltener aufgerufene Historiendatei verschoben werden. Das ist eher ein manueller Workaround, könnte aber die Größe der aktiv geparsten Historie reduzieren.

  3. Alternative Synchronisationsmethoden: MCEBuddy ist zwar hervorragend für Konvertierungen geeignet, aber für eine reine Dateisynchronisation, insbesondere bei einem so großen Datensatz, sind spezialisierte Dateisynchronisationstools möglicherweise effizienter. Dies würde jedoch bedeuten, dass du deine Konvertierungs- und Synchronisations-Workflows trennen musst, was für dein Setup vielleicht nicht ideal ist.

Könntest du klarstellen, ob ähnliche Leistungsprobleme auftreten, wenn du zusätzlich zu „Historie prüfen“ auch „Konvertierung überspringen“ vorübergehend deaktivierst (natürlich an einem Testset, um unnötige Rekonvertierungen zu vermeiden)? Dies würde uns helfen zu isolieren, ob die Logik von „Konvertierung überspringen“ stark vom Parsen der Historiendatei abhängt.

Hast du außerdem schon in Betracht gezogen, eine leistungsstärkere CPU oder eine SSD für die MCEBuddy-Installation und den Speicherort der Historiendatei zu verwenden, falls diese sich derzeit auf einer HDD befindet? Zwar löst dies möglicherweise nicht den architektonischen Engpass, aber es könnte etwas von der I/O- und Verarbeitungs-Overhead entlasten.

Ich werde auch im Forum suchen, um zu sehen, ob andere Benutzer ähnliche Leistungsprobleme mit großen Historiendateien hatten oder Workarounds gefunden haben.

Es hört sich so an, als hättest du eine gründliche Untersuchung des Leistungsengpasses durchgeführt, und deine Beobachtungen bezüglich der Größe der Historiendatei und ihrer Auswirkungen auf die Scan-Leistung sind sehr aufschlussreich. Es ist durchaus möglich, dass MCEBuddy bei fast 10.000 Dateien und einer 7,36 MB großen Historiendatei an die Grenzen seiner aktuellen Architektur stößt, insbesondere wenn die INI-Datei wiederholt geparst wird.

Da das Deaktivieren von „Historie prüfen“ das Verhalten nicht wesentlich verändert hat und du nach wie vor zahlreiche Lesevorgänge auf der Historiendatei siehst, bestärkt dies deine Hypothese, dass die Historiendatei selbst das Kernproblem ist.

Zwar kann ich keine direkten internen architektonischen Änderungen wie den Wechsel zu einer SQLite-Datenbank vorschlagen, aber ich kann einige allgemeine Schritte zur Fehlerbehebung und Überlegungen anbieten, die vielleicht helfen oder zumindest mehr Daten liefern:

  1. Die mcebuddy.log genauer untersuchen: Du hast bereits großartige Arbeit bei der Verwendung der Protokolle geleistet, aber manchmal kann ein tieferer Einblick subtile Muster offenbaren. Achte auf wiederkehrende Fehler oder Warnungen während der Phase des „Parsens und Vergleichens“. Gibt es bestimmte Dateien oder Dateitypen, deren Verarbeitung länger zu dauern scheint?
  2. Die Anzahl der überwachten Dateien temporär reduzieren: Könntest du als Test vorübergehend die Anzahl der Quellverzeichnisse oder Dateien reduzieren, die MCEBuddy überwacht? Wenn die Scan-Zeit proportional sinkt, würde dies weiter bestätigen, dass die Anzahl der Dateien und die Größe der Historiendatei die Haupttreiber des Leistungsproblems sind.
  3. Festplatten-I/O überwachen: Zwar hast du die CPU-Auslastung erwähnt, aber es lohnt sich, die Festplatten-I/O während der Phase des „Parsens und Vergleichens“ zu überprüfen. Wenn die Historiendatei pro Datei hunderte Male gelesen wird, kann es selbst mit Caching eine erhebliche Festplatten-I/O-Komponente geben, insbesondere wenn das Laufwerk keine SSD ist. Der Process Monitor kann dir Lese-/Schreiboperationen auf der Historiendatei anzeigen.
  4. In Betracht ziehen, Aufgaben aufzuteilen: Könntest du deine 9.589 Dateien, falls möglich, in mehrere kleinere Sets aufteilen und separate MCEBuddy-Aufgaben für jedes erstellen? Das würde zwar das zugrundeliegende Problem mit der Historiendatei nicht lösen, aber es könnte MCEBuddy ermöglichen, kleinere Häppchen effizienter zu verarbeiten, wodurch möglicherweise die Auswirkungen des wiederholten Parsens einer einzelnen großen Historiendatei verringert werden. Du könntest diese Aufgaben dann so planen, dass sie nacheinander ablaufen.
  5. Nach MCEBuddy-Updates suchen: Du hast erwähnt, dass du MCEBuddy Premium 2.6.6 verwendest. Es ist immer eine gute Idee sicherzustellen, dass du die absolut neueste verfügbare Version hast. Auch wenn eine größere architektonische Änderung vielleicht nicht in einem kleineren Update enthalten ist, sind Leistungsoptimierungen oft darin enthalten.
  6. Direkt den MCEBuddy-Support kontaktieren: Angesichts deiner detaillierten Analyse und der Protokolle, die du auf deren FTP-Server hochgeladen hast, empfehle ich dringend, dich direkt an die offiziellen Support-Kanäle von MCEBuddy zu wenden. Sie haben den besten Einblick in die internen Abläufe der Anwendung und können bestätigen, ob du für deinen spezifischen Anwendungsfall tatsächlich die Grenzen ihres aktuellen Designs ausreizt. Möglicherweise haben sie auch Beta-Versionen mit Leistungsverbesserungen oder spezifische Empfehlungen für große Bibliotheken.

Es ist offensichtlich, dass du viel Mühe in die Diagnose gesteckt hast, und deine Erkenntnisse sind wertvoll. Ich hoffe, diese Vorschläge helfen dir dabei, entweder einen Workaround zu finden oder eine definitive Antwort von den MCEBuddy-Entwicklern zu erhalten.

3

Wow, was für eine große Hilfe dieser Bot ist. Er hat im Grunde diese Optionen vorgeschlagen:

  1. Eine schnellere CPU bekommen (was bestenfalls nur eine vorübergehende Lösung ist, da die CPU-Anforderung mit der INI-Länge exponentiell steigen wird).
  2. Den gesamten Medienserver-Ansatz ändern, damit er besser zu MCEBuddy passt.
  3. MCEBuddy neu gestalten. (Nein, der Quellcode ist sowieso nicht offen.)
  4. Änderungen vornehmen, die dazu führen würden, dass MCEBuddy nicht mehr funktioniert, was Punkt 3 erforderlich machen würde.
  5. Dinge untersuchen, die ich bereits untersucht habe.

Ich würde lieber meine eigene Anwendung schreiben, als eine dieser Optionen zu wählen. Ich werde das vielleicht tun, aber ich hoffe, dass ich MCEBuddy weiterhin für meinen Workflow nutzen kann!

4

Interessantes Setup. Wir haben MCEBuddy hier in unseren Laboren mit bis zu 500.000 Dateien in einer Verzeichnisstruktur getestet und dabei keine besondere Leistungsverschlechterung beim Scannen der Dateien festgestellt.

Ich werde versuchen, einige Ihrer Fragen zu beantworten.

  • Wenn Sie die CPU-Affinität begrenzen oder die CPU-Priorität auf der Statusseite ändern, wirkt sich dies nur auf die eigentlichen Konvertierungen und nicht auf die Haupt-Engine aus, die Dateien scannt, den Gesamtstatus der Konvertierungen überwacht, die GUI usw. handhabt. Wenn Sie also die CPU begrenzen, verlangsamt dies die Konvertierungen, aber die Haupt-Engine sollte weiterhin mit voller Geschwindigkeit arbeiten.
  • Die INI-Dateidatenbank ist sehr hoch optimiert und auf Leistung und Skalierbarkeit abgestimmt, und wir haben damit keine Probleme mit über einer Million Einträgen festgestellt (daher sollte auch die Verlaufdatei keinen Overhead verursachen).

Wenn ich aufgrund meiner Erfahrung raten müsste, würde ich auf Ihre Festplatte als wahrscheinliches Nadelöhr tippen. Da Sie nur Umbenennungen durchführen, ist dies im Grunde sehr wenig CPU-, aber SEHR viel Festplattenaktivität. Während die Konvertierungsaufgabe also damit beschäftigt ist, Dateien von einer Festplatte auf eine andere zu kopieren und zu verschieben, versucht die Haupt-Engine, die nach neuen Dateien sucht, ebenfalls, die Festplatte zu nutzen, um nach neuen Dateien zu suchen, und dieser Konflikt zwischen den beiden überlastet wahrscheinlich Ihre Festplatte und verlangsamt alles.

Verwenden Sie eine SSD oder eine herkömmliche Spindel-Festplatte?

5

Vielen Dank für Ihre Antwort, Goose!

  • Ich weise normalerweise keine CPU-Affinität zu. Ich habe dies nur als Test getan, um zu sehen, ob MCEBuddy.Service.exe den gesamten CPU-Kern sättigen würde, wenn ich ihm während des Scannens einen Kern zuwiese. Und das tat es.
  • Während meiner Tests fanden keine Konvertierungen statt, da MCEBuddy nur Dateien scannte, die bereits konvertiert/umbenannt worden waren, bereits in der Verlaufdatei existierten und für die bereits konvertierte/umbenannte Dateien am Zielort existierten.
  • Vielleicht haben Sie mich missverstanden, aber ich führe nicht nur eine Umbenennung durch. Einige Konvertierungsaufgaben benennen nur um, andere konvertieren. Jede Aufgabe ist an einen einzigen Überwachungsort gebunden.
  • Ich habe die Festplattenauslastung während des Scannens mit dem Windows Task-Manager überprüft, und nach der 22-sekündigen anfänglichen Dateiaufzählung verbrauchte MCEBuddy für die restlichen 49 Minuten 0-1 % Festplattenzeit, verbrauchte aber 25 % CPU. Auch bei dieser Aufgabe gab es keine Konvertierung und kein Umbenennen/Kopieren. MCEBuddy scannte nur Dateien, die bereits konvertiert/umbenannt worden waren, bereits in der Verlaufdatei existierten und für die bereits konvertierte/umbenannte Dateien am Zielort existierten. Windows und MCEBuddy sind auf einer SSD installiert, aber die zu verarbeitenden Mediendateien befinden sich auf einer herkömmlichen Festplatte. Aber wenn die Festplatte der Engpass wäre, würde ich eine hohe Festplattenauslastung und eine niedrige CPU-Auslastung im Task-Manager erwarten, aber stattdessen sehe ich das Gegenteil. Es wurden nur 3 bis 4 Dateien pro Sekunde verarbeitet, und nichts gelangte in die Konvertierungswarteschlange.
  • Ich habe vergessen, es vorher zu erwähnen, aber ich habe auch versucht, das Antivirenprogramm auf dem PC und dem Dateiserver zu deaktivieren, und es gab keinen Unterschied in der Leistung.

Wenn Sie glauben, dass das Parsen der INI-Datei definitiv nicht der Engpass ist, werde ich aufhören, mich darauf zu konzentrieren. Aber was macht MCEBuddy.Service.exe mit all dieser CPU-Zeit? Wie kann ich das herausfinden?

6

Das könnte daran liegen, dass es darauf wartet, dass Windows alle Dateien im Verzeichnis aufzählt. Der Dienst sollte für längere Zeit nicht viel CPU beanspruchen. Die CPU sollte hauptsächlich von den anderen Prozessen beansprucht werden, die er verwendet (wie ffmpeg, Handbrake usw.). Wenn der Dienst selbst für längere Zeit CPU beansprucht, ruft er im Grunde etwas in Windows auf, und Windows dreht sich im Kreis. Ein Beispiel wäre, dass MCEBuddy Windows auffordert, alle Dateien im Verzeichnis aufzulisten, und Windows aus irgendeinem Grund sehr lange dafür braucht (was normalerweise passiert, wenn die Festplatte sehr ausgelastet ist). Da Ihre Festplatte in Ihrem Fall nicht ausgelastet ist, müsste man sehen, wo die CPU-Zyklen verbraucht werden.

Versuchen Sie Folgendes: Starten Sie MCEBuddy und die Konvertierungen, aber drücken Sie die Pausentaste. Dann sollte die einzige CPU-Auslastung durch das Scannen entstehen. Wie es sich dann verhält, wird mir etwas Neues verraten, ob die Konvertierungen selbst einen Einfluss auf das Scannen haben. Aus Ihren Protokollen kann ich entnehmen, dass Sie nur eine aktive Konvertierung haben.

7

Danke, Goose.

Ich habe dies erneut versucht und auf Start geklickt, dann auf Pause, sobald der MCEBuddy2x-Dienst gestartet wurde. Windows Defender ist aktiv, aber die Quellordner sind als Ausschluss festgelegt, und ich habe auch den Echtzeitschutz deaktiviert, bevor ich den MCEBuddy2x-Dienst gestartet habe. Leider erhielt ich das gleiche Ergebnis. Das Scannen dauerte immer noch etwa 48 Minuten.

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

Die mcebuddy.log befindet sich im Ordner „scan - check history on, conversion paused“ unter meinem Benutzernamen auf dem FTP-Server.

Gibt es eine Möglichkeit, zusätzliche Debug-Protokollierung zu aktivieren, um genau zu sehen, bei welchem Teil der Dateianfragen der MCEBuddy-Dienst am längsten wartet?

8

Okay, wir konnten dies genauer untersuchen und das Problem, mit dem Sie konfrontiert sind, reproduzieren. Es stellte sich heraus, dass die Historie-Datei in einigen Fällen den Engpass verursachte, wenn die Ordner nach dem ersten Scan erneut gescannt wurden, sobald die Historie-Datei eine bestimmte Größe überschritten hatte. Wir haben in unseren Tests eine Leistungssteigerung von 50x bis 100x bei nachfolgenden Scans festgestellt. Der erste Scan nach dem Klicken auf die Start-Schaltfläche wird einige Zeit in Anspruch nehmen, da er zusätzlich zum Durchsuchen des Verzeichnisses Metadaten aus jeder Datei extrahiert, was ein langsamer Prozess ist. Vielen Dank für diesen Hinweis.

Probieren Sie den heutigen Beta-Build 2.7.1 aus und lassen Sie mich wissen, wie es läuft.

9

Ihr habt es geschafft, @Goose!! :clap: :partying_face: Ihr seid Helden!! :smiling_face_with_three_hearts:

Der Scan dauert jetzt 26 Sekunden, statt 49 Minuten. Damit kann ich definitiv leben! Das ist das Schnellste, seit ich das vor 3 Jahren eingerichtet habe!

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

Ich nehme an, mein Setup ist ein Grenzfall, oder zumindest das erste Mal, dass jemand es auf diese Weise mit einer großen Sammlung eingerichtet und sich über die Leistung beschwert hat. Wie auch immer, ich bin froh, dass ihr das Produkt verbessern konntet, und ich bin wieder sehr zufrieden mit meinem Setup. Prost an dich und die anderen Entwickler, die das möglich gemacht haben! :clinking_beer_mugs:

10

Ich habe meine Protokolle vom FTP-Server entfernt.