Backup performance is pants!!!

[George_Dodds]

I'm sure there's threads allready out there about this but i cant find em(Hungover!).

Right is there any way to find out/monitor the data transfer rate between scsi card and a dlt drive.

Server is L2000 and drive is dlt 40/80, recently our informix backups have been dragging there heels.

I need to find out where the problem lies, as it is taking a day to fill a tape(currently on tape 4 of the backup!!).

Cheers

George

[Carlos Fernandez Riera]

How are you doing backups? dd, fbackup, Omniback...?

HOw are disks and DLT connected?...

Any information will be usefull...

[George_Dodds]

Using informix's ontape command to run the backup, I do have a omniback solution for the near future, but not at the moment.

Dlt is directly connected to the server via scsi.

General box performance in good.

Ta

George

[U.SivaKumar_2]

hi,
what is the SCSI ID of that tape drive?. Try setting the SCSI ID to lower priority ID i.e.
0 or 1.

regards,
U.SivaKumar

[harry d brown jr]

George,

glance

live free or die
harry

[U.SivaKumar_2]

hi,
you can also try increasing tape block size TAPEBLK parameter in the "onconfig" file for improved
performance.
regrds,
U.SivaKumar

[Steve Lewis]

I have had this before with ontape.
In a dual CPU machine, ontape started going really slowly. Logging a call with HP got me nowhere, since the response centre pointed out that fbackup was writing at normal speed, therefore an informix problem. Logging a call with informix got me nowhere since they said that they were just doing a simple i/o call to write a block, therefore an HP-UX problem.
You can try the following which sometimes works:
Immediately before starting an ontape to the tape drive, do one to /dev/null.
Set your block size to 128 (less and more than this reduces performance).
Remove blobspaces and use tablespace blobs (my problem only manifested itself on dual-cpu machines with blobspaces).
Verify that fbackup to the drive runs at the normal speed, to rule out hardware issues.
Don't chain multiple tape drives on a single SCSI bus.

[George_Dodds]

Cheers for the info Steve, our box is dual cpu as well.

When the current backup eventually finishes, i will test using fbackup to see if it's a hw issue.

Cheers

George

[Bill Hassell · Accepted solution]

DLT (and DDS and other streamers) are very fast devices and require a constant stream of data to keep them busy. It would be terribly inefficient to write a block (Unix block of 512 bytes) at a time. The overhead in the SCSI driver and hardware handshake would be a significant portion of the total transfer time. And if your system is busy, a simple backup tool (like tar or cpio or others) can't read the data fast enough.

The result is massive numbers of restreams, or stop (because of data starvation), backup, resync and start streaming again. A backup could take 10 to 100 times longer than normal and the wear on the drive (and tape) would be enormous.

fbackup, like other commercial backup tools, starts multiple processes to keep the buffers filled. The default is 2 which is always too small. Additionally, the other parameters need to be adjusted from their default (reel-to-reel) values using a config file:

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

This will work with all models of DLT and DDS drives and improve throughput. Informix would need a similar feature to properly support modern DLT drives.

[George_Dodds]

Bill, you are a veritable fountain of knowledge as ever, cheers ;)

Dont know enough about informix to have a play, have sent the replies to our dba in oz to see what he can do.

Ta

George

[Frank Quinteros]

George,

You can always:
determine the size of the data to backup,
compare previous backup times (beginning and ending)
compare current backup times

divide times/data = rate of backup.

Compare.

I know, this is silly, but it works (to a degree).