Excellent point on removing the 'read' side of things from the equation. 
Who's to say that's not the bottleneck?

We thought we had our Domino systems pretty well tuned only to find major, 
unexpected backup improvements during a SAN migration project.

We were moving our Domino boxes from local disk to SAN to address 
capacity/scaleability.   After the migration, our backup times were 
reduced by nearly 80% across the board for Domino.  We were expecting 
performance benefits in the 25% - 30 %, but 80% was way off the charts.

Jeff Mery - MCSE, MCP
National Instruments

-------------------------------------------------------------------------
"Allow me to extol the virtues of the Net Fairy, and of all the fantastic
dorks that make the nice packets go from here to there. Amen."
TB - Penny Arcade
-------------------------------------------------------------------------



Terry Lemons <lemons_terry AT EMC DOT COM> 
Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
07/26/2007 10:20 AM
Please respond to
EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please respond 
to
lemons_terry AT EMC DOT COM


To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
Re: [Networker] Performance Tuning backup






The huge advantage of using bigasm is that it constructs data in memory,
and so eliminates the 'read' side of the backup testing: you just focus
on the 'middle' (cpu/IO buses/network) and 'write' side (tape/disk).

tl

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Davina Treiber
Sent: Thursday, July 26, 2007 10:52 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Performance Tuning backup

E Gold wrote:
> I have done monitoring and eliminated these as bottlenecks:
>
> Server network
> Tape drivesMemory
>
> Possible bottlenecks:
>
> Cpus (server has 4 xeon 2.8ghz with hyperthreading enabled)
> Client network (doubt it since it has 2 gigabit nics in a team)
>
>
> I feel this is either a cpu or networker tuning issue.

If I was in your position I would run tests with bigasm.

First I would run bigasm locally from the server. Set the target 
sessions to 1 on all drives and test with one session, two sessions etc.

If this scales well to all six drives I would try bigasm on your Lotus 
client, again with one session, then two sessions, perhaps all the way 
up to 12 sessions. These tests should point you to the next steps 
depending on the results.

I won't continue, because there are already many combinations of 
possible results. Try these tests and report back.

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type 
"signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER