CPU load at maximum all the time

[mlevin77]

I'm using Retrospect 6 server on a G5 Xserve running Tiger. When it's writing a backup (e.g., to tape) the CPU lights are at 100% and the server is very unresponsive. Is this normal? Should it be using that much CPU? for what? Isn't it mainly IO to tape? Can I lower the "niceness" of this process or will that be a problem?

 

Mike

 

[rhwalker]

Yes, it's normal. It's hard to keep the pipeline filled so that there is always data for the tape when a write needs to be issued.

 

Remember, this isn't a diagnostic that is simply supplying program-generated data to the tape drive; there are also concurrent reads going on to pull in the data to be written from your source.

 

If the data is not there when the tape drive needs it, such that the pipeline becomes starved for data, two things happen.

 

First, the tape drive will start lengthening the inter-block gap so that the blocks are spaced farther apart, so that the data has a chance to get there in time. This will reduce your tape capacity.

 

Second, if there is a big miss, such that any reasonable lengthening of inter-block gaps can't slow the tape data rate down enough, the tape will write an EOT mark (two filemarks in a row) in case of disaster during this recovery, rewind a bit (space reverse a number of blocks), then get a running start and try again, overwriting the EOT mark with the next sequential tape blocks, etc. This greatly slows down the backup and also shortens the tape life; the tape is only rated for a certain number of passes over the heads.

 

Use of the CPU is a GOOD thing. It shows that the scheduler is working and that the CPU is fully occupied.

 

Solutions are: Add more memory, get a faster computer with more CPUs, dedicate a server to the backup job. It's a big job.

 

Bottom line: you are seeing the expected behavior.

 

Russ

[mlevin77]

I see. Now, most of the time when the CPU is high while Retrospect is writing, the server is perfectly responsive to other things (e.g., VNC access which I use to see how it's going). But occasionally, it seems to get really hung up where it won't respond to mouse clicks for minutes at a time; when I kill Retrospect, this problem goes away. Any idea why? Why is high CPU ok most of the time but not sometimes, and what is Retrospect doing that's special, during the times when I can't use it?

 

thanks,

 

Mike

 

[rhwalker]

I think that there may be some spin wait loops in the driver that were believed to be of short duration but which, over time, have run into conditions that take a long time. Such spin waits are often used when the context switch times would be too long for an (expected) short event to keep the pipeline filled.

 

It's not going to get fixed, though, because Retrospect 6 is dead, as are the G5 machines.

 

Russ