× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. July 2016

RE: Improve R&D LPAR poor disk performance (10K spiiny) by using virtualized SSD from Production LPAR

Jim,

< Now the trick to avoid unpleasant issues with the unmatched sizes: Now stop allocation to the large drive. Life will go on just fine with that one being read only and all the read write activity on the other storage devices. >

IBM informed me that this is not recommended, can cause issues with balancing and STRASPBAL, should not be done.
But they do not have any documentation stating this.

Bottom line, keep all drives in the ASP the same size so STRASPBAL works correctly.
So, if re-building an LPAR or building a new LPAR, using virtual SSD, what would be a recommended size for both the load source and remaining drives in ASP1?
Slower, spinny drives I would create in ASP2, then force cold data to that ASP.

IBM also informed me that LIC, i5/OS, LPP must be in ASP1.
So my plan to try and move some system libraries to ASP2 would never work.

The R&D LPAR is fine for now.
But if I really want to fix it, I need to have all my virtual SSD in ASP1 and slow spinny in ASP2.

I can do this in one of two ways.
1) Total rebuild of LPAR.
2) Swap DASD using STRASPBAL.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Wednesday, June 29, 2016 2:46 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using virtualized SSD from Production LPAR

Build your load source as needed.

Build the other storage devices to the size you need (remembering more storage devices are better than fewer with 6 as the absolute minimum)

Now the trick to avoid unpleasant issues with the unmatched sizes: Now stop allocation to the large drive. Life will go on just fine with that one being read only and all the read write activity on the other storage devices.

Or my preferred method: Create the partition with the sizes/quantities you want. Save Restore it into the new environment.
A) It gets it set up the way you want it
B) Tests your recovery plan
C) Sets up all the shared access paths better
D) gives you a chance to clean house a bit.

Downside: takes a while.

--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Wednesday, June 29, 2016 1:33 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using virtualized SSD from Production LPAR

I've been informed that if I decide to migrate my load source from current 10k spinny to virtual SSD, I should make the virtual SSD the same size as my 10k spinnys, which are 571gb.
for performance reasons, all disks in the ASP should be of the same size.
Currently, R&D ASP1 has 24 571gb 10k spinny, Raid5 , two parity sets, no hot spare.
I would create 1 additional virtual SSD, 571gb, and add it to ASP1.
Bit of a waste of virtual SSD for a load source.

Any thoughts from the group?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Monday, June 27, 2016 10:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using virtualized SSD from Production LPAR

Preliminary performance numbers.

A complicated batch process taking 2 hours on 10k spinny took 53 minutes on R&D with virtual SSD, equaling or exceeding Production LPAR times.
5 NWSD with 6 100gb NWSSTG each, 30 NWSTG total.

My manager asked if I could somehow improve our R&D test runs to be closer to Production run times.
I knew the 10k spinny were the issue.
I had extra SSD on Production LPAR which was purchased for a project that was later cancelled.

I virtualized 3tb of SSD from Production LPAR to R&D LPAR.

The R&D LPAR has a large amount of cold data, 8TB, which would be hard to cost justify 100% SSD.

On the R&D LPAR, using RSTLIBBRM, restoring to ASP2 , (5 NWSD with 6 100gb NWSSTG each, 30 NWSTG total). which is the virtual SSD on the client R&D LPAR, I can control by library which R&D environment needs performance.

I had some other posts about trying to virtualize the 10k load source, but at this time I do not think this will be necessary.

I've seen this many times over the years with improvements to the DASD subsystem.
Majority of the time, DASD improvements will result in the largest savings when it comes to large batch processing.

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Holger Scherer
Sent: Monday, June 27, 2016 1:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny) by using virtualized SSD from Production LPAR

For performance - at least 6 NWSSTG per system, max 16 (32?) NWSSTG per NWSD.

for performance comparison HDD/SDD - absolutely same config (# NWSSTG / NWSD / Disk size)

If performance is not *that* issue -> one big NWSSTG is ok ;-)

-h



Am 27.06.2016 um 19:41 schrieb Rob Berendt <rob@xxxxxxxxx>:

I just remember something about 6 or more storage spaces per nwsd.
And if you have a few storage spaces it's better to also have more nwsd's.
Like, instead of maxing out the storage spaces per nwsd, create more
nwsd's.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

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.