rmwilliams23 Posted January 22, 2016 Report Share Posted January 22, 2016 Currently running Retrospect 10.5.0 on Snow Leopard Machine: Processor Speed: 2.66 GHz Number Of Processors: 2 Total Number Of Cores: 4 L2 Cache (per processor): 4 MB Memory: 13 GB HDD Capacity: 496 GB Available: 396.91 GB Have been using Retrospect 10 to rebuild catalogues that were previously being used within version 6. The rebuilds have been going fine but lately I have been getting an error of: '!Not enough application memory'. Nothing in my opinion has changed from when we started rebuilding catalogs and in my opinion I would think that the machine being used has plenty of system memory. Has anyone else come across this error on rebuild/repair? Surely there should be an easy solution to this that I'm just missing, or isit simply a bug? Any info would be great. Thanks Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 22, 2016 Report Share Posted January 22, 2016 Rebooting the computer just prior to recataloging should free up memory. If it happens anyway, check the memory in Apple's System Monitor. Quote Link to comment Share on other sites More sharing options...
rmwilliams23 Posted January 26, 2016 Author Report Share Posted January 26, 2016 Just ran system monitor whilst Rerstrospect was trying to rebuild and the activity monitor said that it never dropped below 13GB of free memory at any time. Should I therefore rule out a system memory problem? The issue still says not enough application memory so that is maybe leading me in the direction of it being a bug/software problem. If anyone could get back to me on this with maybe the same problem that would be great! Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 26, 2016 Report Share Posted January 26, 2016 Did you reboot the computer just prior to running the recatalog? Then it looks very much like a bug or maybe a corrupt backup set. Are you running the last 10.5 variant? [10.5.0 (145)] http://www.retrospect.com/en/support/archived#mac105 Quote Link to comment Share on other sites More sharing options...
rmwilliams23 Posted January 26, 2016 Author Report Share Posted January 26, 2016 I am indeed running 10.5.0 and I did a reboot yes. The rebuild files shouldn't be corrupt as I've previously rebuilt this set on the system but it got lost. So in theory if I update the machine to Yosemite and install the latest version that could very well fix the issue? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 26, 2016 Report Share Posted January 26, 2016 I am indeed running 10.5.0 and I did a reboot yes. The rebuild files shouldn't be corrupt as I've previously rebuilt this set on the system but it got lost. So in theory if I update the machine to Yosemite and install the latest version that could very well fix the issue? Is the last digits (145) in the version number? Yosemite is a lemon. If you don't want El Capitan, go for Mavericks. That is, if you really want to leave Snow Leopard. Quote Link to comment Share on other sites More sharing options...
rmwilliams23 Posted February 5, 2016 Author Report Share Posted February 5, 2016 Ok think I've solved the problem. Seems to be running smoothly now but we shall see. If anyone else gets this problem here's how to fix it. It had nothing to do with system memory but seems that there were too many activities within Retrospect running at once which was giving the '!not enough application memory' error message on rebuild. Luckily there is an option within general preferences that allows you to choose how many activities can run at any one time. The number in the activity threads box had defaulted to 16 so I simply changed this to 1 and now it seems to be running without any problem at all. I have also attached an image so everyone can see where this is. Thanks Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 5, 2016 Report Share Posted February 5, 2016 Good detective work. Thanks for posting the solution. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 5, 2016 Report Share Posted February 5, 2016 Come to think of it: How many threads were actually running when the recatalog failed? You could, perhaps, try half that number (instead of just one single thread). Quote Link to comment Share on other sites More sharing options...
rmwilliams23 Posted February 8, 2016 Author Report Share Posted February 8, 2016 I was running 16 threads so yes 8 would probably solve it too but to be honest putting it to 1 thread hasn't slowed and rebuild down one bit. As quick as ever so I will persist with it and hope won't be anymore errors. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 8, 2016 Report Share Posted February 8, 2016 Did you really have 16 executions running at the same time? What I meant was checking how many executions that were actually running (out of the 16) and use half that number. If you only have one allowed execution, nothing else will be running when you do a recatalog. Quote Link to comment Share on other sites More sharing options...
Don Lee Posted February 26, 2016 Report Share Posted February 26, 2016 16 is a lot. 8 could be a lot. Being able to run more than 1 - like 2 - is wonderful. However, it's not often that more than 2 or 3 are of real advantage. If you get several threads either reading or riting to the same device/disk, you end up spending all your time seeking the head. Other scenarios also limit the actual amount of "parallelism" you actually get. Each thread can burn a lot of memory and/or other resources. I'd be inclined to limit the threads to 2 or 3, unless you have a good plan, and a good reason. 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.