> Do you turn on auto_vacuum during the scan, do a vacuum before scanning, > or do a vacuum after scanning? Why not also do the remaining databases?
auto_vacuum is off for these two files. The auto_vacuum is mostly about not wasting disk space, but it doesn't help the fragmentation. If you want best performance, then you'll have to run a full VACUUM. As these two files don't see that many changes the waste of disk space should be negligible.
It's a different story for the cache files which change every minute if you listen to some online source. This is the reason why I did not enable auto_vacuum on library and persist, but on the cache files.
Initially I set vacuum to be run right after the scanner had wiped all tables, as I expected this to be the quickest. Unfortunately the DB is slightly slower if it has to constantly grow the file. Plus at the end of the scan there would be a certain amount of fragmentation already. Therefore I decided to run it in the optimize step.
The thing I dislike about this approach is that if everything in LMS worked as it should (i.e. if there were no scanning bugs or bugs that cause the database to become inconsistent or corrupted) users should never have to run a full rescan.
We still have a long way to go :-). > Having to do so to maximize performance
is not the best strategy, IMO. For the users for whom this will do the most good, that full rescan may take hours due to very large libraries or very slow hardware.
Another change I just committed: the VACUUM is read during a new & changed scan, too, if no player is active. The problem is that VACUUM can break playback. If you use the rescan plugin to run scans at night, you should be on the save side.
Is the max buffer size per SQLite database or is there just one buffer for the entire LMS application?
It's per database connection, to be accurate. Eg. the scanner can use a different buffer size than the server (which makes sense, as the scanner doesn't profit as much from the larger buffer to its mostly writing nature).
Currently only persist and library use that maximum setting. Caches don't. I probably have to tweak this further, as caches are accessed quite often, while persist is rather simple (unless you're using one of Erland's plugins). But I'd like to get some data from you first.
Keep in mind that in most cases LMS would be using a fraction of that maximum cache_size only anyway. Eg. my server process is currently running at around 200MB memory usage. Before the buffer change it was around 140MB. It's far from using 500MB times two cache_size. Unfortunately I haven't figured out a way yet to determine how much sqlite is actually using.
-- Michael _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
