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
|
