Veritas-bu

[Veritas-bu] performance?

2006-02-07 14:58:00
Subject: [Veritas-bu] performance?
From: austin.murphy AT gmail DOT com (Austin Murphy)
Date: Tue, 7 Feb 2006 14:58:00 -0500
It looks like you are maxing out your Gigabit ethernet cards.

My performance measurements of Gigabit ethernet were at best ~35MB/sec
for one normal gigabit link.  The only numbers I saw on the internet
that were substantially higher used jumbo frames.

I'm using an E450 (4x 296MHz)  with a 4-port GigaSwift (2 ports live,
2 offline).  I restricted the storage unit to only use 2 drives
(LTO-2) at once, each of which maxes out at ~30MB/sec native.

If you added a 4x GigaSwift card (or two) and arranged your network to
make use of the extra Gigabit links, you could pump more data to your
tapes.   If you can spend a bit more money you might try a faster
technology like 10GbE or IP over Fibrechannel.  Beyond that I think
you are looking at a media server.

Austin Murphy


On 2/7/06, Paul Keating <pkeating AT bank-banque-canada DOT ca> wrote:
>
> I'm running a Sunfire V880.
>
> 4x 1.2 GHz Ultrasparc III+ proc.
> 8 Gig Ram
>
> 6 internal 72 Gig disks.
>
> 1st pair disks mirrored OS /, /usr, /opt, etc etc
> 2nd pair disks mirrored /opt/openv (replicated to a standby system using
> Veritas Volume Replicator)
> 3rd pair disks one slice mirrored for VVR's SRL logs
>                     remainder of the two disks concatenated into a 96 Gig FS
> for a DSSU for a couple of small clients on 10Mb/s HD encrypted links.
>
> Pair of FC200 HBAs in 66MHz PCI slots
> Pair of GigaSwift GigE cards in 33MHz PCI slots (only 2 66Mhz slots on the
> machine.)
>
> the HBAs each feed 7 tape drives and 1 robot.....using Inline tape
> copy.....the robots are essentially mirrored....one onsite, one at the end
> of a DWDM link.
>
>
> I previously had only 3 drives at each site.....and added the additional 4
> at each site two weeks ago.
>
> with the 3 drives per site, I was getting approx 60MB/s total date to the
> three drives...so an avg of 20MB/s drive.
>
> The addidional drives were added for resiliency (Mgmt wanted two stus, one
> for dev, one for prod servers..so now we have a stu with 4 drives avail for
> prod, and 3 drives avail for dev)
> in the case where a client or two stuck at half duplex hangs up a drive all
> night, the remainder of jobs can finish...
>
> The problem is that, after adding the new tape drives, we don't get any more
> total throughput....seemd stuck at about 60-65MB/s, but now spread among
> twice the tape drives.
> This means that since more machines are backing up concurrantly (allowed
> because of the increased number of drives) that each machine is backing up
> slower...in effect, each machine is taking twice as long to back
> up....causing some major issues.
>
> Anyone know of any particular configs or issues that may be affecting us
> here? benchmarks on processing required to manage this many ITC jobs? we
> didn't see a performance hit in the lab, but never had this big of a system
> in the lab to really load it.
>
> I've been doing consant IOstat and netstat monitoring....no
> waits/queues/errors/collisions anywhere, except at one point for about 15
> minutes during the FULL window on the weekend, a few waits accumulated on
> the disks the /opt/openv resides on....but the performance was the same
> during that period as the remaining 24+ hours, where there were no waits.
>
> any new ideas would be welcome.
>
> Thanks,
> Paul
> ====================================================================================
>
> La version française suit le texte anglais.
>
> ------------------------------------------------------------------------------------
>
> This email message from the Bank of Canada is given in good faith, and shall
> not be
> binding or construed as constituting any obligation on the part of the Bank.
>
> This email may contain privileged and/or confidential information, and the
> Bank of
> Canada does not waive any related rights. Any distribution, use, or copying
> of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it
> immediately from
> your system and notify the sender promptly by email that you have done so.
>
> Recipients are advised to apply their own virus checks to this message upon
> receipt.
>
> ------------------------------------------------------------------------------------
>
> L'information communiquée dans les courriels en provenance de la Banque du
> Canada
> est soumise de bonne foi, mais elle ne saurait lier la Banque et ne doit
> aucunement
> être interprétée comme constituant une obligation de sa part.
>
> Le présent courriel peut contenir de l'information privilégiée ou
> confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
> diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par
> une
> personne autre que le ou les destinataires désignés est interdite Si vous
> recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
> délai à
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
> votre
> ordinateur toute copie du courriel reçu.
>
> Dès la réception du présent message, le ou les destinataires doivent activer
> leur
> programme de détection de virus pour éviter toute contamination possible.
>
>
>


<Prev in Thread] Current Thread [Next in Thread>