jelockwood Posted March 2, 2017 Report Share Posted March 2, 2017 Retrospect ever since version 8 and still all the way to version 13.5 i.e. the very latest has been utterly insane regarding the amount of CPU power it uses. Retrospect is not a rendering program, it is not trying to calculate million digit prime numbers, it is a poxy backup program!!! There is no way it should need such massive amounts of CPU power, other brands of backup program do not. Previously Retrospect have come up with the absurd response that they are 'reserving' CPU i.e. grabbing 100% of a single core whether they need it or not. This is not how programs work, CPU usage is not like memory usage, yes for memory you do often need to pre-allocate a block of RAM but for CPU you use it or you do not use it, you do not allocate it regardless. Note: I have previously turned off every possible option like software compression, encryption, de-duplication, etc. etc. which made no difference. Now today whilst I am still very disappointed by Retrospect's continuing pathetic CPU utilisation problem I am reporting a new problem which appears to be a direct result of Retrospect being so bad with regards to CPU usage. We recently upgraded one of our servers to Sierra 10.12.3 from a previous generation of OS X. The Mac is the same model using the same drives with the same files on the same external data drive as before being upgraded, Retrospect has correctly spotted the files are the same so is not doing a backup of all files only the changed ones. One would expect the backup to take a similar amount of time as before the client i.e. the Mac server was upgraded. In fact technically speaking it seems the backup is taking a similar amount of time but what is taking hours and hours longer is the post-backup cataloging and snapshot making tasks. We have had a look at the Console logs on this Mac server and found that there are entries like the following Date/Time: 2017-03-01 08:10:39 +0000 OS Version: Mac OS X 10.12.3 (Build 16D32) Architecture: x86_64 Report Version: 19 Command: RetrospectInstantScan Path: /Library/Application Support/Retrospect/RetrospectInstantScan.bundle/Contents/MacOS/RetrospectInstantScan Version: 13.5.0 (173) (13.5.0.173) Parent: launchd [1] PID: 25918 Event: cpu usage CPU: 90s cpu time over 114 seconds (79% cpu average), exceeding limit of 50% cpu over 180 seconds Duration: 114.21s Steps: 130 Hardware model: Macmini7,1 Active cpus: 4 Fan speed: 1794 rpm This is showing that Sierra has spotted excessive CPU usage by RetrospectInstantScan and the implication is that when this happens Sierra throttles the CPU usage of this process which would slow it down and then slow down the Retrospect backup. Note: We also saw a similar message for the RetroClient process as below Date/Time: 2017-02-26 13:11:08 +0000 OS Version: Mac OS X 10.12.3 (Build 16D32) Architecture: x86_64 Report Version: 19 Command: retroclient Path: /Library/PreferencePanes/Retrospect Client.prefPane/Contents/MacOS/retroclient Version: ??? (???) Parent: launchd [1] PID: 62 Event: cpu usage CPU: 90s cpu time over 123 seconds (73% cpu average), exceeding limit of 50% cpu over 180 seconds Duration: 123.28s Steps: 107 Hardware model: Macmini7,1 Active cpus: 4 Fan speed: 1794 rpm Although this one surprisingly is not logged for every day. These logs are located in /Library/Logs/DiagnosticReports/ Note: These particular logs are not created on a virtually identical El Capitan server and those El Capitan servers have not exhibited this new problem although as mentioned like all Macs running Retrospect server or client use excessive CPU power all the time a Retrospect task is active. It seems it is possible to disable Sierra's CPU throttling mechanism but that this is not an easy process. See http://apple.stackexchange.com/questions/254143/how-do-i-disable-configure-macos-sierras-auto-throttling-of-the-cpu-for-process Once again I stress the problem is Retrospect's long time and still present pathetically poor CPU utilisation. (We will ignore the fact Retrospect is also almost completely incapable of using multiple CPU cores for a single backup script even though logically many tasks could be overlapped or distributed e.g. compression, encryption, cataloging.) Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted March 2, 2017 Report Share Posted March 2, 2017 It would be interesting to see a sampling of the Retrospect process while running a backup. http://www.thexlab.com/faqs/activitymonitor.html#AM-Sample-Process 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.