On Jul 20, 2018, at 2:12 AM, Florian Balmer <florian.bal...@gmail.com> wrote: > > There's a lot of backup traffic
Quantify “a lot.” Do you have benchmark numbers showing that the current load is too high, and that your wished-for changes will reduce load to acceptable levels? > (This was also the main reason for my complaining about the leftover > WAL and SHM files, recently, which accumulated in my backup logs. > Because in the end, WAL and SHM have to be kept together with the > SQLite database, as they might contain valuable information?) The greater concern is that if these files are present after all clients have disconnected from the DB, it means you’ve got a DB client that is dying without closing the DB properly. That’s a problem in its own right, but it might also mean that the last transaction run might not have hit the journal before the program died, so it’s effectively rolled back upon replay of the journal. Rather than worry over the resulting WAL size, I’d find out why the DB client is dying early and fix that, so that the WAL ends up being deleted entirely upon a clean DB shutdown. > From peeking at the Fossil timeline, my question is, will the new > "backoffice processing" cause even more frequent updates to the main > repository database, i.e. with the pids stored in the configuration > table, and updated after each web page display? How many checkins, syncs, etc. do you have per day? I find it odd that some people get so itchy over DB concurrency and such with Fossil when highly active projects might have 40 or so commits per day. Amortized evenly over an 8-hour work day, that’s only one every 12 minutes. With real-world bursty traffic, there’s still an excellent chance that on every DB update, there is no write contention at all. > Does anybody care about the repository > database, holding all your valuable contents, being modified > frequently with simple non-contents state information? If I didn’t trust it to withstand that, I wouldn’t trust it to hold my unique work products, either. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
