|
Thanks Philipp, The hardware config is really odd, here is the controller breakdown DC01 2741-001 Operational Storage Controller DD009 6607-070 Operational Disk Unit DD004 6607-072 Operational Disk Unit DD003 6607-072 Operational Disk Unit DD002 6607-072 Operational Disk Unit DD001 6607-072 Operational Disk Unit OPT01 6321-002 Operational Optical Storage Unit TAP03 6390-001 Operational Tape Unit DD008 6607-072 Operational Disk Unit DD007 6607-072 Operational Disk Unit DD006 6607-072 Operational Disk Unit DD005 6607-072 Operational Disk Unit DD015 6607-070 Operational Disk Unit DC03 2748-001 Operational Storage Controller DD024 6717-074 Operational Disk Unit DD023 6717-074 Operational Disk Unit DD022 6717-074 Operational Disk Unit DD021 6717-074 Operational Disk Unit OPT03 6321-002 Operational Optical Storage Unit D01 283F-001 Operational Device Services DC02 2741-001 Operational Storage Controller DD014 6607-070 Operational Disk Unit DD013 6607-074 Operational Disk Unit DD012 6607-074 Operational Disk Unit DD011 6607-074 Operational Disk Unit DD010 6607-074 Operational Disk Unit DD020 6713-070 Operational Disk Unit DD019 6713-074 Operational Disk Unit DD018 6713-074 Operational Disk Unit DD017 6713-074 Operational Disk Unit DD016 6713-074 Operational Disk Unit And yes we are raid protected ; Sadly - this is beyond my understanding of which units are "used" and which are the raid packs - there are 2 other controllers, but they are for tape units. This is a "converted" 620 to a 820, so we still have a rack of the 620 left here for some disk units, and some disk units are in the new 820 rack, plus the 620 had a "side-cart" with disk packs too - This has been the "cost-conscious" way to upgrade - and it will not be changing anytime soon as long as the powers to be do not just hand over blank checks to us. Disk units getting hit heavy normally are 5, 6, 16, 18, 23, and 24 sometimes at 40-75% while the rest are at 2-5%. The idea/gulp/thought of backing off data, deleting, balancing, and restoring is scary; I don't know if I could get that much dedicated time for the next two months... Sadly too, due to too many canned packages, and too many years of too many cooks in the kitchen, the data files are spread in 18 different libraries; getting better, but so much clean up with no "visible" ROI keeps the "mess" in place. It is something I could look at when time is more available closer to February. Sorry for such a big post - and thank you for any other insights, or suggestions that do not involve hardware upgrades. -Mark -----Original Message----- From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On Behalf Of Philipp Rusch Sent: Tuesday, December 03, 2002 12:39 PM To: midrange-l@midrange.com Subject: Re: TRCASPBAL and STRASPBAL does not seem to work Which disks are the ones you notice to be "used more than others" ? Please give more info on your exact disk/controller configuration. At first sight it looks a little strange to me ... I see that disk 2-9 must be on the same controller in a RAID-config in an "eight-disk-set", the next 4 disks (10-13) are in a "four-disk-set" the next two disks have obviously been added to that set afterwards and No. 24 disk is completely out of that order ... Disks 16-23 and No.1 seem to be on the next controller in an "eight-disk-set" of another RAID-array, but how are they spreaded over the system busses / controllers, that's the question ... At first sight I would say that the 9th 8 GB disk is some kind of "extra" and that there is one 6607 disk lacking to make the bunch of eight disks for that second RAID-set complete. Second tip is to identify the data (-library) which is used the most, then save it to tape, completely delete that library (or files) and run STRASPBAL with *capacity as parameter, then do a restore of your data files. This should spread your data over more arms than before. But, for more performance tips, we definitely need more info. Regards from Germany, Philipp Rusch "Mark A. Manske" schrieb: > I have a few disks on a 820 at V5R1 that are being used much more > heavily than most others, thus hampering performance. > > I had run the TRCASPBAL for a week to collect data, then we > IPL'd and I had set things up in the startup to do the STRASPBAL, > it ran for 1 second - and did nothing. > > I looked through the archives, and on IBM's manuals which dragged me > to the Hierarchical Storage Management manual - > > None of which told me anything I did not already know, I am wondering > how the following commands "appear" to have done nothing - > note, these ran under QSECOFR user, and shows in the QHST log > that the ASP trace started, there is no log entry showing that it ended... > > On 11/23/2002 I ran the following command- > > TRCASPBAL ASP(*ALL) SET(*ON) TIMLMT(9999) > > and the next Saturday I ran the following command - > > STRASPBAL ASP(*ALL) TYPE(*USAGE) TIMLMT(1800) > > I set a time limit of 1800 so as to allow time to let system settle down > before the Sunday shift started working. > > Due to budget constraints and sporadic growth, we have a varied > collection of disk packs - as follows: > > Size > Unit Type (M) > 1 6717 6442 > 2 6607 3670 > 3 6607 3670 > 4 6607 3670 > 5 6607 3670 > 6 6607 3670 > 7 6607 3670 > 8 6607 3670 > 9 6607 3670 > 10 6607 3145 > 11 6607 3145 > 12 6607 3145 > 13 6607 3145 > 14 6607 4194 > 15 6607 4194 > 16 6713 6442 > 17 6713 6442 > 18 6713 6442 > 19 6713 6442 > 20 6713 8589 > 21 6717 6442 > 22 6717 6442 > 23 6717 6442 > 24 6607 4194 > > Any thoughts as to why this did not work for me "as expected" - > I was hoping to balance the work load of the heads/packs; some run at 0% to > 5%, > and just five to six will run at 70%-90% during many runs that we have going > in > batch all this while the CPU utilization is at 40% or less. > > TIA
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
