From: Kern S. <ke...@si...> - 2004-03-31 14:45:52
|
On Wed, 2004-03-31 at 13:54, Mike Acar wrote: ... > > > > Ah, that's a really nice improvement. > > It is - but I'm unhappy to report that I've been rerunning my tests and > my results have proven to be pretty unstable :( Even after writing a > script to compile the sources for me to help eliminate variation, my > results vary widely: e.g. from 13 to 17.5 minutes for 5 runs of the new > code, and from 12(!) to 29 minutes for 5 runs of the old code. 13 to 17.5 minutes is understandable, but 12 to 29 means something is seriously going wrong. Check to make sure a screen saver or something like that is not kicking in and that no other *major* task is run. Normally if you toss the first and possibly second run, the variation between runs should not be more than 5% and 10% is very large. > > Perhaps I should write an article about this for the Journal of > Irreproducible Results? *sigh* > > I'm at rather a loss to explain it; perhaps it's an effect of disk > caching of the data file? The data file is 302 MB, and my machine has > only 512MB of RAM, so clearly something's going to be getting shuffled > into and out of cache, but I'd expect that to behave more consistently > between runs. Any ideas? Yes, it should be much more consistent even with paging and low RAM. I'd suggest that you take a look at all the daemons running to see if anything could possibly be perturbing the results. On my machine, I saw a variation of 1-2/40, where it was much more often 1/40. > > > > > The old code searched the whole list while inserting sorted data. The > > > > new code only searches part of the list, but at worst is no worse than > > > > the original code -- for the part of entering the Full save. > > > > > > Yes, you're right, and my latest tests bear this out. > > > > I'm happy I haven't lost my sense of performance tuning ... my old > > profession. > > Do you sense anything wrong with my approach thus far? :) > > [...] > > Well, the results should be slightly poorer, but unless you have huge > > masses of Incrementals, the overall totals should be better than before > > the new code. > > Indeed. > > > To get improved results, I thing the simplest thing is to add a doubly > > linked list and take advantage of our knowledge that most items come in > > in sorted order and thus do the search from the end of the list. > > It would be useful if somebody else out there could try this out > themselves on their data sets and for some of their backups - in > particular after a relatively lengthy history of backups on the same > machine, since that might perturb the ordering in the database. There is one more machine where I am sysadmin that is running a 500MHz RH7.1 system, where I can possibly try the code -- I'm a bit reluctant because I'd have to install new code on a production machine. Perhaps I can install a test Bacula pointing to the production database. This would give us one other set of data. The problem is they only have 144K files, so the results won't be much different from mine. > > I'll be happy to write the code, but I think I might wait until after > > 1.34.0 is released. Time is marching on quickly, and I would like to > > release it shortly or I'll have to wait until June. > > *nod* I'd very much like to see 1.34 out as well - it'll contain > PostgreSQL and data spooling support, right? Yes and yes. Regards, Kern |