Re: ASPs

["Dave Shaw" <daveshaw@xxxxxxxxxxxxx>]

Walden,

No flames, but - the theory sounds better than the reality that I
experienced using EXACTLY this scheme back in '93.  Modern systems will
differ in details, but the I suspect the lesson learned may still apply.

System: F45, 80 MB main storage, running MAPICS/db as the primary
application and V2R2 of OS/400.

ASP 1: 4 9332-600's, mirrored (if you've forgotten, 9332's had 2 arms per
unit, so I had a net 8 arms for reads, 4 for writes)

ASP 2: Two trays of 9337-220's, RAID 5 (I don't remember exactly how many
drives in the units, but this ASP wasn't the bottleneck)

ASP 3: A pair of ancient EMC Guardian drives (9335 equivalents - 2 arms per
unit as far as the /400 could tell, but actually 4 arms per unit internally)
mirrored

ASP 3 was for journal receivers, and it was only a bottleneck on rare
occasions (heavy batch updates).  ASP 2 was never a problem.  ASP 1 was
working its arms to death much of the time, with low CPU utilization and
high numbers of page faults in the machine pool.  Doubling the size of the
machine pool from the "normal" value reduced the problem a bit, but did not
cure it.  The capacity utilization in ASP 1 was normally below 50%, although
tasks that built large objects in QTEMP (such as occasional queries and
certain MAPICS batch jobs) occasionally pushed it up to about 75%.

When V2R3 came out, we got the ability to mix mirrored and RAID drives in
the same ASP.  When we consolidated ASP's 1 and 2, we saw a tremendous
improvement, EVEN THOUGH we had not redistributed the operating system or
LPP's on the drives (the data had to be restored from tape when we made the
change, since the "old" ASP 1 wasn't big enough to hold it while we made a
copy).  The theory was that having the extra arms available for the many
temporary objects that OS/400 uses was what made the difference.  Had we
done a full restore, we probably would have seen some additional
improvement, but we didn't get the time to do that and it was running "good
enough" - finally!

Dave Shaw
Simpsonville, SC
---
If you would like to participate in the MAPICS-L mailing list send email to
MAPICS-L-SUB@midrange.com or go to www.midrange.com and follow the
instructions.

----- Original Message -----
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>


> OK, this is theory here as I haven't tried this but... I can see a design
> where three ASPs would be of great use from a performance point of view.
>
> ASP 1: Operating system and LPP
> ASP 2: Data files (PFs and LFs) and user programs
> ASP 3: Journal Receivers (you DO journal, right?)
>
> However the standard caveat of disk arms applies. If you have 2 drives in
> ASP 1 mirrored and they are 17G drives, you may have 17 Gig available, but
> you only have one arm. BAD. However, if you have, say, 3-4 arms and you're
> probably ok.
>
> Someone brought up the concern of disk contention because the low-level
> operating system programs would be all on ASP 1. While it's true that they
> are on ASP 1, they also page to the machine pool, not the user pool, and
are
> used so often that I'd bet good money they are always in memory so disk
> contention is not an issue for these programs.
>
> ASP 2 has all your data files and I'd guess 90% of your disk arm movement
is
> to retrieve data so make damn sure you have sufficient drive arms in that
> ASP. You're moving the arms around so much anyway that the additional
> movement to load programs would be minimal.
>
> Finally, journal receivers are _almost_ entirely a sequential write
> operation. If you can isolate them to their own ASP the arms will move
> sequentially with the write operation and usually be in the right spot to
> write the next block of data.
>
> Now, as I said, this is theory, so I await the flames <G>
>
> -Walden



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---