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
|
