slow backup using gig fibre

[SM_3]

hp-ux 11i

Whilst using gig ethernet with netbackup client 5.1, I get 9mb per sec.
Using gig fibre I get 1mb per sec.
gig fibre is set at 1000Full duplex

What speed do you get using gig fibre?

Thanks

[Florian Heigl (new acc)]

It depends, mostly on adapter tpye and using jumbo frames or not.

copying ram-to-ram with good adapters (syskonnect etc) should go well up to 95MB/s, and copying from our always-overloaded testfiler through a crappy d-link nic through a low-end 3com switch will give 12-15MB/s.

Here at work 30 or 40MB/s would be normal, anything more exceptional.

But: both 1MB/s and 9MB/s is out of discussion, at first I'd check if there is any faulty hardware or something else badly misconfigured.

Are You saving directly to tape? Maybe it's something easy like raising the block size - but at first I would check the fibre cabling and gbics.

Do some raw throughput testing like
time dd if=/dev/zero obs=1400 bs=1024k count=1000 | ssh -cypher=none netbackup_server "dd of=/dev/null"

[Peter Godron]

SM,
seeems to be common complaint, judging by amount of data available.
Most seem to be hardware related (block size,going directly to tape ...). First step would be to ensure all relevant patches are loaded. Then some dd tests to establish a performance base line.
Regards

[Steven E. Protter]

Actual performance is going to be much slower than theortical top speed. Lots of factors, including the ios of the switch that can effect it.

Consider the Fiber related patches on this list:

PHCO_29379 1.0 LVM commands cumulative patch
PHKL_26743 1.0 LVM Cumulative Patch
PHKL_28984 1.0 Fibre Channel Mass Storage Patch
PHKL_29365 1.0 SCSI IO Cumulative Patch
PHKL_29539 1.0 PDC_SCSI_PARMS,iCOD,vPars,IPMI,OLA/R
PHKL_29685 1.0 SCSI Ultra160 Cumulative Patch
PHKL_25506 1.0 asyncio driver patch

Except for the FCMS and asyncio driver patches installed, there are
later HP recommended versions for all of the above.

Recommend updating system with the following patches (plus any patch
dependencies needed with these):

PHSS_28509 s700_800 11.11 Tachyon TL Fibre Channel Driver Patch
PHKL_32235 s700_800 11.11 VxFS cumulative patch for three way deadlock
PHCO_30698 s700_800 11.11 LVM commands cumulative patch; LVM OLR
PHKL_31216 s700_800 11.11 LVM Cumulative Patch; LVM OLR; SLVM 16 Node
PHKL_30510 s700_800 11.11 SCSI IO Cumulative Patch
PHKL_30523 s700_800 11.11 PDC_SCSI_PARMS,iCOD,vPars,IPMI,OLA/R
PHKL_30511 s700_800 11.11 SCSI Ultra160 Cumulative Patch

SEP

[SM_3]

I have 9mb per sec on most other clients, it's just the fibre that's mis-behaving.

I thought maybe changing the default /dev/tcp settings.

[SM_3]

forgot to mention, the fibre is connected to a Fast Iron 8000 switch.

[Florian Heigl (new acc)]

SM - please try testing the raw throughput, the FastIron should be dimensioned well enough for getting more than what You see.

I don't think it's time for tuning via /dev/tcp until You get a much better level of base performance.
Probably this is flaky hardware (GBIC,Cable,Adapter) somewhere or a very strange setting in the switch.
Candidates for that: flow control, backpressure, autoneg and mismatched jumbo frame settings. the duplex settings are always hardwired to full-duplex on fibre of course, but the results You get when one party has autonegotiation enabled and the other has not are sometimes ... strange.

[SM_3]

tried the dd command but the system did not recognise the cipher option "=none."

With FTP I got 9mb per sec which is good since we have a 100MB per sec cap on the switch, i.e., with the fibre nic

Looks like a netbackup issue. Will raise a call with veritas.

Will give the feedback later.

Thanks.

[Florian Heigl (new acc)]

I'm glad to see this is not a issue with the network card itself.

Do You have a way of spooling the backup data through a disk device on the server?

This might in basic be a tape start/stop issue.

[Dave Hutton]

It obviously depends on the speed of your tape devices.

Also there is a performance tuning whitepaper that talks about improving performace. I know < 5.0 there are a few files you can create to greatly improve your performace. I'm guessing 5.1 these files still exist.

These are created on the client side along with my values which are adjustable so you will want to play around with them.
(This is for the media servers/masters, even though I stick this file on my clients just to be consitant, but I don't think this value does anything)
/usr/openv/netbackup/NET_BUFFER_SZ (2621644)

(these are for the clients)
/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS (32)
/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS (262144)

Those values seem to work well for me, using NB 5.0, LTO2 drives with Gig ethernet.
If you change those too high you can get successful backups yet the data is bad.

Heres a doc that talks about these settings which you may want to read first:
http://seer.support.veritas.com/docs/183702.htm

[SM_3]

"Do You have a way of spooling the backup data through a disk device on the server?"

I see the point, but the other gig copper nic perform a 9MB per sec to the tape device.

[SM_3]

The problem was due to an incorrect rate shape on the fibre port.