Backup Process Using 100% CPU

[Jim Sobiesczyk]

I'm new to HPs and also for the company I'm working for. But I have a backup script that has the following in it:
-----------------------------------------------
#Always backup root filesystem
#
FS=/
echo "Starting backup of \"$FS\" `/bin/date`." >>$BACKUPLOG
cd $FS
find . -print | \
grep -v '/arc' | \
grep -v '/intra' | \
grep -v '/curly' | \
grep -v '/tempgis' | \
grep -v '/photos' | \
cpio -oBcdmuv > $NOREWIND_TAPE 2>$BACKUPDETAIL
echo "Backup of \"$FS\" completed `/bin/date`." >>$BACKUPLOG

# Run backup loop in subshell, and tee output to the backup log
(cat $FSYS | while read FS
do
echo "Starting backup of \"$FS\" `/bin/date`."
echo "Starting backup of \"$FS\" `/bin/date`." >>$BACKUPDETAIL
cd $FS
find . -print | cpio -oBcdmuv > $NOREWIND_TAPE 2>>$BACKUPDETAIL
echo "Backup of \"$FS\" completed `/bin/date`."
echo "Backup of \"$FS\" completed `/bin/date`." >>$BACKUPDETAIL
done) >> $BACKUPLOG
---------------------------------------------_

This is an HP9000 running HP-UX 11.00, which was created using Ignite-UX. The system has 1 Processor, 32 bit, 256 MB memory, and 2 swap spaces of 128MB each.

The CPU is running at 100% for the duration of the backups, and I do not see any apparent problems during this timeframe.

Any advice would be greatly appreciated.

[Bill Hassell]

I don't see where your script has defined NOREWIND_TAPE and since the script does not use "set -u" to prevent errors like this, you may want to see if the tape drive is actually running during the backup. CPU at 100% seems a bit high for a simple backup, even for this very small system. Does top report cpio as the user of all the CPU time?

[Jim Sobiesczyk]

Bill Hassell:

Thanks for your reply and I guess I should've given you at least 4 points... Anyhow, Here's the tape Defs I didn't originally include:

NOREWIND_TAPE=/dev/rmt/1mn
REWIND_TAPE=/dev/rmt/1m

And there -s no "set -u" within the script, so I don't know what that provides.

The backup runs between 1900 and 2200 hrs so I have no idea if the tape light's blinking.

I use sar for my daily Performance check, is it possible to run top thru CRON (maybe AT) to monitor during that timeframe?

[Patrick Wallek]

It is entirely possible that you have more than 1 issue here.

First, this is a rather small machine especially RAM-wise. 128 MB is not much for 11.0.

What may be happening is that the backup kicks off and the find commands run. Doing a find can impact a machine since it has to traverse down the mountpoing you are running it on. The find is also piping the output to cpio to write to the drive. What **MIGHT** be happening is that find is using a few resources, and cpio is using a few resources, but with only 128MB ram, you are using up the available resources and causing the system to page out. If that starts happening then you can severely impact a systems performance.

You can run top periodically and have it write its output to a file. Use the '-f filename' option to top. Have a look at 'man top' for more information on the options available to you with top.

You might also consider running a periodic 'swapinfo -tam' to check your swap utilization during the time the backup runs.

[Jim Sobiesczyk]

Patrick Wallek:

Thanks for the feedback. Those were pretty much my suspicions too. There's no other processes running during that timeframe, so I'll just run a 'swapinfo' cronjob during that timeframe. Not sure they'll spring for the memory as it's pretty expensive; They'd be going for a ne server instead.

[Jim Sobiesczyk]

Patrick Wallek:

Thanks for the feedback. Those were pretty much my suspicions too. There's no other processes running during that timeframe, so I'll just run a 'swapinfo' cronjob during that timeframe. Not sure they'll spring for the memory as it's pretty expensive; They'd be going for a new server instead.

[Bill Hassell]

set -u should be stanbdard for all scripts to prevent errors, sometimes catastrophic. The shell assumes that all variables are undefined and are given a null value. So if you created a script to remove all the files and directories in tmp, you might do this:

DIRNAME=tmp
rm -rf /$DIRNAM

(DO NOT TRY THIS ON YOUR SYSTEM)
Oops, there's a slight mistake. $DIRNAM should be $DIRNAME. But the shell doesn't know that and the resultant statement now reads:

rm -rf /

That statement is the end of your system--all files and directories on all disks will be removed with no recovery excepty re-install. Now if the set -u was inserted in the front of the script, the rm statement would not be executed because $DIRNAM is undefined and the script stops.

[Ted Buis · Accepted solution]

You have very little RAM, but even more is the minimal swap space. It is hard to believe that you don't have more problems with so little virtual address space.

[Jim Sobiesczyk]

Information provided by respondents.