Re: Perfomance problem backupscript

Hi,

> R.J. Baart wrote:
> now a backup that took in case of 
> the SuSE distribution 2-3 hours takes now +/- 12 hours.

You should try to find out wether the bottleneck is in
- filesystem crawling performance
- star reading, formatting, transfer performance
- tape drive (and driver) performance

For that i would run the following tests :


To find out about the filesystem tree crawler performance
(which is quite a snail on my system) :

  time find ...your.directories... -ctime 1 >/dev/null

-ctime 1 will force find to actually obtain inode
information and to not just scan the name lists of
the directories. No payload data get read, though.

If this is similarly slow as your backup, then the
filesystem is to blame. (Super large directories ?)

I bet star crawls better than find, btw.


To find out wether the tape drive is to blame i would
pipe the backup into /dev/null rather than into /dev/st0

  time /bin/star ... -acl H=exustar ...your.directories... >/dev/null

(no -f option)

If this is as fast as your old system's backups then
the tape drive (resp. its new driver) needs mending.


If the first test runs fast and the second one slow,
then at least a part of the problem occurs during
the inner operations of star while reading data
from disk, formatting them and putting out.

One would then have to develop tests which impose the
same filesystem load but circumvent star in order to
learn more about payload data handling in your
filesystem.
(I do not expect star to be slow in general but rather 
being hampered by a peculiar situation on your disk.)

A test with -no-fifo would eliminate one more part
of your usual backup processing chain. -fifo is intended
to speed up (resp. smoothen) but one never knows ...


Have a nice day :)

Thomas