Scan/sammenlign ydelsesproblem

Generel support / Spørgsmål
1

Hej! Jeg har brugt MCEBuddy i et par år. Jeg bruger i øjeblikket MCEBuddy Premium 2.6.6.

Jeg bruger MCEBuddy til at holde sæt af kildedirectorier (som jeg vedligeholder på den lokale HDD på en pc, der kører MCEBuddy) og destinationsdirectorier (som er på en filserver og tilgås via SMB) synkroniseret ved hjælp af indstillingerne “Skip reconversion” (Spring genkonvertering over) og “Check history” (Tjek historik). Destinationsdirectoriene på filserveren bruges til at levere konverteret medie til klienter. MCEBuddy er konfigureret til at konvertere filer fra bestemte kildedirectorier og blot replikere filer fra andre uden at konvertere (ved hjælp af indstillingen “Rename without converting” (Omdøb uden at konvertere)). Hovedpointen her er, at kildedirectoriene aldrig tømmes; filer “lever” i kildedirectoriene hele tiden, og ændringer replikeres til de “synlige” directorier på filserveren, efterhånden som kildedirectoriene ændres. Jeg har i øjeblikket 9.589 filer i kildedirectoriene.

Alt dette virker. Mit problem er, at scanningsydelsen er elendig og bliver værre, efterhånden som jeg tilføjer filer. Den indledende gennemgang af bibliotristrukturerne og opbygningen af fillisten er ret hurtig, idet alle filer findes på cirka 22 sekunder og behandler op til 1.000 filer i sekundet. (Under dette trin ser jeg filerne opregnet i mcebuddy.log som “xxx is being monitored for syncing with output file” (xxx overvåges til synkronisering med outputfil).) Parsingen af filer og sammenligning med det, der er i historikfilen, fortsætter dog i yderligere 49 minutter og behandler kun 3 til 4 filer i sekundet. (På dette tidspunkt ser jeg filerne opregnet i mcebuddy.log som “xxx already converted with status Converted” (xxx allerede konverteret med status Konverteret).) Denne proces ser ud til primært at være CPU-bundet, da MCEBuddy.Service.exe i gennemsnit bruger 24-25% CPU-belastning på et 4-kerners system (åbenlyst ikke et bæst, med en Intel Core i5-7600 @ 3,5 GHz og 16 GB RAM). Hvis jeg tildeler CPU-tilknytning til 1 CPU-kerne for den pågældende proces, bruger den 100% af den kerne. Selvfølgelig kender jeg ikke MCEBuddy’s interne funktioner, men jeg er nødt til at forestille mig, at al denne CPU-overhead er MCEBuddy, der sammenligner filerne i kildedirectoriets træ med posterne i historikfilen, som er 7,36 MB på dette tidspunkt. Jeg ved nok til at indse, at en INI-fil af denne størrelse er meget dyr at parse. Så jeg prøvede at deaktivere indstillingen “Check history” (Tjek historik) i alle mine konverteringsopgaver og tænkte, at det ville få MCEBuddy til at ignorere historikfilen og blot kontrollere for eksistensen af destinationsfilnavnet på serveren for hvert kildefilnavn på det lokale drev. Men det ændrede slet ikke på ydelseskarakteristikaene; det tilføjede faktisk 12 sekunder til scanningen (selvom den afvigelse er så lille i sammenhæng, at indstillingsændringen kan være irrelevant).

Jeg har brugt Process Monitor til at undersøge, hvad der foregår, og selv med “Check history” (Tjek historik) deaktiveret, ser jeg MCEBuddy.Service.exe kontrollere hver kildefil én gang og udføre bogstaveligt talt hundredvis af læsninger på historikfilen for hver enkelt, men slet ikke røre ved filserveren. Jeg gætter på, at det giver mening, hvorfor den skal læse historikfilen uanset for at finde ud af, hvad destinationsfilstien er, men jeg forventede en eller anden ændring i adfærd her. Uanset hvad, ser dette ikke ud til at være min sølvkugle.

Kan du foreslå andre indstillingsændringer, der kan forbedre ydeevnen, eller er jeg bare ved at presse de praktiske grænser for MCEBuddy’s arkitektur? Jeg ville forestille mig, at denne type brugsscenarie ville fungere meget bedre med en rigtig database (f.eks. SQLite), og jeg tror, at historikfilen er flaskehalsen her, men jeg er åben for forslag.

Jeg har allerede forsøgt at genskabe historikfilen (Show history (Vis historik) → Clear history (Ryd historik), sørget for, at “C:\Program Files\MCEBuddy2x\config\history” er væk, genstartet MCEBuddy2x-tjenesten, startet konvertering og tilladt den at genopbygge). Det gjorde heller ingen forskel.

Jeg har uploadet MCEBuddy-logs til FTP-serveren i to undermapper: “scan - check history” og “scan - no check history”. For at oprette hver enkelt opdaterede jeg indstillingerne, stoppede MCEBuddy2x-tjenesten, slettede mcebuddy.log, startede tjenesten, startede konverteringer, ventede, indtil scanningen var færdig, og stoppede MCEBuddy2x-tjenesten, så hver log skulle være meget ren.

Tjek historik aktiveret: 14:18:20 - 15:08:06 = 49m:46s
Tjek historik deaktiveret: 13:09:50 - 13:59:48 = 49m:58s

Tak for at læse!

2

Hi toasterking, thanks for the detailed problem description and the logs. It sounds like you’re running into a performance bottleneck with the history file, especially with such a large number of files.

You’re right that the INI file format for the history can become inefficient with a very large number of entries. While I can’t directly change the software’s architecture to use a database, let’s see if there are any other settings or workarounds that might help.

Given your use case, where source directories are never emptied and you’re essentially syncing changes, the “Skip reconversion” and “Check history” options are crucial. However, the performance impact you’re seeing is significant.

Let’s try to explore some alternative approaches or confirm some assumptions:

  1. “Skip reconversion” with “Check history” disabled: You mentioned that disabling “Check history” didn’t help. My understanding is that “Skip reconversion” relies on the history file to know if a file has been previously converted and what its destination was. So, even if “Check history” is explicitly disabled, the system might still be querying the history file for the “Skip reconversion” logic. This would explain why you’re still seeing hundreds of reads on the history file.

  2. Optimizing the history file: Is there any possibility of archiving or splitting the history file if certain source directories are “stable” and rarely change? If you have older, static content that doesn’t need constant checking, perhaps those entries could be moved to a separate, less frequently accessed history file. This is more of a manual workaround, but it might reduce the size of the actively parsed history.

  3. Alternative synchronization methods: While MCEBuddy is excellent for conversions, for pure file synchronization, especially with such a large dataset, specialized file synchronization tools might be more efficient. However, this would mean separating your conversion and synchronization workflows, which might not be ideal for your setup.

Could you clarify if you’re experiencing similar performance issues if you temporarily disable “Skip reconversion” in addition to “Check history” (on a test set, of course, to avoid unnecessary reconversions)? This would help us isolate if the “Skip reconversion” logic itself is heavily reliant on the history file parsing.

Also, have you considered using a more powerful CPU or an SSD for the MCEBuddy installation and history file location if it’s currently on an HDD? While it might not solve the architectural bottleneck, it could alleviate some of the I/O and processing overhead.

I’ll also search the forum to see if other users have encountered similar performance issues with large history files or found any workarounds.

It sounds like you’ve done a thorough investigation into the performance bottleneck, and your observations regarding the history file size and its impact on scanning performance are very insightful. It’s indeed possible that with nearly 10,000 files and a 7.36MB history file, MCEBuddy is encountering limitations with its current architecture, especially if it’s repeatedly parsing the INI file.

Since disabling “Check history” didn’t significantly alter the behavior, and you’re still seeing numerous reads on the history file, it reinforces your hypothesis that the history file itself is the core issue.

While I can’t directly suggest internal architectural changes like switching to a SQLite database, I can offer some general troubleshooting steps and considerations that might help, or at least provide more data:

  1. Examine the mcebuddy.log more closely: You’ve already done a great job of using the logs, but sometimes a deeper dive can reveal subtle patterns. Look for any recurring errors or warnings during the “parsing and comparing” phase. Are there any specific files or types of files that seem to take longer to process?
  2. Temporarily reduce the number of monitored files: As a test, could you temporarily reduce the number of source directories or files MCEBuddy is monitoring? If the scan time scales down proportionally, it would further confirm that the number of files and the history file size are the primary drivers of the performance issue.
  3. Monitor disk I/O: While you mentioned CPU usage, it’s worth checking disk I/O during the “parsing and comparing” phase. If the history file is being read hundreds of times per file, even with caching, there could be a significant disk I/O component, especially if the drive is not an SSD. Process Monitor can show you read/write operations on the history file.
  4. Consider breaking down your tasks: If possible, could you split your 9,589 files into multiple, smaller sets and create separate MCEBuddy tasks for each? This wouldn’t solve the underlying history file issue, but it might allow MCEBuddy to process smaller chunks more efficiently, potentially reducing the impact of parsing a single large history file repeatedly. You could then schedule these tasks to run sequentially.
  5. Check for MCEBuddy updates: You mentioned you’re using MCEBuddy Premium 2.6.6. It’s always a good idea to ensure you’re on the absolute latest version available. While a major architectural change might not be in a minor update, performance optimizations are often included.
  6. Reach out to MCEBuddy support directly: Given your detailed analysis and the logs you’ve uploaded to their FTP server, I highly recommend reaching out to MCEBuddy’s official support channels directly. They would have the most insight into the internal workings of the application and could confirm if you’re indeed pushing the limits of its current design for your specific use case. They might also have beta versions with performance improvements or specific recommendations for large libraries.

It’s clear you’ve put a lot of effort into diagnosing this, and your insights are valuable. I hope these suggestions help you either find a workaround or get a definitive answer from the MCEBuddy developers.

3

Wow, sikke en stor hjælp denne bot er. Den har basalt set foreslået disse muligheder:

  1. Få en hurtigere CPU (hvilket kun er en midlertidig løsning, da CPU-kravet vil stige eksponentielt med INI-længden).
  2. Ændre hele medieafspilningstilgangen, så den passer bedre til MCEBuddy.
  3. Omstrukturere MCEBuddy. (Nej, kildekoden er alligevel ikke åben.)
  4. Foretage ændringer, der ville få MCEBuddy til at holde op med at virke, hvilket nødvendiggør #3.
  5. Undersøge ting, jeg allerede har undersøgt.

Jeg ville hellere skrive min egen applikation end at gøre noget af dette. Jeg ender måske med at gøre det, men jeg håber, jeg kan få MCEBuddy til fortsat at understøtte mit workflow!

4

Interessant opsætning. Vi har testet MCEBuddy her i vores laboratorier med op til 500.000 filer i en mappestruktur og har ikke set nogen særlig ydeevnedegradering under scanning af filer.

Jeg vil forsøge at besvare nogle af dine spørgsmål.

  • Når du bruger begrænsning af CPU-tilknytning eller ændrer CPU-prioriteten fra statusfanen, påvirker det kun de faktiske konverteringer og ikke hovedmotoren, der scanner filer, overvåger den overordnede status for konverteringer, håndterer GUI’en osv. Så hvis du begrænser CPU’en, vil det sænke konverteringerne, men hovedmotoren bør stadig køre med fuld hastighed.
  • INI-filernes database er meget højt optimeret og finjusteret til ydeevne og skalerbarhed, og vi har ikke set problemer med den med over en million poster i den (så historikfilen bør heller ikke tilføje nogen overhead).

Hvis jeg skulle gætte baseret på min erfaring, ville jeg satse på, at din disk er den sandsynlige flaskehals. Da du kun foretager omdøbning, er det stort set meget lidt CPU, men MASSER af harddiskaktivitet. Så mens konverteringsopgaven er travlt optaget af at kopiere og flytte filer fra én disk til en anden, forsøger hovedmotoren, der overvåger nye filer, også at bruge harddisken til at lede efter nye filer, og det sammenstød mellem de to overbelaster sandsynligvis din disk og sænker farten på det hele.

Bruger du en SSD eller en almindelig spindel-harddisk?

5

Mange tak for dit svar, Goose!

  • Jeg tildeler normalt ikke CPU-tilknytning. Jeg gjorde det kun som en test for at se, om MCEBuddy.Service.exe ville mætte hele CPU-kernen, hvis jeg tildelte den én kerne under scanning. Og det gjorde den.
  • Der foregik ingen konverteringer under min test, da MCEBuddy kun scannede filer, som allerede var blevet konverteret/omdøbt, allerede eksisterede i historikfilen, og allerede havde konverterede/omdøbte filer i destinationen.
  • Måske misforstod du, men jeg foretager ikke kun omdøbning. Nogle konverteringsopgaver omdøber kun, men andre konverterer. Hver opgave er bundet til en enkelt overvågningsplacering.
  • Jeg kontrollerede diskforbruget under scanning ved hjælp af Windows Jobliste, og efter den 22 sekunders indledende filoptælling brugte MCEBuddy 0-1% disk tid i de resterende 49 minutter, men brugte 25% CPU. Igen, under denne opgave var der ingen konvertering og ingen omdøbning/kopiering. MCEBuddy scannede kun filer, som allerede var blevet konverteret/omdøbt, allerede eksisterede i historikfilen, og allerede havde konverterede/omdøbte filer i destinationen. Windows og MCEBuddy er installeret på en SSD, men mediefilerne, der behandles, er på en roterende rustdisk. Men hvis disken var flaskehalsen, ville jeg forvente at se højt diskforbrug og lavt CPU-forbrug i Jobliste, men i stedet ser jeg det modsatte. Den behandlede kun 3 til 4 filer i sekundet, og intet kom ind i konverteringskøen.
  • Jeg glemte at nævne det før, men jeg prøvede også at deaktivere antivirus på pc’en og filserveren og så ingen forskel i ydeevnen.

Hvis du mener, at INI-filparsing bestemt ikke er flaskehalsen, vil jeg stoppe med at fokusere på det. Men hvad laver MCEBuddy.Service.exe med al den CPU-tid? Hvordan kan jeg finde ud af det?

6

Det kan være, at den venter på, at Windows skal gennemgå alle filerne i mappen. Tjenesten bør ikke bruge meget CPU i længere tid. CPU’en bør for det meste blive brugt af de andre processer, den bruger (som ffmpeg, handbrake osv.). Hvis selve tjenesten bruger CPU i en længere periode, så er det i bund og grund ved at påkalde noget i Windows, og Windows spinder rundt på det. Et eksempel ville være, at MCEBuddy beder Windows om at gennemgå alle filerne i mappen, og af en eller anden grund tager Windows meget lang tid om det (typisk sker det, når disken er meget travl). Da din disk ikke er travl i dit tilfælde, ville det være nødvendigt at se, hvor den bruger alle sine CPU-cyklusser.

Prøv dette: Start MCEBuddy og konverteringerne, men tryk på pauseknappen. Så vil den eneste CPU-belastning være fra scanningen. Hvordan den opfører sig derefter, vil fortælle mig noget nyt, om konverteringerne i sig selv har indflydelse på scanningen. Fra dine logfiler kan jeg se, at du kun har én aktiv konvertering.

7

Tak, Goose.

Jeg prøvede dette igen og klikkede på Start og derefter Pause, så snart MCEBuddy2x-tjenesten startede. Windows Defender er aktiv, men kilde-mapperne er indstillet som en undtagelse, og jeg deaktiverede også Real Time Protection, før jeg startede MCEBuddy2x-tjenesten. Desværre fik jeg det samme resultat. Scanning tog stadig omkring 48 minutter.

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

mcebuddy.log er i mappen “scan - check history on, conversion paused” under mit brugernavn på FTP-serveren.

Er der en måde, vi kan aktivere yderligere debug-logning for at se præcis, hvilken del af filforespørgslerne MCEBuddy-tjenesten venter længst på?

8

Okay, vi har kunnet undersøge dette nærmere og genskabe det problem, du oplever. Det viste sig at være historikfilen, der i nogle tilfælde forårsagede flaskehalsen ved gen-scanning af mapperne efter den indledende scanning, når historikfilen voksede ud over en vis størrelse. Vi har omarbejdet dette i vores tests, og vi ser nu en 50x-100x forbedring i ydeevnen ved efterfølgende scanninger. Den indledende scanning efter at have klikket på startknappen vil tage tid, da den udtrækker metadata fra hver fil ud over at scanne biblioteket, hvilket er en langsom proces. Tak for din rapportering.

Prøv dagens 2.7.1 beta-build og lad mig vide, hvordan det går.

9

Du har fikset det, @Goose!! :clap: :partying_face: I er helte!! :smiling_face_with_three_hearts:

Scanning tager nu 26 sekunder, ned fra 49 minutter. Det kan jeg sagtens leve med! Det er det hurtigste, det nogensinde har været, siden jeg satte det op for 3 år siden!

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

Jeg går ud fra, at mit setup er et kanttilfælde, eller i det mindste første gang nogen har sat det op på denne måde med en stor samling og klaget over ydeevnen. Uanset hvad, er jeg glad for, at I var i stand til at forbedre produktet, og jeg er meget glad for mit setup igen. Skål til dig og de andre udviklere, der fik det til at ske! :clinking_beer_mugs:

10

Jeg har fjernet mine logfiler fra FTP-serveren.