|
I agree that it is a matter of the situation. I was at a shop that bought Very Large Capacity drives, slooooow seeks and put into a separate ASP for archiving their data. They would then mine this when needed in batch. Moving these files to a separate ASP freed up the smaller, faster drives for the day to day interactive processing and took the long running batch jobs, very large amounts of sequential data, to there own drives. Work great. % arm utilization down, performance faster. Christopher K. Bipes mailto:ChrisB@Cross-Check.com Sr. Programmer/Analyst mailto:Chris_Bipes@Yahoo.com CrossCheck, Inc. http://www.cross-check.com 6119 State Farm Drive Phone: 707 586-0551 x 1102 Rohnert Park CA 94928 Fax: 707 586-1884 *Note to Recruiters I nor anyone that I know of is interested in any new and/or exciting positions. Please do not contact me. -----Original Message----- From: email@james-w-kilgore.com [mailto:email@james-w-kilgore.com] Sent: Friday, October 15, 1999 12:27 AM To: MIDRANGE-L@midrange.com Subject: Re: Setting up ASP Doug, Geez ... it's only an example <g> Actually, the drive counts were from the original post as a point of reference, the percentage of usage was from my own experience. We did not have the same mix of drives. I did not mean to imply that our solution could directly be translated into their situation, just making a statement of factors to consider. In the real case, we doubled our total disk capacity (but not arms, due to drive difference) and dropped from pushing 70% to 35% utilization in the base ASP. I agree, it is all a matter of numbers. And one -must- do their own math. I also admit, I do not have the model number/capacity memorized, nor did I research the original post to truly understand the particular scenario. Duh, lower model number, lower capacity ... should have caught that one! <g> From your post, the 30 drives, each, have twice the capacity of the other 6. Our situation is not the same. We added half the number of drives at twice the capacity each. And yes, the customer services department (90% of the users) are creating high arm usage against a normalized gazillion file data base as they talk on the phone and require subsecond response time. The rest of the users are back room accounting that primarily perform batch type process against a different set of files. Well, OK, it's not a gazillion, but just off the top of my head, these staff members are performing at least 20 CHAIN/READE's once they enter an account number, until they want to display detailed invoice history. It's the detailed invoice history file that is the heavy hitter that we moved to a separate ASP. And once I told the back room people about this thing, wouldn't you know it, they started mining it! Go figure. Hence, by moving the activity against this file to a separate ASP, the 90% users were no longer penalized by access to this huge file. (3 years of detail) BTW, the file has enough records in it that it is created to reuse deleted records and it hasn't been reorganized in over two years. The last time we did it, it took 12 hours. And that was when we moved it to fewer drives/arms! Each month we archive out old data making room for new, but who knows where, or how far scattered, the complete set for a given entity will wind up. (The company only shuts down 2 days per year) Maybe what I'm getting to is that it's more than just the hardware numbers that determine if one should or should not have a separate ASP, but the user community and/or data base structure and demand that makes this kind of request an "it depends". BTW, I won't tease you too much for stating drive capacity in MB instead of GB, it's these types of easy mistakes that can cause someone to get picky with your post. <G> P.S. I've seen a lot of email shorthand, but never YMMV. I'm guessing: Your Move M... V...? Or maybe: You Make Me Vomit? I hope you're playing nice. Douglas Handy wrote: > > The math seems creative. If we ignore capacity lost to device parity > for the sake of simplicity, we have: > > <<snip>> a lot of good stuff detailing drive capacity planning > > I'm not arguing the theory, but I think you'd need more arms left in > the system ASP in relation to the recommended minimum and/or for the > historical data to be a bigger percentage of the total capacity to > come out ahead. Those scenarios can well exist, and evidently did in > your case, but I think they are the exception rather than the norm. > > How many arms did you move to a history data ASP, and how many arms > were left in the live data ASP? What is your system's recommended > minimum disk arms? > > YMMV, > Doug +--- | 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 +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.