Nathan,
well you've got it about as good as it gets, I'd just make sure that
each database and log alocation on disk is of equal size (db can be
different than log but all of each should be the same).
Mirroring is always more efficient the closer to the hardware is is
being performed. Thus AIX mirroring is the lowest form of software
mirroring (therefore the highest performance software implementation)
while ADSM being an application on top of AIX would be at best next
best.
The answer would be the reorganization to limit the number of files in a
directory and consider implementing multiple nodes and corresponding
services, each to backup a separate directory structure. Your ADSM
server can serve up files to multiple nodes much faster than to one node
when you are limited by the database interaction with the client (as you
are in this case).
Steffan
Nathan King wrote:
>
> Steffan,
>
> You know what? I'm confused as to what's best - ADSM mirroring Vs. Hardware
> Mirroring.
>
> Personally I've always thought that Hardware mirroring would always be
> better. I understand the concern regarding
> the partial page write, but we've never experienced this (not that I'm aware
> of anyways). I know that some people have, but I don't think it's
> widespread.
>
> The bottom line is that when I attended IBM's introductory class (about a
> year ago) I was actually told that ADSM mirriroing was not only more robust
> but
> performed better than hardware mirroring.. infact I've heard this from other
> sources also. Somehow that's never rung true for me though.
>
> The truth of the matter is that I've seen no stats to prove either way. Has
> anyone actually done the homework here and made an equal comparison.
>
> Going back to the disk config. We have two disks in each drawer devoted to
> the database and one for the recovery log. Each of these disks is hardware
> mirrored.
>
> So that makes a total of 2*2*8=32disks (not of all which we are currently
> using) for the database and 16 for the recovery log.
>
> Nathan
>
> -----Original Message-----
> From: arhoads [SMTP:arhoads AT PACBELL DOT NET]
> Sent: Friday, July 23, 1999 4:18 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Performance
>
> Nathan,
>
> How many disks are devoted to 1st (only) copy of db & logs, each?
> Actually OS mirroring is faster than ADSM mirroring but ADSM
> mirroring
> is safer since ADSM can recognize a write problem to one copy and
> not
> propogate the problem to the (now good) copy.
>
> Steffan
>
> Nathan King wrote:
> >
> > Steffan,
> >
> > All disks are SSA. 8 Drawers in all with 16 disks in each drawer.
> The S7A is
> > an 8 Way RS64-II with 4Gb of memory.
> >
> > We use hardware mirroring for the db and logs since our ADSM
> server's are
> > configured for HA. So the disks are mirrored across the adapters.
> > I realise that you can get better performance by using ADSM
> mirroring but
> > when we're already mirroring for HA ,mirroring again just for a
> little extra
> > performance might not be cost effective.
> >
> > HA also prevents us from using write cacheing which does slow down
> > performance but shouldn't make much difference on restores as it's
> database
> > reads that you're doing.
> > The network between the client and the server is ATM. Both servers
> on the
> > same VLAN (so no routers involved).
> >
> > Yes, tried multiple restore sessions but didn't make any
> difference.
> >
> > Nathan
> >
> > > -----Original Message-----
> > > From: arhoads [SMTP:arhoads AT PACBELL DOT NET]
> > > Sent: Friday, July 23, 1999 12:45 PM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: Performance
> > >
> > > Nathan,
> > >
> > > You've got the right server: how are your database, logs and
> storage
> > > pools laid out? All on SSA? On how many drives each? Mirrored
> at ADSM
> > > level (db & logs)? What's the network like between that client
> and the
> > > server? Have you tried multiple restore sessions up to one per
> > > subdirectory?
> > >
> > > Steffan
> > >
> > > Nathan King wrote:
> > > >
> > > > Richard,
> > > >
> > > > I agree whole heartedly with your comments. However I think
> ADSM
> > > > Developement is well aware of the performance degradation
> caused by
> > > small
> > > > files.
> > > > As noted in the ADSM NT Server readme.
> > > >
> > > > Next to system hardware, the number and size of client
> files has a
> > > > big impact on ADSM performance. The performance when
> tranferring
> > > > small files is lower than when transferring large files.
> > > >
> > > > For example, using a 133MHZ pentium, FAT file system,
> local ADSM
> > > > client with no compression, and named pipes to a disk
> storage pool
> > > > throughput has been measured at:
> > > >
> > > > File Size
> > > > Throughput 1KB 10KB 100KB 10MB
> > > > KB/Sec 57 445 1280 1625
> > > > GB/hr 0.20 1.53 4.39 5.58
> > > >
> > > > Ok so this is a pentium 133 but with it being a local client
> you can
> > > rule
> > > > out the network as an issue.
> > > > Named pipes is the fastest way to backup locally on NT.
> > > >
> > > > So even if I took the hardware and made it five times faster
> and
> > > supposing
> > > > that by some magic that 5times faster hardware=5times faster
> adsm
> > > > performance, my 16gb restore of small 1-2kb files would still
> have taken
> > > > 16hours!!
> > > >
> > > > Unacceptable!
> > > >
> > > > Nathan
> > > >
> > > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > > Subject: Re: Performance
> > > > >
> > > > > ...
> > > > > >However when it comes to restoring servers which are 90%
> small files
> > > then
> > > > > we
> > > > > >may aswell be on a 4Mb Token Ring. We once
> > > > > >had the grand oppurtunity to restore the drive of an SMS
> Server which
> > > was
> > > > > >made up of about 16Gb worth of 2Kb log files.
> > > > > >This took 27hrs.
> > > > > ...
> > > > > > when it comes to small files Adsm just plain sucks!
> > > > > ...
> > > > > >Any thoughts?
> > > > >
> > > > > Nathan - You clearly had a very frustrating, unsatisfactory
> restoral
> > > > > experience. But realize that it's not helping the
> many
> > > customers
> > > > > on
> > > > > the mailing list to just receive a splat without any details
> as to how
> > > the
> > > > > restoral was performed...like network configuration, network
> load at
> > > the
> > > > > time,
> > > > > server system load, what else the ADSM server was doing,
> server
> > > > > configuration,
> > > > > server options, database cache hit ratio, client load, disk
> > > configuration,
> > > > > file system topology, ADSM client options, restoral command,
> results
> > > from
> > > > > testing various combinations in your configuration, etc.
> > > > >
> > > > > The great value in our mailing list is in discovering
> optimal
> > > techniques,
> > > > > and
> > > > > then sharing them, to the betterment of all. Realize that
> it's plain
> > > > > frustrating for the people on the list to see complaints
> rather than
> > > the
> > > > > results from measured analysis. And it does not point to
> solid
> > > evidence
> > > > > that
> > > > > IBM can react to in bettering the product - which will help
> everyone.
> > > > >
> > > > > Sure - there's a lot of frustration out in the customer
> base. But I
> > > as a
> > > > > customer feel that I have a responsibility both as a
> customer and a
> > > > > professional in the data processing field to do some
> research, to prod
> > > the
> > > > > system, change variables, and find out where the problems
> are. We can
> > > > > shower
> > > > > IBM with raw complaints and they can tell us about KLOC
> numbers, but
> > > > > working
> > > > > together with specifics will really solve problems. Yes,
> sometimes
> > > it's
> > > > > necessary to shake up vendors to get them to be responsive
> to the
> > > > > realities we
> > > > > face, but the rest of the time customers and vendor need to
> dig in and
> > > get
> > > > > to
> > > > > the bottom of what's really wrong. Hey, we're not here as a
> personal
> > > > > pursuit:
> > > > > we're in company and institutional positions as employees
> expected to
> > > > > effectively deal with problems for the better operation of
> the
> > > > > organization so
> > > > > that we can all make more money!
> > > > >
> > > > > Naturally, not all customer sites have the resources to
> pursue things
> > > to
> > > > > the
> > > > > depth that better-equipped sites can, and hence depend upon
> the
> > > results
> > > > > that
> > > > > others find. The mailing list is a dissemination and
> discussion point
> > > for
> > > > > what ails us and what we can do for each other as well as
> solicit the
> > > > > vendor,
> > > > > IBM, to improve conditions beyond the pointed problems we
> need to
> > > bring to
> > > > > the
> > > > > Support Center. IBM, in turn, needs to be responsive to the
> > > discontent
> > > > > evidenced in the customer base, which is the List's great
> value to
> > > them;
> > > > > and
> > > > > they need to feed back on optimal techniques, which they
> often do very
> > > > > well in
> > > > > the famous Redbooks [please encourage them]. From
> management feedback
> > > to
> > > > > the
> > > > > List, it is very evident that IBM is listening; but what
> they
> > > particularly
> > > > > want to hear is substantive feedback to allow them to
> respond as
> > > > > substantively. This is what we need to do.
> > > > >
> > > > > So channel that energy in ways that will help the general
> case.
> > > > >
> > > > > Richard Sims, BU
|
