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
|
