Re: VM Newbie Question
I agree. The poster didn't really say what their plans weremostly that he was a newbie. In my shop, we have Oracle 10g running in test. Applications wanted an Oracle machine bigger then we currently have in production (4 GB). I gave them a couple images of Oracle running in 400 MBs (about the smallest I could make it and still run OEM). They have been happy with the performance. Now, production may be a different matter. But we will go into production with a 400 MB machine and I'll give it more memory (and adjust the SGA) when I see the performance problems. We will be scaling up slowly. Perhaps a dozen users will be moved to the mainframe on the first go around. Tom Duerbusch THD Consulting >>> "Romanowski, John (OFT)" <[EMAIL PROTECTED]> 10/19/2007 12:46 PM >>> On the other hand, if his site plans to eventually run multiple oracle guests with little/zero down time to add LPAR memory as more guests are added , then sizing the LPAR memory now to avoid LPAR outages later is prudent. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Friday, October 19, 2007 1:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM Newbie Question The first question that pops into my mind is, why do you think you need that much real memory (central and expanded)? Is it that you have 16 GB real and nothing else to do with it? Is it that you have a current Oracle box that needs more and more memory? The performance characteristics of mainframes are quite a bit different then the other platforms. Your box, should have Ficon/FCP channels. The promos on our IBM DS6800 dasd subsystem, states that if it is properly configured (ours is not), it can do 300,000 I/Os per second. What do your current platforms have? What I'm getting at is, take Intel for example. Very cheap memory. Very cheap MIPS. Poor context switching. Poor I/O rates (unless you spend mainframe type dollars to beef up the I/O subsystem). So you throw lots of cheap memory on the box to knock down the I/O rates. (cheaper than beefing up the I/O subsystem). On the mainframe, we have the I/O subsystem (basically comes standard...well for the price we pay for the box). In my book, you trade memory for a higher I/O rate and you still get great performance. True, you may still need the memory. But just because the Intel side needed the memory, doesn't mean the mainframe side needs it. True, I would keep memory at 16 GB for a POC. But if I had the time, I would scale the memory back, perhaps a GB at a time, until I see performance start to suffer. In other words, take advantage of the resources available on the new-to-you platform. All the rules of thumb that you have seen for Oracle, really need to be rethought in the shared environment of the mainframe. If you treat the mainframe like a PC, it will be a very expensive project. Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Motion A cat will move in a straight line, unless there is a really good reason to change direction. >>> Mark Jacobs <[EMAIL PROTECTED]> 10/18/2007 7:21 AM >>> What is a good ratio of Central to Expanded storage to support an zLinux Oracle workload under zVM 5.3? The LPAR has 16GB assigned and our initial storage split is 12 Central, 4 Expanded. The workloads haven't been moved to this environment yet so we have no tuning numbers available. -- Mark Jacobs Time Customer Service Tampa, FL -- A desire not to butt into other people's business is at least eighty percent of all human wisdom...and the other twenty percent isn't very important. Jubal Harshaw (Stranger in a Strange Land)
Re: VM Newbie Question
On the other hand, if his site plans to eventually run multiple oracle guests with little/zero down time to add LPAR memory as more guests are added , then sizing the LPAR memory now to avoid LPAR outages later is prudent. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Friday, October 19, 2007 1:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM Newbie Question The first question that pops into my mind is, why do you think you need that much real memory (central and expanded)? Is it that you have 16 GB real and nothing else to do with it? Is it that you have a current Oracle box that needs more and more memory? The performance characteristics of mainframes are quite a bit different then the other platforms. Your box, should have Ficon/FCP channels. The promos on our IBM DS6800 dasd subsystem, states that if it is properly configured (ours is not), it can do 300,000 I/Os per second. What do your current platforms have? What I'm getting at is, take Intel for example. Very cheap memory. Very cheap MIPS. Poor context switching. Poor I/O rates (unless you spend mainframe type dollars to beef up the I/O subsystem). So you throw lots of cheap memory on the box to knock down the I/O rates. (cheaper than beefing up the I/O subsystem). On the mainframe, we have the I/O subsystem (basically comes standard...well for the price we pay for the box). In my book, you trade memory for a higher I/O rate and you still get great performance. True, you may still need the memory. But just because the Intel side needed the memory, doesn't mean the mainframe side needs it. True, I would keep memory at 16 GB for a POC. But if I had the time, I would scale the memory back, perhaps a GB at a time, until I see performance start to suffer. In other words, take advantage of the resources available on the new-to-you platform. All the rules of thumb that you have seen for Oracle, really need to be rethought in the shared environment of the mainframe. If you treat the mainframe like a PC, it will be a very expensive project. Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Motion A cat will move in a straight line, unless there is a really good reason to change direction. >>> Mark Jacobs <[EMAIL PROTECTED]> 10/18/2007 7:21 AM >>> What is a good ratio of Central to Expanded storage to support an zLinux Oracle workload under zVM 5.3? The LPAR has 16GB assigned and our initial storage split is 12 Central, 4 Expanded. The workloads haven't been moved to this environment yet so we have no tuning numbers available. -- Mark Jacobs Time Customer Service Tampa, FL -- A desire not to butt into other people's business is at least eighty percent of all human wisdom...and the other twenty percent isn't very important. Jubal Harshaw (Stranger in a Strange Land)
Re: VM Newbie Question
The first question that pops into my mind is, why do you think you need that much real memory (central and expanded)? Is it that you have 16 GB real and nothing else to do with it? Is it that you have a current Oracle box that needs more and more memory? The performance characteristics of mainframes are quite a bit different then the other platforms. Your box, should have Ficon/FCP channels. The promos on our IBM DS6800 dasd subsystem, states that if it is properly configured (ours is not), it can do 300,000 I/Os per second. What do your current platforms have? What I'm getting at is, take Intel for example. Very cheap memory. Very cheap MIPS. Poor context switching. Poor I/O rates (unless you spend mainframe type dollars to beef up the I/O subsystem). So you throw lots of cheap memory on the box to knock down the I/O rates. (cheaper than beefing up the I/O subsystem). On the mainframe, we have the I/O subsystem (basically comes standard...well for the price we pay for the box). In my book, you trade memory for a higher I/O rate and you still get great performance. True, you may still need the memory. But just because the Intel side needed the memory, doesn't mean the mainframe side needs it. True, I would keep memory at 16 GB for a POC. But if I had the time, I would scale the memory back, perhaps a GB at a time, until I see performance start to suffer. In other words, take advantage of the resources available on the new-to-you platform. All the rules of thumb that you have seen for Oracle, really need to be rethought in the shared environment of the mainframe. If you treat the mainframe like a PC, it will be a very expensive project. Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Motion A cat will move in a straight line, unless there is a really good reason to change direction. >>> Mark Jacobs <[EMAIL PROTECTED]> 10/18/2007 7:21 AM >>> What is a good ratio of Central to Expanded storage to support an zLinux Oracle workload under zVM 5.3? The LPAR has 16GB assigned and our initial storage split is 12 Central, 4 Expanded. The workloads haven't been moved to this environment yet so we have no tuning numbers available. -- Mark Jacobs Time Customer Service Tampa, FL -- A desire not to butt into other people's business is at least eighty percent of all human wisdom...and the other twenty percent isn't very important. Jubal Harshaw (Stranger in a Strange Land)
Re: VM Newbie Question
>>> On Thu, Oct 18, 2007 at 8:21 AM, in message <[EMAIL PROTECTED]>, Mark Jacobs <[EMAIL PROTECTED]> wrote: > What is a good ratio of Central to Expanded storage to support an zLinux > Oracle workload under zVM 5.3? > > The LPAR has 16GB assigned and our initial storage split is 12 Central, > 4 Expanded. The workloads haven't been moved to this environment yet so > we have no tuning numbers available. All the recommendations I've seen have topped out at 4GB for XSTOR. So, as a first SWAG, I think you're in decent shape. What are you running for a performance monitor? That will probably be a critical factor once you start moving the work. Mark Post