Jump to content

Retrospect using 90%+ processor time


Recommended Posts

 

We recently setup Retrospect 5.0 on a client's new Xserve 1.33 (1.5 RAM), 10.2.4. The server is used for file and mail services as well as Retrospect backup. The client is using a VXA firewire tape drive for backup.

 

The problem is that when Retrospect is running, it consumes over 90% of the processor time (shown by Top). The led's are pegged on the Xserve, and over time the Mail portion of Mac OS X server dies and cannot be restarted. Although we can kill the processes related to Retrospect, mail refuses to restart until the who Xserve is restarted. These problems ONLY occur when Retrospect 5.0238 is running and backing up (usually a recycle backup). If Retrospect is not running, the mail server does not have these problems.

 

While we cannot reproduce the problem with killing mail (I think that requires the processor is pegged for a longer amount of time), we can produce the 90%+ processor demand by retrospect. Simply erase a new tape in the VXA drive and the LEDs will ratchet to full. Once the tape is erased, the LED''s will drop down. Is this normal? Why doesn't this happen with the SCSI based devices?

 

Is there anyone else having issues like these?

 

 

Jeff

 

 

 

 

Link to comment
Share on other sites

Having the same problem. didn't notice the problem with mail quitting though. The Backup appears to halt and peg the processor for minutes at a time. Have you found a solution? We have the latest update from Dantz. 5.0238 I believe.

Link to comment
Share on other sites

Dantz is aware of some of these issues specifically related to the Retrospect Client. To be notified when they are fixed, join the following mailing list.

 

 

 

http://list.dantz.com/mailman/listinfo/mac_client_cpu

 

 

 

 

 

If this is XServe RAID, please read our compatibility Statement:

 

 

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27639

Link to comment
Share on other sites

We are using xserve raid and the thing is that retrospect is having no problems backing up the raid volumes when it can get to them. The high processor utilization is occurring when it's backing up the xserve local system volume. It also fails repeatedly with a "automatic exectution unexpectedly terminated" while copying the sysvol. For instance the backup ran fine over the weekend, kicked off last night and failed with the above msg. I ran the dailybackup manually from the run command this morning and it's still running along fine - with the exception of pegging the processor at %90 while copying the sysvol.

Link to comment
Share on other sites

We see this problem as well (see my earlier post). Long runs with Retrospect (sometimes) bring down mail service as well as Apple file service. In our case the reason the mail server won't restart is because when the server quits it leaves a process called "MailService" running, which happens to be what Apple's Watchdog service monitors. If you kill "MailService", Watchdog should restart the mail server without needing to reboot the entire machine. This might be due to Retrospect hogging the CPU but it might also be network bandwidth related since the mail server usually shuts down claiming it can't reach a DNS machine.

Link to comment
Share on other sites

Quote:

We see this problem as well (see my earlier post).

 


 

Unfortunately, your earlier post is equally short on details.

 

- For example, what are you doing?

 

- Is Retrospect backing up Client machines?

 

- What do the mail server log error times correspond to in the Retrospect log?

 

- What's your network topology like?

 

Just wondering,

 

Dave

Link to comment
Share on other sites

We are not using Retrospect client, we are only using Workgroup on the Xserve. It is only backing up local firewire drives to a VXA firewire device. We are not using an Xserve RAID.

I can easily reproduce the mail server dying by executing a Recycle backup during the day. As users hit the mail server it just dies. I can kill all processes associated with mail, but sometimes it will not restart without a reboot. None of these problems occur if Retrospect is not running, so Retrospect is definietly the cause of it.

 

Just doing a simple rewind, quit after execution (which causes a rewind) or erasing a tape will peg the processors to near 100%.

 

As a note, on other client Xserves (DP's) I've notice the Retrospect has the same hit to the processor, but the load is divded over the two processors.

 

Jeff

 

 

 

Link to comment
Share on other sites

Quote:

I can easily reproduce the mail server dying by executing a Recycle backup during the day

 


 

- At what point during the Execution does the mail server choke?

- Is it during Scan?

- During Copy?

- Is it always at the same Source?

- How many files are in the session that's the Source when the mail server chokes?

- Does it happen when backing up a small defined subvolume?

 

Dave

----

Link to comment
Share on other sites

Dave,

The mail server "chokes" when Retrospect has the CPU pegged for @ least 30 minutes (varies, could be longer). Backing up smaller sub sets will not reproduce the problem since it won't be a long enough time @ 90% of CPU time. Execution of a normal backup will not cause these problems since the CPU is pegged only for a short time.

 

It is almost always during the copy process but every so often in the compare (read) state.

Recycle copies usually contain about 50,000+ files per volume. Backup is coming from the same source - 2 firewire drives.

 

This occurs whether it's a manual or automatic execution - recycle backup only.

 

Jeff

 

 

 

 

 

Link to comment
Share on other sites

Quote:

Quote:

We see this problem as well (see my earlier post).

 


 

Unfortunately, your earlier post is equally short on details.

 


 

Sorry for not providing this information earlier...

 

Quote:

- For example, what are you doing?

 


 

Retrospect is running on OS X Server (10.2.5) running on a 500 MHz G4 Server machine. Runs a scripted backup once per day backing up itself and 5-10 clients (all OS X machines) depending on which machines are on the network.

 

Quote:

- Is Retrospect backing up Client machines?

 


 

The script does back up client machines but usually at the time of the crash it is either copying or comparing its own files. (Which makes my previous comments about this being a network bandwidth issue unlikely...)

 

Quote:

- What do the mail server log error times correspond to in the Retrospect log?

 


 

The mail server crash was recorded at 22:12:32 and the apple file server shut down at 22:12:27 The Retrospect log for that time period was as follows:

 

+ Normal backup using EasyScript Backup at 4/10/2003 22:00

To backup set Backup Set A?

 

- 4/10/2003 22:00:18: Copying Disk?

Can't read file ??aÅNÅsoÅLu`eÅLÅgEÅLKEÅLCEÅLh.pdf?, error -43 (file/folder not found), path: ?Disk/Library/Documentation/MacOSXServer/Japanese/?aÅNÅsoÅLu`eÅLÅgEÅLKEÅLCEÅLh.pdf?.

4/10/2003 22:11:16: Comparing Disk?

Can't read file ??aÅNÅsoÅLu`eÅLÅgEÅLKEÅLCEÅLh.pdf?, error -43 (file/folder not found), path: ?Disk/Library/Documentation/MacOSXServer/Japanese/?aÅNÅsoÅLu`eÅLÅgEÅLKEÅLCEÅLh.pdf?.

File ?Operations Log?: different data size (set: 186,392, vol: 186,630), path: ?Disk/Library/Preferences/Retrospect/Operations Log?.

File ?access_log?: different data size (set: 87,837, vol: 97,359), path: ?Disk/private/var/log/cups/access_log?.

4/10/2003 22:12:54: 4 execution errors.

Completed: 1433 files, 469.8 MB

Performance: 269.7 MB/minute (221.9 copy, 343.7 compare)

Duration: 00:12:36 (00:09:07 idle/loading/preparing)

 

4/10/2003 22:12:54: Connected to Lolle Office iMac G4

 

- 4/10/2003 22:12:55: Copying Macintosh HD on Lolle Office iMac G4?

Can't read file ?retropds.22?, error -40 (file positioning error), path: ?Macintosh HD/Applications/Retrospect Client/Retrospect Client.app/Contents/Resources/retropds.22?.

4/10/2003 22:21:56: Comparing Macintosh HD on Lolle Office iMac G4?

File ?access_log?: different data size (set: 464,232, vol: 467,544), path: ?Macintosh HD/private/var/log/cups/access_log?.

4/10/2003 22:22:23: 2 execution errors.

Completed: 66 files, 73.3 MB

Performance: 94.5 MB/minute (55.6 copy, 313.9 compare)

Duration: 00:09:28 (00:07:55 idle/loading/preparing)

 

 

Quote:

- What's your network topology like?

 


 

100MBit full duplex ethernet

All machines on a single subnet connected to the same Netgear 10/100 switch

 

Thanks for your interest...

 

Bob

Link to comment
Share on other sites

Quote:

Long runs with Retrospect (sometimes) bring down mail service as well as Apple file service.

 

...usually at the time of the crash it is either copying or comparing its own files

 

- 4/10/2003 22:00:18: Copying Disk

- 4/10/2003 22:11:16: Comparing Disk

- 4/10/2003 22:12:54: 4 execution errors.

- Completed: 1433 files, 469.8 MB

- Performance: 269.7 MB/minute (221.9 copy, 343.7 compare)

- Duration: 00:12:36 (00:09:07 idle/loading/preparing)

 


 

This log segment shows a fast 12 minute Backup, with a screaming fast 1-1/2 minute Compare. Is this representative of a long run?

 

What sort of Backup Device are your writing to?

 

This weekend I used AppleScript to create 1.6 million files (into 10,000 folders) on an OS X Server 10.2.5 machine. I then backed them up to a File Backup Set stored on a large external FW drive. The entire operation took over 10 hours. File serving and mail serving are working fine this morning.

Link to comment
Share on other sites

Dantz has released an update to the Retrospect Client software for Mac OS X. This update is compatible with Retrospect 5.0 for Macintosh as well as Retrospect 6.5 for Windows.

 

Changes made the new Macintosh client software include improved memory management on the client computer as well as a fix for the error -40 File positioning for retropds.22.

 

The new client installer can be downloaded from:

 

ftp://ftp.dantz.com/pub/cs/mac_client_5_1.sit

 

Thanks,

 

Dantz Technical Support

 

Link to comment
Share on other sites

  • 3 months later...

At the risk of finding out that I have a screwed up system, I have a dual 1 GHz G4 that, after cancelling a backup (due to processor load during operation), pitond continues to max out one of the processors at 95-96%. I am running client 5.1.106, with OS X.1.5. The main focus of this box is mySQL, with sendmail and php on it as well.

 

After killing pitond, and restarting the process from the client app, the processor hit for pitond is closer to .9%, a much more acceptable number. When I Timbuktu'ed into the box to restart the client and logged in, there was a dialog box waiting for me, letting me know that the backup was cancelled.

 

Has anyone else seen this? Is it possible that the pitond is running at such a high processor level just to show (and get a click-through) of the error message? Could this be tied to the issue in the 5.0 client? Does anyone have any potential solutions/things to look at? Can I ask any more inane questions? Who killed Colonel Mustard?

 

Thanks,

tre

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...