How long does an optimization of a DB file run in average? Yesterday I have optimized and compressed my DB file afterwards checking in appx 50k files and the DB file contains now in total appx 229k. The current file size is about 12,5 GiB.
The duration time of optimization and compress was 1,5 h - without any error or information message, so everything is fine with the file structure.
The day before yesterday, when the total amount of files was appx 170k, it took only 9 min.
In both cases the DB file was stored on local SSD.
This raises a.m. question.
Additionally to this question: Would it be (or maybe it is already) possible to run such optimization/compress by a task? Then I would configure a task that runs every third day at 3 am.
The Compact & Optimize cannot know how long it will take before it is done. This is an atomic operation which runs 100% inside the database kernel (3rd party).
It basically produces a pristine copy of your database with all slack removed, heuristic information updated, indices optimized etc.
The diagnosis remembers the time it took the last time and how many files the database contained at that time.
Usually the optimization time increases linearly with the file count. A database with twice as many files takes about twice the time.
As an example, on my system, IMatch needs 14s for a 50,000 files database and 25s to optimize a database with 100,000 files.
I store my databases on a fast m.2 internal SSD.
If it runs 9 minutes one day and 90 minutes the other day after increasing database size by about 25%, something appears to be wrong.
Maybe your virus checker kicked in? Or some other software or service produced a of disk I/O at the time, thus forcing IMatch to pause often?
Thanks for your hints. Today the whole process ran only 4 minutes, added 4k files. Hm...
So 9 minutes, 90 minutes, 4 minutes?
Sounds like something else was doing a lot of file IO during the second test and IMatch was forced to wait for the disk...?
I've have excluded the folder containing the DB of virus scanning. A retest with the previous unoptimized version of the DB confirmed the solution. So everything is fine now and now it works as expected. ;D
I was also expecting a linear increase of the optimization, therefore an increase by factor 10 is not normal.