kipouros Posted December 3, 2011 Report Share Posted December 3, 2011 Hi I upgraded to Retro 9 recently while still running 10.6.x. This week I upgraded to 10.7.x and I noticed that RetroEngine 9 uses - even idle - around 85-105% on my Mac Mini (late 2009) 2.53 Core 2 Duo, 4GB. I also noticed that I stopping RetroEngine via the SystemPrefs Extension takes ages (15 mins or more). Additionally, when rebooting the computer, it hangs when shutting down - I narrowed it down to RetroEngine, that wouldn't quit... I uninstalled and re-installed Retro9... didn't help. Any ideas? Cheers Quote Link to comment Share on other sites More sharing options...
Guest Steve Maser Posted December 4, 2011 Report Share Posted December 4, 2011 I've only seen the engine take a long time to stop via the System Preference if there is actually an activity in progress. Are you sure it was completely idle? Quote Link to comment Share on other sites More sharing options...
kipouros Posted December 4, 2011 Author Report Share Posted December 4, 2011 Are you sure it was completely idle? yes... nothing in the activity report... I think that 85-105% processor load is quite a lot for an "idle" process ;o) Quote Link to comment Share on other sites More sharing options...
prl Posted December 4, 2011 Report Share Posted December 4, 2011 yes... nothing in the activity report... I think that 85-105% processor load is quite a lot for an "idle" process ;o) You could use /Applications/Utilities/Activity Monitor to see whether it's the engine or the console that's chewing up the cycles. Just click on the % CPU column of the Activity Monitor display to order the processes by CPU usage. Repeated clicks on the header switch it between ascending and descending CPU usage. Descending order (triangle pointing down) is most useful for this. Quote Link to comment Share on other sites More sharing options...
kipouros Posted December 5, 2011 Author Report Share Posted December 5, 2011 I have "Activity Monitor" open since I upgraded to Lion and noticed, that some process is pretty processor intensive... And yes, it's RetroEngine that's running berserk not Retrospect.app... Quote Link to comment Share on other sites More sharing options...
prl Posted December 5, 2011 Report Share Posted December 5, 2011 I have "Activity Monitor" open since I upgraded to Lion and noticed, that some process is pretty processor intensive... And yes, it's RetroEngine that's running berserk not Retrospect.app... If you select RetroEngine in Activity Monitor's process list, and then click on the Inspect button at the top of the window, you get some more information about the process. The Open Files and Ports panel may give you a hint of what's going on, and pressing the Sample button on the process's Inspect window gives you a call stack with an indication of where the CPU time is going. You can save that and perhaps give Retrospect support a copy. It may help them diagnose where the problem lies. Quote Link to comment Share on other sites More sharing options...
19914193-04ff-4969-b172-ab0880c26727 Posted December 5, 2011 Report Share Posted December 5, 2011 (edited) I'm experiencing the same thing. Retrospect 9.0.0(319) engine generating 100% activity on one (of 4) CPU cores. Xserve Intel computer running a fresh installation of Mac OS 10.7.2 Server. Note, this computer was not upgraded from Snow Leopard (installed Lion from USB key). The other strange bit of behaviour (I'm not sure if it is related) is that the computer won't restart/shutdown with the Retrospect 9 engine running. For the computer to gracefully restart/shutdown I have to force quit the Retrospect 9 engine first. Sam Venning Melbourne, Australia Edited December 5, 2011 by Sam Venning Quote Link to comment Share on other sites More sharing options...
Guest Steve Maser Posted December 5, 2011 Report Share Posted December 5, 2011 Make sure you report this. The changes to the console's responsiveness (always one of my Retro 8.2 sore points) have been driving me batty with 9.0. Every time a backup activity is in the "closing..." status, I find that the console will SPOD and be unusable until that part of the backup is over. I haven't had any problems restarting my computer with the engine installed though. However, I almost always turn off the engine on my production machine before I restart it. My test machines, though, I don't -- but those don't have any active activities -- or if they have Proactive scripts, it's usually just one script. Quote Link to comment Share on other sites More sharing options...
kipouros Posted December 7, 2011 Author Report Share Posted December 7, 2011 (edited) Hi all I figured out, what the problem was. I am still observing to say that it's solved, but it looks much better now. The reason for the high CPU usage was the conversion of some clients's Mac OS X 10.7 hard drives to FileVault2. Obviously the conversion causes some changes in the drive, that it's not recognized ;o) as the same drive (since the encryption results in a different partition structure). I realized it, since other backup / synchronization tools like ChronoSync didn't recognize the converted drives. The real issue though, is not that it's a different drive, but that it's somehow different but still similar as the backed-up drive (like the movie «same same - but different» ;o)) In the sources view, there were two drives appearing in the same machine (the old unencrypted and backed-up drive, and the new FileVault2-encrypted drive). Since I had favourite folders defined, both drives even showed the same favourite folders. Also I wasn't able to edit the favourite folders of the client. Actually I wasn't able to edit anything in the affected clients. To test it, I converted the internal drive of the Mac running Retrospect. Same thing. I also noted, that Retrospect failed to back up the new converted FileVault2 partitions (note: I use Proactive backup scripts). I guess it stuck between - the partitions looking similar, but not being exactly the same... Solution: Remove previously backed-up and converted Mac OS X 10.7 FileVault2-encrypted volumes / clients completely from the sources list, and add them back again. This causes a full back-up, but it works fine. As soon as I removed all volumes that appeared twice in the sources list, thing went back to normal. (Since FileVault2 on-the-fly conversion works only on startup-volumes, same applies probably for external Volumes that are erased, partitioned with a encrypted partition, and reverted with the previous content - probably every partition that appears two times in the sources list). Unfortunately I was not able to remove just the "old" partition / volume, so you have to remove the drive / client completely from the sources list... Hope it helped. PS: One interesting thing I just noticed: I removed one client's volume, that was backed up before, from the sources list before converting it to FileVault2. After the conversion, I added to the sources list. Obviously this process avoids triggering a full backup. Because - oddly - the next backup was not a full backup as with the other clients, but an incremental backup. Edited December 7, 2011 by kipp Quote Link to comment Share on other sites More sharing options...
f30e6e60-a263-4d69-8f60-c92703669308 Posted December 7, 2011 Report Share Posted December 7, 2011 oddly - the next backup was not a full backup as with the other clients, but an incremental backup Remember that Retrospect does not perform "Full" and "Incremental" backups as some sort of different operations. "Incremental Plus " means Retrospect scans the Source and matches it against its Catalog, then backs up whatever is different/new. That could be every file, that could be only one file. But as far as Retrospect is concerned, it's not doing anything differently. That the program saw every file as changed after your first steps but did not when you altered your actions is quite helpful information; I hope the company's documentarian(s) make a note of it... Quote Link to comment Share on other sites More sharing options...
kipouros Posted December 7, 2011 Author Report Share Posted December 7, 2011 Thanks for the clarification. The important thing is, whether Retrospect regards the volume as the same as before or as a different one. I guess, that in the all but the last client, Retrospect regarded the newly encrypted volumes as completely different volumes and backed them up completely - only in the last case, Retrospect regarded the volume as the same, and backed up only the changed files... Why? Only Retrospect knows ;o) Quote Link to comment Share on other sites More sharing options...
twickland Posted December 7, 2011 Report Share Posted December 7, 2011 I guess, that in the all but the last client, Retrospect regarded the newly encrypted volumes as completely different volumes and backed them up completely - only in the last case, Retrospect regarded the volume as the same, and backed up only the changed files... Does your backup script include the option "Match only files in same location/path?" (This option is not selected by default.) If it doesn't, Retrospect should always back up only the changed files, irrespective of whether it sees the source volume as the same or different. Quote Link to comment Share on other sites More sharing options...
kipouros Posted December 8, 2011 Author Report Share Posted December 8, 2011 (edited) Does your backup script include the option "Match only files in same location/path?" Thanks for the hint. I checked and actually it's off. Also the option "Don't add duplicate files to the Media Set" is set... So it shouldn't have. But - whatever... What happened - happened ;o) Edited December 8, 2011 by kipp Quote Link to comment Share on other sites More sharing options...
alabay Posted August 12, 2012 Report Share Posted August 12, 2012 This Retro ist driving me insane! I recently updated to 10.7.4 and now I have the same issue. With R8, but as I read, this has not changed in R9 :-( And no, I don’t have FileVault in use, I have one old client and three local proactive sctipts. The shares have all been killed, it’s not possible to use them with RS and Lion. But still … CPU load until kill, afterwards everything works fine, on- and off-switchable. An NOWHERE, no-one can tell one nothing. What to do? Who will save us RS-victims?! 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.