Jump to content

Recommended Posts

Having tested 6.0 Workgroup on two different setups I have observed that when doing backup of large volumes to tape drives and tape libraries, Retrospect uses almost all CPU cycles available - top will usually show CPU utilization going between 65 and 95% back and forth (for Retrospect alone). Seems a lot for just copying data (software compression and encryption are both disabled, of course).

 

I have observed that on pretty fast hardware including an Xserve 1,33 Ghz and a PowerMac G4 1 Ghz.

 

Is this expected behaviour? Are there any ways to tweak/improve the performance of Retrospect, or do we have to live with the fact that backup with Retrospect is processor-intensive?

 

(this is certainly not related to the Event Handler issue described in my other post - the CPU utilization die not change noticable after I installed the Event Handler).

 

Cheers,

Rafael Kobylinski

Link to comment
Share on other sites

When my scheduled backups run at night, the CPU utilization hovers around 90% for the entire duration of the backup (on a G4 Xserve).

 

I also find that when I'm just poking around in the application, checking logs, managing backup sets, etc., Retrospect tends to chew up around 50% of the CPU. Sometimes, it takes 20-30 seconds just to complete each operation (switch from Immediate to Reports tab, for example). Clearly, something is amiss.

Link to comment
Share on other sites

I have the same problem, using RS 6 under 10.3.3/10.3.2 even so that my Server is Hanging and all my clients are disconnected, i run RS 6.0 Workgroup on a xserve 2* 1Ghz with 1 GB of RAM ....

 

I now can't make any backup anymore, my server restarts it self because it is thinking that it hang's ....

 

PLEASE DANTZ FIX THIS PROBLEM ....

Link to comment
Share on other sites

Yes i can ... smile.gif

 

xserve 2x 1 Ghz G4 1024 MB RAM, 1 x 60 GB drive, 1 x 120 GB drive 2 x 180 GB drive (Mirrored)

ATTO Express PCI Pro UL 366 SCSI 2 Card with connected a Sony AIT 1 35 GB Drive unit

MacOS X.3.3 Server

 

Backup is going wel for the first 5 GB than it freeze the machine, installed all the updates there are for RS 6

 

Bakcup runs at 5 AM every day ...

 

If you need more info please ask ... smile.gif

Link to comment
Share on other sites

FYI -

 

I just installed Retrospect 6 Workgroup on a new Panther Server and attempted my first unattended backup this morning at 3:00 AM. When I got in around 8:00, the server was frozen solid, not responding to anything. After a reboot, I checked the CPU graph and at exactly 3:00 AM, the CPU went off the charts and services starting failing. AFP failed at 3:06 AM, mail and web hung around a little longer, but everything was doomed by 8 AM. The CPU graph shows that between 3:00 and reboot, the CPU was maxed out 100% and clearly the server was having significant problems. I'm doing a manual backup now (during the day), and Retrospect is still consuming 90%+ of the CPU, though nothing has failed yet.

 

This is a new server setup (about 1 week old), so there may be other issues involved, but I thought I'd pass on my experience as it sounds similar to those in this post. The sever has been flawless until this crash.

 

Hardware: 933 MHz G4 with 1 GB RAM

OS: Mac OS X Server 10.3.3

Retrospect v6.0.178

SCSI Card: ATTO ExpressPCIPro UL3D

Tape Drive: Sony TSL-A300C AIT 4-tape autoloader

Backing Up: Boot Volume (20 GB ATA), Mirrored 200 GB SATA RAID (internal), and 1 Mac OS X Client.

 

Let me know if any more info would be helpful...

 

Bjk.

Link to comment
Share on other sites

Nate:

 

If that question was directed to 'imbjk', then the answer is Yes. I flashed the ATTO card with the latest firmware (1.6.6f0), and updated the drivers to ATTO's latest, 3.1.0 for Panther. I've tested this configuration on a clean install of 10.3.3 client as well (with the driver update), and still Retrospect consumes close to 100% of the processor backing up a local volume to tape. When trying to backup a network client, there's barely a cycle left for anything else. This didn't cause many problems on the client, but when running on a server with other services that need regular CPU time, the results were unacceptable (i.e. services failing).

 

Even when quitting Retrospect, while it's waiting for the tape to rewind, it's consuming 100% of the CPU. Huh?

 

Bjk.

Link to comment
Share on other sites

Nate:

 

I found the following post by you (from 12/15/03) in a different area of the forums (5.1 with Panther):

 

--- Start Quote ---

 

This is probably not what you want to hear but here is the offical word on a similar issue:

 

XServe/Mac OS X Server

Dantz, along with several other software and hardware companies, have been actively investigating Mac OS X Server backup problems reported by customers in the field. The core issue reported is that after a certain period of backup to SCSI-attached tape, the server (most often an Xserve) becomes unresponsive or is restarted by the watchdog utility.

 

Dantz and the other companies involved are working together to find the root cause of--and a solution to--this problem. To be notified when additional information is available, Dantz recommends that affected customers sign up for the Dantz Xserve mailing list.

 

...

 

Really high CPU useage is another symptom of the problem listed above. I suspect that may be what it happening in your case

 

Nate

 

--- End Quote ---

 

It sounds like this is very similar to my problem. Is there any new information on this topic? I haven't been able to back up completely since this 'upgrade'...

 

Thanks,

 

Bjk.

Link to comment
Share on other sites

I posted earlier that I have been having problems with Retrospect 6.0 slowing to a crawl on my Xserve G4 (single) running 10.2.8.

 

What I've discovered since then is that if I manually kill the RetroRun process every day, then allow it to restart by launching Retrospect, things run smoothly.

 

Last Saturday morning, I killed RetroRun. Then I left everything alone until Monday night, when a regular backup was scheduled. That backup ran at about 10 MB/min, and I killed it Tuesday morning. No other activity took place on the server between killing RetroRun and the Monday night backup attempt.

 

My conclusion is that something happens to the RetroRun process over time, whether backups take place or not. My "fix" is therefore to make sure I kill RetroRun within a few hours prior to any scheduled backup.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...