Memory solves all problems.

Tom Moulder quoting Ted VanDuyn

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Knutson, Sam
Sent: Friday, November 09, 2007 12:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Hi,

 

You are going to do a great service to the business if you can make the
case to use a valued asset you already own to improve service.  Go for
it! 

 

You can absolutely leverage the better part of 2 gigabytes of memory
just for DB2 buffer pools in V7.  Pay attention to peak storage demands
in DB2xDBM1 address space and remember that in V7 you can do some tricks
like data spaces you lose in V8.  Get more detailed advice on the DB2-L
list.

 

I think the level of concern may be to high here. 10G really is not that
much even on z/OS 1.7 we had LPARs several times that size without any
problem. There are some IEAOPTxx parms that can minimize RSM overhead on
1.7 that have been documented by IBM now but we found that made a
difference on really large LPAR's 40G - 80G not 10G LPARs.

 

Remember "There is NO I/O like NO I/O"!  

 

You can exploit extra real memory with products you already have in hand
easily. 

 

SyncSort or DFSORT will both exploit more memory to improve performance
easily.  Some adjustments may help things run the way you want.  Both
SyncSort and IBM provide good advice as well as good software.

 

Exploit VLF! Increase your cache size for CSVLLA and look at other
exploitation of LLA/VLF.

 

The best paging is no paging.  Paging on z/OS is a waste of cycles put
enough storage on you don't normally page.

 

DB2! One of DB2's best defenses against I/O is sufficiently large buffer
pools intelligently allocated with DB2 objects and thresholds.

DB2 V7 is OK.  DB2 V8 is much better at exploiting LOTS of storage.

 

Spare storage?  Are you planning on adding an LPAR?  If not setup your
HSA with plenty of room for dynamic growth and use the rest.  At $8K/G
or $10/G it seems wasteful to leave it idle.

 

 

        Best Regards, 

 

                Sam Knutson, GEICO 

                System z Performance and Availability Management 

                mailto:[EMAIL PROTECTED] 

                (office)  301.986.3574 

 

((((DO SOMETHING!) SMALL) USEFUL) NOW!) - computer pioneer  Bob Bemer

 

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 5:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Real storage usage - a quick question

 

Esteemed listers

 

I've a problem but I haven't any answer to it or better I've different 

answers. 

 

Say we have a machine with, just to say, 10 Gb of real storage. Only 5
are 

used by the only LPAR defined (actually there's  another very small
LPAR, 

but it's real small), which is a WLC LPAR and often it's CPU capped.  5
Gb 

remain unused. I asked why, as I'd like to enlarge my bufferpools in DB2


(for instance).  I've got these answers:

 

- Increasing real storage increases cpu overhead to managed more memory 

blocks in a cpu-constrained machine. 

- Increasing real storage causes more workload so more chanches to hit
WLC 

capping. 

- It's better to have some spare storage (5 Gb ?). 

 

Our workload is increasing and we have some occasional paging spikes.
DB2 

doesn't perform well due to too small pools. 

 

According listers' experience, is using the most part/all real  storage 

(perhaps with a spare memory for future incrases) a real problem ? Did 

anyone experimented any problem ? What are guidelines ? 

 

Thank you in advance

 

Max Scarpa

 

 

====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-- 
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM


No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM
 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to