On Thu, 13 Apr 2017 20:41:29 +0000, Turner Cheryl L <[email protected]> 
wrote:

>If we were to follow the 1:1 ratio now, we would be increasing ESQA even more. 
>For example: Our MAXSPACE=16000M and have allocated  512 G real memory. We 
>currently have 9 3390-27 local page datasets defined for that system.  Our 
>past rule of thumb would suggest that 11 entire 3390-54 local page datasets 
>are actually required.     
 
>What we aren't sure of is if we are extremely oversized and can and should 
>back our current paging subsystem allocation down some to recover some of the 
>ESQA currently in use. Did I mention, we hardly, if ever, page?

To at least some degree it depends on what you're using that real for, but my 
general expectation would be that you probably don't need to back that by a 1:1 
ratio.  If that memory is being used by large production DB2 buffer pools, you 
really want those to be fixed 1MB pages anyways, so they're not going to page 
out. So why have paging space to back them?

If the memory is there to support a multitude of smaller non-production things 
(such as a plethora of Webspheres) that are only sporadically use, then maybe 
you don't mind if some of them are paged out and so maybe you need some paging 
space to support them. But the benefit of large memory is certainly reduced if 
you let them page.

So how much does one really need? I don't think you can necessarily use a rule 
of thumb anymore, I think you have to look at how you're using the memory and 
for what. But I will say I really like SCM (FlashExpress): it makes configuring 
a relatively large paging space easy and painless and if it's actually used it 
will perform much better than paging to DASD, even SSD DASD. It's not as cheap 
as DASD, but in the grand scheme of things it's not *that* expensive. And it 
also can make dumps much more tolerable. I might go so far as to say that any 
machine over some threshold of real should really (!) have SCM. 

Scott Chapman

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to