Chris,

I agree with your point.  Of all the components involved in the process,
CPU, IOPs, IOAs, memory, and disk arms - the most likely performance
bottleneck is the number of disk arms in the secondary ASP.  I would
agree based upon Phil's reported disk arm activity.  At 90+% disk arm
utilization, the drives are swamped.  Perhaps it would be relevant to
point out that disk arm efficiency does not follow a linear curve.  If
your processor moves from 50% to 60% activity, you can generally assume
that it is doing 10% additional work.  This is not the case with disk
activity.  Generally, efficient disk arm activity peaks at about 40%.
This is because when the system issues a write request, it is helpful to
have a disk arm waiting to fulfill that request.  At 90+% activity,
there is a less than 10% chance that there will be an available arm and
the request will need to be queued.  This queuing multiplier causes
dramatic loss of efficiency and at Phil's stated utilization, it seems
certain that additional arms would increase throughput on the save and
thus reduce the overall save time.

This is not to say that there isn't some other bottleneck just around
the corner, but with the figures that Phil reported, faster writes
(either to disk or to tape) would shorten duration.

I would also be wary of the CPU percentage.  On a dual processor system
running a single save, I would expect the reported CPU utilization to
max out at 50%.  The reported figure of 35% (assuming all devoted to
save) would indicate that a single processor was running at 70% while
the other stood idle.  I'm willing to be corrected on this point, but I
don't think that the save will use multiple processors.

Regards,
Andy Nolen-Parkhouse

> Subject: RE: Reducing downtime for backups
>
> But as you increase disk arms, i.e. drives, you get higher through
put.
> As
> your through put goes up, your IOP, CPU and Main ASP Disk load will go
up.
> Now if those do NOT become a bottle neck, you will still see 90+% disk
> utilization on your secondary ASP BUT your run time will go down.
>
> Any body want to back me up on this?
>
> And I do not take any offense to you or anyone on this list
questioning
> what
> I post.

> Chris,
>
> Don't take this wrong, but I have trouble swallowing that.  I have to
go
> back to
> basics on this and in my (admittedly simplistic) view it goes like
this:
> CPU -
> Fast;   Disk - Not So Fast,   Tape - Really Slow.  For this job, the
CPU
> has
> nothing else to do, so it will always be waiting on the disks, so no
> matter
> how
> many I throw at it the disk busy percentage will always be high.  If
my
> lousy
> memory serves me correctly, IBM invented *SAVF files for the express
> purpose
> of
> reducing downtime for backups.  Has tape processing improved so much
that
> one
> tape drive can record data faster than 6 read/write heads on disk?  Or
is
> it
> possible that the RAID processing on these disks is causing so much
> thrashing
> that the whole system is bouncing up and down in the computer room?
>
> Phil
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.