Re: Real storage usage - a quick question
To follow-up on the case here when a DB2 DBA accidently overcommitted storage to DB2 an APAR PK58272 is now open against DB2 to provide a WTO message that can be automated to notify and escalate if a DBA does this and gets the message DSNB542I. PK58272 MAKE DSNB542I A WTO MESSAGE, SO THAT THE CHECKING OF THIS MESSAGE CAN BE AUTOMATED. Here a DBA transposed some numbers in a job and got DSNB542I but did not immediately back out the changes. DSNB542I -DB2P DSNB1ABP THE TOTAL ACTIVE PGFIX YES BUFFER POOL STORAGE EXCEEDS THE DB2 ALLOWED REAL STORAGE CAPACITY WHEN EXPANDING STORAGE FOR BUFFER POOL BP24 CURRENT VPSIZE = 40 NEW VPSIZE = 200 REAL STORAGE CAPACITY = 73728 MB. DSN9022I -DB2P DSNB1CMD '-ALT BPOOL' NORMAL COMPLETION Best Regards, Sam Knutson, GEICO System z Performance and Availability mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... 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
Re: Real storage usage - a quick question
I have never encountered a bad page dataset. I have encountered page errors within a page dataset (usually due to some sort of IO error). The last time I encountered this (circa 1985) the task referencing the bad page received a S028 abend. The system marked the slot in the page dataset as bad and proceeded on it's merry way. snip As for pagedel - if the page data set hits an error, I think ASM marks it bad, writes an abend089 dump and then either a number of address spaces will fail (those with pages out there on that data set) or only one slot is bad, and then the rest of the system goes on. /snip -- 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
Re: Real storage usage - a quick question
Shane, right. It wasn't me who introduce the PAGEDEL command. In the past we had several reserved page datasets which was used/shared by several LPARs. Automation add's and delete them on demand. This was fine for several years unless this add/delete happen more frequently because of some DB2 dumps after DB2 V8 comes real. I wasn't aware of this bad effect until we fall into this. Well just an IPL. Also I don't see the PAGEDEL command is dangerous in some cases. Perhaps I miss some docs or it still isn't documented. However we hit this and perhaps we aren't the only one. Best would be to document this behaviour for the PAGEDEL command. Roland On Fri, 2007-11-09 at 21:35 +0100, Roland wrote: Also AFAIR the PAGEDEL didn't release all storage so massive combination of PAGEADD/PAGEDEL can cause problems too. PAGEDEL ???. That's what IPLs are for. I'm with Mark - you add a page dataset, you leave it there. Get any current problems sorted, then worry about the preferred configuration later. There may be reasons for removing page datasets (rarely), but certainly not in the heat of battle. -- 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
Re: Real storage usage - a quick question
A question on PAGEDEL: What happens if a page data set goes bad and you don't delete it? It's just I vaguely recall a long time ago there being a problem under such circumstances. VERY vaguely recall by the way. But that might be a reason to be able to do a PAGEDEL. Martin (who's never done a PAGEDEL nor PAGEADD neither) :-) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: Real storage usage - a quick question
A question on PAGEDEL: What happens if a page data set goes bad and you don't delete it? Since at least MVS/SP 1.1, the ASM and MVS recovery handles that. There should be never a reason to PAGEDEL. It doesn't hurt to be over-allocated on aux store, these days. - Too busy driving to stop for gas! -- 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
Re: Real storage usage - a quick question
On Thu, 8 Nov 2007 09:02:05 +0100, Max Scarpa [EMAIL PROTECTED] wrote: Jumping from 4 to 25 Gb isn't a good idea, but if I have 4 Gb used and 4 unused I think there's no difference in adding, say, 2 Gb (so using 6 Gb as total). Consider we have bursts or spikes in paging and for instance our DB2 isn't performing well even if 'all runs well' as someone say. If you are paging at all, then add all 4 Gb. Anyway is there any rule of thumb, having z/OS 1.7, for max central storage ? I mean, is there a suggested value to avoid RSM overhead before z/OS 1.8 (1 Gb ? 5, 10 or which value for central storage) ? I don't think there is an ROT, just the warning that if you aren't paging at all, don't add gobs of storage just because.A few GB isn't going to be noticeable or measurable. No need to micro-manage. It also isn't going to matter unless you are running at or near 100% busy and you want to squeeze every last cycle out of the machine that you can. I say this because a lot of shops do run that way. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Real storage usage - a quick question
Using more memory in DB2 V8 running on z/OS 1.7 can still be a net positive. There are some things you can set in IEAOPTxx to reduce overhead. z/OS 1.8 is the real solution for handling large memory more efficiently in z/OS but the benefits of large buffer pools with DB2 V8 are pretty significant. /* */ /* SRM INVOCATION INTERVAL CONSTANT */ /* SET TO 3K PER LOCAL FIX FOR OA18452 TILL CLOSURE... SJK MAR-08-07 */ /* WAS 1K*/ RMPTTOM=3000, /* */ /* UICFRAMESCHECKTIME is the number of frames (in thousands) that*/ /* RSM processes on one address space queue before checking for the */ /* RSM timeout value which is internally defaulted at 25ms. While*/ /* the system is running address space queues to do UIC updating the */ /* RSM lock is held. Other callers who need this lock (such as to do */ /* a page fix to do DB2 I/O, or assigning a frame) will spin waiting */ /* for the address space queue to be processed. The default */ /* UICFRAMESCHECKTIME is 525 (2GB). */ /* */ /* Set to 5 per IBM WSC ...SJK JUL-18-07 */ UICFRAMESCHECKTIME=5 The support for UICFRAMESCHECKTIME was provided with APAR OA07055 which can be reviewed for additional information. YMMV so do your own research and testing and consider consulting IBM if you think you really have a problem this may help. I wouldn't suggest you go making changes to IEAOPTxx to add either RMPTTOM or UICFRAMESCHECKTIME if you are happy with your current z/OS 1.7 system. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Wednesday, November 07, 2007 9:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question In z/OS 1.8 the memory management is much more conducive to large memory. They no longer use the least recently used algorithm and no longer check every page. This has made a big difference for us. Under 1.7 we had issues with large real memory sizes due to the constant checking by RSM. This is no longer the case and we have increased our memory dramatically with no performance hit. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 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
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
Re: Real storage usage - a quick question
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
Re: Real storage usage - a quick question
John Reda wrote: Using large quantities of storage can, in the right situation dramatically improve performance. But (there's always a But...) you need to be VERY careful, make sure that the storage you are going to use is not only available right now but that it will be available for the duration of your job. You also need the ability to back off when the system gets busy for an unexpected reason. The consequences of over committing storage can be catastrophic. If there is a system outage related to storage and you are holding a big chunk, it will be your fault. It doesn't matter what else happened, it's your fault and this time it is not just one person or group, it effects everyone running on the system. A classic example is when a large address space - eg DB2's DBM1 (not to pick on it but it can be MASSIVE) - dumps... You'd better be able to contain the dump space requirements. Worst case in paging space. Better case in memory, though that might not be economically feasible. I've known 3 separate cases of customers either running out of paging space or getting awfully close. And no, I don't know the syntax for PAGEADD or whatever it's called. Do you in a hurry? :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: Real storage usage - a quick question
Tom Beretvas used to have a saying the answer to all DASD performance problems was More Cache!. Now he said that tongue in cheek and then illustrated that there was some truth in it and of course it was not always the answer. So in the same vein if you want to say More Memory! is the answer to all performance problems I will agree:-) I like memory. It is the cheapest thing I can buy to improve performance. It is of course part of a balanced solution but the millions of dollars people will spend on processors and then try to save a few gigabytes of memory and allow those precious processors to spend cycles doing paging or allow applications to incur delays due to wait for I/O that is easily avoided boggles me. Memory is cheap relative to other System z resources you can buy. Today's 2094 is not your old 4381 just faster. When you can combine current IBM operating system z/OS, current subsystems DB2, MQ, IMS, and current balanced hardware solutions z9 and DS8300 the sum is greater than any of the parts with very few weak spots. Plenty of memory on the host processor is an enabler for a lot of z/OS and DB2 exploitation. Don't put DB2 or z/OS on a memory starvation diet and then complain it is not up to peak performance demands. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Moulder Sent: Friday, November 09, 2007 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question Memory solves all problems. Tom Moulder quoting Ted VanDuyn 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
Re: Real storage usage - a quick question
Using large quantities of storage can, in the right situation dramatically improve performance. But (there's always a But...) you need to be VERY careful, make sure that the storage you are going to use is not only available right now but that it will be available for the duration of your job. You also need the ability to back off when the system gets busy for an unexpected reason. The consequences of over committing storage can be catastrophic. If there is a system outage related to storage and you are holding a big chunk, it will be your fault. It doesn't matter what else happened, it's your fault and this time it is not just one person or group, it effects everyone running on the system. Picture those old movies where there is a line of people. They are asked a question and the guilty party is supposed to step forward. Everyone but one person takes a step back leaving just one person. That person is left with a bewildered look on his face and is instantly guilty. John Reda Syncsort, Inc. 201-930-8260 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Knutson, Sam Sent: Friday, November 09, 2007 1:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question snip 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. snip 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 -- 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
Re: Real storage usage - a quick question
On Fri, 9 Nov 2007 19:32:51 +, Martin Packer [EMAIL PROTECTED] wrote: You'd better be able to contain the dump space requirements. MAXSPACE= on your dump options. Worst case in paging space. Better case in memory, though that might not be economically feasible. I've known 3 separate cases of customers either running out of paging space or getting awfully close. And no, I don't know the syntax for PAGEADD or whatever it's called. Do you in a hurry? :-) Yes, but maybe I can't type that fast or probably I am not looking at the console. :-) That is what automation is for. But using automation to add pagespace after a aux shortage message begs the question: If you are already putting the DASD aside for the spare page data set(s), why not just add it to begin with? Perhaps in the old days you kept a spare on the back end of some volume where response time mattered. But now, unless you have SLED DASD that wouldn't be an issue (unless you had it on the back of a volume that you let get RESERVEd). With customizable volume sizes... or even if you don't use custom sizes (DR considerations), DASD is still cheap enough to define all your spares up front and always have them available for the worst case scenario. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Real storage usage - a quick question
Hmmmh IBM-DB2 l2 often refuse to even at partial dumps Also AFAIR the PAGEDEL didn't release all storage so massive combination of PAGEADD/PAGEDEL can cause problems too. We had this problem because of automation, sick Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Friday, November 09, 2007 8:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question On Fri, 9 Nov 2007 19:32:51 +, Martin Packer [EMAIL PROTECTED] wrote: You'd better be able to contain the dump space requirements. MAXSPACE= on your dump options. Worst case in paging space. Better case in memory, though that might not be economically feasible. I've known 3 separate cases of customers either running out of paging space or getting awfully close. And no, I don't know the syntax for PAGEADD or whatever it's called. Do you in a hurry? :-) Yes, but maybe I can't type that fast or probably I am not looking at the console. :-) That is what automation is for. But using automation to add pagespace after a aux shortage message begs the question: If you are already putting the DASD aside for the spare page data set(s), why not just add it to begin with? Perhaps in the old days you kept a spare on the back end of some volume where response time mattered. But now, unless you have SLED DASD that wouldn't be an issue (unless you had it on the back of a volume that you let get RESERVEd). With customizable volume sizes... or even if you don't use custom sizes (DR considerations), DASD is still cheap enough to define all your spares up front and always have them available for the worst case scenario. -- 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
Re: Real storage usage - a quick question
On Fri, 2007-11-09 at 21:35 +0100, Roland wrote: Also AFAIR the PAGEDEL didn't release all storage so massive combination of PAGEADD/PAGEDEL can cause problems too. PAGEDEL ???. That's what IPLs are for. I'm with Mark - you add a page dataset, you leave it there. Get any current problems sorted, then worry about the preferred configuration later. There may be reasons for removing page datasets (rarely), but certainly not in the heat of battle. Shane ... -- 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
Re: Real storage usage - a quick question
Yeah - and the best thing about buying more memory is IBM doesn't raise the price of the software like they do if you buy a faster processor! Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Knutson, Sam [EMAIL PROTECTED] Memory is cheap relative to other System z resources you can buy. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 -- 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
Re: Real storage usage - a quick question
On Nov 9, 2007, at 6:53 PM, Eric Bielefeld wrote: Yeah - and the best thing about buying more memory is IBM doesn't raise the price of the software like they do if you buy a faster processor! Eric: Ss!!! you might give them ideas . Ed Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Knutson, Sam [EMAIL PROTECTED] Memory is cheap relative to other System z resources you can buy. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 -- 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 -- 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
Re: Real storage usage - a quick question
Jumping from 4 to 25 Gb isn't a good idea, but if I have 4 Gb used and 4 unused I think there's no difference in adding, say, 2 Gb (so using 6 Gb as total). Consider we have bursts or spikes in paging and for instance our DB2 isn't performing well even if 'all runs well' as someone say. Anyway is there any rule of thumb, having z/OS 1.7, for max central storage ? I mean, is there a suggested value to avoid RSM overhead before z/OS 1.8 (1 Gb ? 5, 10 or which value for central storage) ? Thank you in advance Max Scarpa Mark Zelden [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/11/2007 17.30 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Real storage usage - a quick question On Wed, 7 Nov 2007 10:22:30 -0500, Veilleux, Jon L [EMAIL PROTECTED] wrote: In 1.7 RSM took more CPU when we increased our real storage since it had to look at every frame for the UIC. It's a simple equation, more frames more CPU to scan them for their UIC. Our performance area noticed that there was an increase. I believe that it showed up as uncaptured CPU or MVS usage under OMEGAMON CPU utilization. Exactly. So if you are running below z/OS 1.8 and aren't paging, don't just add 25G of storage because you have it laying around doing nothing since you upgraded your processor and added all the cheap memory. We've discussed this before. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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 -- 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
Re: Real storage usage - a quick question
You should have the PTFs for z/OS APAR OA17114 installed if you are using paged fixed buffers in DB2 V8. Not having it was one of the causes of a z/OS outage here when a DB2 DBA accidently overcommitted storage to DB2. APAR Identifier .. OA17114 Last Changed 07/07/03 IRA400E 04,PAGEABLE STORAGE SHORTAGE HIGH VIRTUAL STORAGE FIXED IN ABOVE FRAMES INSTEAD OF HIGH FRAMES Symptom .. MS MSGIRA400EStatus ... CLOSED PER Severity ... 2 Date Closed . 07/05/31 Component .. 5752SC1CR Duplicate of Reported Release . 720 Fixed Release 999 Component Name 5752 REAL STOR Special Notice HIPER Current Target Date ..07/06/15 Flags RESTART/BOOT/IPL SCP ... Platform Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List: PTF List: Release 709 : UA34631 available 07/06/13 (F706 ) Release 720 : UA34632 available 07/06/13 (F706 ) Release 730 : UA34633 available 07/06/13 (F706 ) Release 740 : UA34634 available 07/06/13 (F706 ) You should also need to educate your DBA's that they must confirm all increases in DB2 bufferpool storage. If they get any error they should immediately back out whatever they did. A DBA transposed some numbers in job and got DSNB542I but did not immediately back out the changes. DSNB542I -DB2P DSNB1ABP THE TOTAL ACTIVE PGFIX YES BUFFER POOL STORAGE EXCEEDS THE DB2 ALLOWED REAL STORAGE CAPACITY WHEN EXPANDING STORAGE FOR BUFFER POOL BP24 CURRENT VPSIZE = 40 NEW VPSIZE = 200 REAL STORAGE CAPACITY = 73728 MB. DSN9022I -DB2P DSNB1CMD '-ALT BPOOL' NORMAL COMPLETION It would be useful if DB2 allowed an installation to set the percentage to decline to allow buffer pools increases beyond rather than hard coding 80%. DSNB542I csect-name THE TOTAL ACTIVE PGFIX YES BUFFER POOL STORAGE EXCEEDS THE DB2 ALLOWED REAL STORAGE CAPACITY WHEN EXPANDING STORAGE FOR BUFFER POOL bpname CURRENT VPSIZE = cbpsize NEW VPSIZE = nbpsize REAL STORAGE CAPACITY = rsc MB. Explanation: When expanding the VPSIZE for an active PGFIX YES buffer pool, DB2 detects that the total storage allocated for all active PGFIX YES buffer pools will exceed 80% of the real storage capacity on this z/OS image. The ALTER BUFFERPOOL command fails and the buffer pool will continue to be active with the current VPSIZE value. The buffer pool attributes and real storage capacity are: bpnameThe buffer pool name. cbpsize The current VPSIZE for the buffer pool. nbpsize The new VPSIZE that was specified on the ALTER BUFFERPOOL command. rsc The real storage capacity of this z/OS image in units of megabytes (1 MB = 2**20 bytes). System Action: The ALTER BUFFERPOOL command fails. The buffer pool continues to be active with the current VPSIZE. System Programmer Response: Either allocate more real storage to this z/OS image, reduce the requested size of the buffer pool or use the PGFIX NO attribute. Best Regards, Sam Knutson, GEICO System z Performance and Availability mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Roland Schiradin Sent: Wednesday, November 07, 2007 1:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question Hi Max, if you're going to V8 make sure the bufferpools are pagefixed otherwise DB2 have to do it for each I/O. Roland 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
Re: Real storage usage - a quick question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Knutson, Sam) writes: You should have the PTFs for z/OS APAR OA17114 installed if you are using paged fixed buffers in DB2 V8. Not having it was one of the causes of a z/OS outage here when a DB2 DBA accidently overcommitted storage to DB2. aka application page fixed buffers ... allows applications to specify the real addresses in the channel program ... avoiding the dynamic channel program translation (creating a duplicate of the channel program passed by excp/svc0) and dynamic page fixing that otherwise has to occur on every i/o operations (however, it can eliminate pageable storage needed by the rest of system) recent post mentioning difference between EXCP and EXCPVR (vis-a-vis channel program translation) http://www.garlic.com/~lynn/2007q.html#8 GETMAIN/FREEMAIN and virtual storage backing up other recent posts discussing dynamic channel program translation (in the initial translation from MVT to OS/VS2 supporting virtual memory, there was extensive borrowing of technology from cp67 CCWTRANS, channel program translation) http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007e.html#46 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation http://www.garlic.com/~lynn/2007n.html#35 IBM obsoleting mainframe hardware http://www.garlic.com/~lynn/2007o.html#37 Each CPU usage http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation http://www.garlic.com/~lynn/2007p.html#69 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#70 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#72 A question for the Wheelers - Diagnose instruction http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' -- 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
Re: Real storage usage - a quick question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Veilleux, Jon L) writes: In z/OS 1.8 the memory management is much more conducive to large memory. They no longer use the least recently used algorithm and no longer check every page. This has made a big difference for us. Under 1.7 we had issues with large real memory sizes due to the constant checking by RSM. This is no longer the case and we have increased our memory dramatically with no performance hit. one of the things found in clock LRU-approximation that i had originally done as undergraduate in the 60s http://www.garlic.com/~lynn/subtopic.html#wsclock was that if the interval between page resets started to exceed some limit, then there was little differention benefit of the reset activity ... least recently used tends to have some implicit dependencies on amount of history ... if the duration is too long ... then it lost much of its correlation being able to differentate between pages as to future page reference pattern. however across a wide range of configurations and workloads in the 70s, clock LRU-approximation had the advantage of effectively being able to (usefully) dynamically adapt the interval. however with a lot of cp67 experimenting and also heavy use of storage reference traces and page replacement modeling ... it was possible to show that outside some useful operating range ... the use of LRU algorithms for differentiating/predicting future page reference behavior became less and less accurate. It was also possible to show that for very large memories ... that the overhead of repeatedly resetting page reference bits provided less benefit than any possible improvement in page replacement strategy. we did do some experimenting at the science center attempting to recognize the operating region/environment across where clock LRU-approximated was beneficial ... and attempt to take some secondary measures/strategies when it was outside that operating region/envrionment. one of the scenarios was that most LRU-approximation algorithms are measured against how well they performed vis-a-vis simulation that exactly implemented least-recently-used page ordering (measured in terms of total page faults for given workload and real storage size). Good approximations tended to come within 5-15 percent (total page faults) of real least-recently-used page ordering. We were able to find some page replacement variations that instead of being 5-15 percent worse/more (total page faults compared to simulated real least-recently-used page ordering), we were able to show 5-15 percent fewer total page faults. the scenario was that in some configuration/workload scenarios, LRU-approximate could effectively cycle thru every page in real storage w/o finding a candidate ... and then take the first page it started with. Besides having a lot of processing overhead, this characteristic effectively degraded to FIFO page replacement (there are operating regions for LRU where it can degenerate to FIFO page replacement at the same time taking an extrodinary amount of processor overhead). our variation tended to recognize when operating in this configuration/workload region and effectively switched to RANDOM page replacement at very low processor overhead (and modeling showed that when not able to make any other differentiation between pages to be replaced ... RANDOM replacement makes better choice than FIFO, independent of the overhead issue). In fact, the original cp67 delivered at the univ. last week jan68, ... also referenced here http://www.garlic.com/~lynn/2007r.html#74 System 360 EBCDIC vs. ASCII ... effectively implemented something that tended to operate as FIFO replacement with purely software and didn't make use of the hardware reference bits. As undergraduate, I did the kernel algorithm and software changes to implement clock LRU-approximation page replacement ... taking advantage of page replacement bits. In this scenario ... with only on the order of 120 real pageable pages ... this reduced the time spent in page replacement selection (under relatively heavy load) from approx. 10 percent of total processor to effectively unmeasureable (and at the same time drastically improvement the quality of the replacement choice). -- 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
Re: Real storage usage - a quick question
Max, that's right. I used to call that book the DIM Coffee Table book. :-) It was a nice illustration of the benefit of Data In Memory (DIM). I wish I recalled the form number. But definitely I recall one of the take home messages being DIM might well benefit you but it's highly variable whether it will save you or cost you CPU. VIO to Expanded Storage is one exploiter I remember being graphed as negative under some conditions and positive under others. (Slightly) later on I'd co-write the Storage Configuration Guidelines Redbooks. But that's another story. :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: Real storage usage - a quick question
But in z/OS 1.7 which kind of problem(s) did you have ? Max Scarpa Veilleux, Jon L [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/11/2007 15.49 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Real storage usage - a quick question In z/OS 1.8 the memory management is much more conducive to large memory. They no longer use the least recently used algorithm and no longer check every page. This has made a big difference for us. Under 1.7 we had issues with large real memory sizes due to the constant checking by RSM. This is no longer the case and we have increased our memory dramatically with no performance hit. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Max Scarpa Sent: Wednesday, November 07, 2007 9:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question Hi Martin how is it ? We're in V7, I suppose you warned about 2 Gb limit. If the case, I can assure you we're quite far from 2GB limit... Anyway you've said that there were highly variable results (in tests and in late 80s) which means that sometime things went better and sometimes things worsened (about cpu usage I presume). Is it correct ? Max Scarpa This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 -- 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
Re: Real storage usage - a quick question
Two things Caution about any case resting on saving CPU by eliminating I/O. Back in the late 1980s a series of IBM studies showed highly variable results in this area. Though the technology has (at least in part) rolled a number of times I'd still take home the same lesson. In z/OS R.8 the cost of memory management got improved because of the RSM rewrite. I'd hazard that any management cost scaled better with memory size... As that was the whole point of the rewrite. Oh, alright then, three things... :-) Caution should be applied on DB2 Virtual Storage when scaling the buffer pools up - if you're on DB2 Version 7. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: Real storage usage - a quick question
In 1.7 RSM took more CPU when we increased our real storage since it had to look at every frame for the UIC. It's a simple equation And, the increas was? - Too busy driving to stop for gas! -- 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
Re: Real storage usage - a quick question
In 1.7 RSM took more CPU when we increased our real storage since it had to look at every frame for the UIC. It's a simple equation, more frames more CPU to scan them for their UIC. Our performance area noticed that there was an increase. I believe that it showed up as uncaptured CPU or MVS usage under OMEGAMON CPU utilization. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Max Scarpa Sent: Wednesday, November 07, 2007 9:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question But in z/OS 1.7 which kind of problem(s) did you have ? Max Scarpa This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: Real storage usage - a quick question
Here is how I see the answers to the naysayers. 1. The CPU overhead incurred because of the addition of memory blocks would be minimal and you'd probably actually buy back CPU overhead because of things such as less I/O. Adding more memory blocks would allow you to retain more data in memory (DB2 buffers for example) and reduce I/O. In my mind I/O overhead would be a lot more CPU intensive than any memory overhead. 2. Yes, increasing the memory would probably cause the workload to increase slightly. There is always a tit-for-tat situation where you fix one bottleneck in a system another will pop up. However, it sounds like your limiting your CPU usage based on software costs. While I understand the budget thing you also have to decide if you're hurting your customers by doing that. Is your DB2 processing so slow because of the lack of memory that your customers are complaining? 3. So you're paying for 5GB of storage that you aren't using. Is that really a good use of budget resources? Sent: Wednesday, November 07, 2007 4:00 AM by Max Scarpa 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
Re: Real storage usage - a quick question
Hi Max, if you're going to V8 make sure the bufferpools are pagefixed otherwise DB2 have to do it for each I/O. Roland Hi Martin how is it ? We're in V7, I suppose you warned about 2 Gb limit. If the case, I can assure you we're quite far from 2GB limit... Anyway you've said that there were highly variable results (in tests and in late 80s) which means that sometime things went better and sometimes things worsened (about cpu usage I presume). Is it correct ? -- 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
Re: Real storage usage - a quick question
Hi Tom and thank you a lot for your reply. WLC is a thing I cannot influence as it's managers' decision. But not using storage you bought and could be very useful seems to me a waste of money without a valid reason. Using it could increase performance and save some CPU to be used for customers. Sometime our capping is so long that all jobs are delayed a lot, expecially batch. Thank you again and best regards Max Scarpa Kelman, Tom [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/11/2007 14.51 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Real storage usage - a quick question Here is how I see the answers to the naysayers. 1. The CPU overhead incurred because of the addition of memory blocks would be minimal and you'd probably actually buy back CPU overhead because of things such as less I/O. Adding more memory blocks would allow you to retain more data in memory (DB2 buffers for example) and reduce I/O. In my mind I/O overhead would be a lot more CPU intensive than any memory overhead. 2. Yes, increasing the memory would probably cause the workload to increase slightly. There is always a tit-for-tat situation where you fix one bottleneck in a system another will pop up. However, it sounds like your limiting your CPU usage based on software costs. While I understand the budget thing you also have to decide if you're hurting your customers by doing that. Is your DB2 processing so slow because of the lack of memory that your customers are complaining? 3. So you're paying for 5GB of storage that you aren't using. Is that really a good use of budget resources? Sent: Wednesday, November 07, 2007 4:00 AM by Max Scarpa 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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 -- 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
Re: Real storage usage - a quick question
In z/OS 1.8 the memory management is much more conducive to large memory. They no longer use the least recently used algorithm and no longer check every page. This has made a big difference for us. Under 1.7 we had issues with large real memory sizes due to the constant checking by RSM. This is no longer the case and we have increased our memory dramatically with no performance hit. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Max Scarpa Sent: Wednesday, November 07, 2007 9:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question Hi Martin how is it ? We're in V7, I suppose you warned about 2 Gb limit. If the case, I can assure you we're quite far from 2GB limit... Anyway you've said that there were highly variable results (in tests and in late 80s) which means that sometime things went better and sometimes things worsened (about cpu usage I presume). Is it correct ? Max Scarpa This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: Real storage usage - a quick question
Hi Martin how is it ? We're in V7, I suppose you warned about 2 Gb limit. If the case, I can assure you we're quite far from 2GB limit... Anyway you've said that there were highly variable results (in tests and in late 80s) which means that sometime things went better and sometimes things worsened (about cpu usage I presume). Is it correct ? Max Scarpa Martin Packer [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 07/11/2007 15.23 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Real storage usage - a quick question Two things Caution about any case resting on saving CPU by eliminating I/O. Back in the late 1980s a series of IBM studies showed highly variable results in this area. Though the technology has (at least in part) rolled a number of times I'd still take home the same lesson. In z/OS R.8 the cost of memory management got improved because of the RSM rewrite. I'd hazard that any management cost scaled better with memory size... As that was the whole point of the rewrite. Oh, alright then, three things... :-) Caution should be applied on DB2 Virtual Storage when scaling the buffer pools up - if you're on DB2 Version 7. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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 -- 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
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 -- 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
Re: Real storage usage - a quick question
I don't have specific numbers, but it was noticable. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, November 07, 2007 10:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question In 1.7 RSM took more CPU when we increased our real storage since it had to look at every frame for the UIC. It's a simple equation And, the increas was? - Too busy driving to stop for gas! -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: Real storage usage - a quick question
- Increasing real storage increases cpu overhead to managed more memory. blocks in a cpu-constrained machine. It's cheaper to manage storage than it is to page. I've always found the CPU overhead vs memory argument bogus. - Too busy driving to stop for gas! -- 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
Re: Real storage usage - a quick question
On Wed, 7 Nov 2007 10:22:30 -0500, Veilleux, Jon L [EMAIL PROTECTED] wrote: In 1.7 RSM took more CPU when we increased our real storage since it had to look at every frame for the UIC. It's a simple equation, more frames more CPU to scan them for their UIC. Our performance area noticed that there was an increase. I believe that it showed up as uncaptured CPU or MVS usage under OMEGAMON CPU utilization. Exactly. So if you are running below z/OS 1.8 and aren't paging, don't just add 25G of storage because you have it laying around doing nothing since you upgraded your processor and added all the cheap memory. We've discussed this before. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
