jel Posted July 17, 2009 Report Share Posted July 17, 2009 I have only recently upgraded to Retrospect 8.1 from 6.1 so I am still trying to get a feel for how it behaves compared to the previous version. As I watch it right now, it has it appears 'finished' backing up the biggest server volume (5 of 12) which contains on this one volume about 784,000 files. It currently says remaining 140 files, but these I believe are the ones it has failed to do because they have been deleted between scanning and backing up. (So they are no longer really remaining.) At a guess what it is now doing is preparing the information about those 784,000 files it has backed up to write to the catalog, however it has been like this for a very long time (of course 6.1 was notorious for this as well). However with 6.1 at least it would have shown a message saying it was updating the catalog. Currently in 8.1 the status is blank (a minus symbol) so I cannot be sure exactly what if anything it is doing. CPU activity on this 8-core Mac Pro is practically nothing, and it has 10GB of RAM of which currently 5.88GB is free. Yet again, it appears not only is Retrospect failing to take advantage of all the processors, it is also failing to take advantage of all the extra RAM. I am very disappointed about the complete lack of performance improvement over Retrospect 6.1 running on a far, far less powerful PowerMac G4. With supposedly a completely new design (engine) and now running on a machine several orders of magnitude faster, why cannot it be scanning, backing up, and update the catalog of different machines it is/has backed up at the same time? Is there some hidden setting to get it to use multiple cores? Hmm, as in this case the problem seems to be the one Retrospect has suffered from for years and years (an exponential increase in the time it takes as the number of files on a volume to be backed up increases), maybe a trick will be to make a series of 'sub-volumes' (aka. Favourites) for the top level folders of this large volume, and then it will only need to consider a smaller amount at a time. Or will it merely be that this means the time it takes is equivalent to 2+2+2+2+2=10 instead of 1 big volume taking 10 and not result in an overall difference. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 17, 2009 Report Share Posted July 17, 2009 We know performance is an issue. We have been doing a ton of code review to try and find speed improvements in areas like building snapshot (which is probably what you are describing above). We also know that network performance is not what it should be and we are working on getting that much better too. Quote Link to comment Share on other sites More sharing options...
fredturner Posted July 17, 2009 Report Share Posted July 17, 2009 Robin, there seems to me to be a lot of activity in the Retrospect engine even when there doesn't appear to be anything going on. I've noticed this on my busiest backup server, which I'm trying Retro 8.1 alongside 6.1 on. I only have 2 clients added to 8.1, but looking at top shows the Retrospect engine regularly sucking up all free CPU cycles (100..125..150%). Granted (and you may beat me down at this point), this backup server is a mere G4/500DP w/ 704MB RAM, but as a point of comparison, Retro 6.1 actively backing up (at several times the speed of R8.1) doesn't take up as much a CPU %-age as R8.1 just sitting idly, in my experience. Anyway, not meant to kick you while you're down WRT speed, but the Retro Engine does seem to be close to a runaway process on my machine. HTH, Fred Quote Link to comment Share on other sites More sharing options...
jel Posted July 20, 2009 Author Report Share Posted July 20, 2009 (edited) We know performance is an issue. We have been doing a ton of code review to try and find speed improvements in areas like building snapshot (which is probably what you are describing above). We also know that network performance is not what it should be and we are working on getting that much better too. Thank you for the reply, hearing that you are acknowledging the problem(s) is a reassurance. My suggestion that Retrospect could be (in one thread) building the snapshot (even at its current diabolically slow speed) while in another thread starting the scanning/backup of the next volume, would make a huge difference in overall performance, it could even halve the total time to backup. On my 8-core Mac Pro I have so far never seen the Retrospect Engine go above 100%, i.e. just using one core, so the computer could easily do both tasks at the same time. I am still concerned that the performance/CPU usage I am seeing suggests Retrospect is limited (possibly due to a single-threaded design) to using a single CPU/Core. PS. It would seem to make sense for you to change Retrospect so that status shows "Building Snapshot" instead of nothing (i.e. a Dash) this would at least indicate it has not died. Edited July 20, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.