On Thu, Sep 23, 2010 at 2:14 AM, O'Brien, Dennis L <dennis.l.o'[email protected]> wrote: > I heard from a couple of performance people at SHARE that we should have 20% > to 25% of the total storage in an LPAR configured as expanded storage. > Naturally, that's a guideline and the proper amount varies by workload. What > should I look at to determine if we have enough expanded storage? We use > Velocity's ESALPS suite. The systems that I'm most concerned about have a > Linux guest workload. One of them is all WAS, and the other is a mix of WAS, > Oracle, and some other things.
You're most welcome to send us data for review. We do that all the time for customers. Let's work off-list on that; would be a bit unfair to those on the list who don't have our products. We can tell from the data when you don't have enough expanded storage. But you need enough performance history to know when your peak requirement is. Too much expanded storage is rarely a problem, to little is bad. Expanded storage creates another layer in z/VM storage management. Typical Linux workloads effectively bypass some of the first layers, so you really want that last bastion before going to DASD. The challenge in tuning many of these workloads is that the middleware itself introduces a layer of memory management that does not interface with the hypervisor. The JVM grabs memory from Linux and treats it like real, Linux gets memory from z/VM and thinks it is real. And z/VM is trying to decide who should use the real memory and when. With no further info from the application, z/VM uses the "what would happen when I take this away" approach. When the page is still in expanded storage, that works pretty well. When it went to DASD, it gets really slow. So I can tell from performance data that z/VM has not enough expanded storage. But since the tuning itself changes the workload, it is very hard to predict how much you need (requires Crystal Ball Technology that we have not yet announced). Since workloads change over time, and too much expanded storage rarely hurts, I tend to stay on the safe side. > I've heard that WAS isn't the best choice for System z, but that's not the > focus of my concern. We have the workload that we have, and I just want to > make it run as well as it can. > Exactly my view! It's no secret you need more CPU and memory when you replace a well-tuned CICS application by SAP with all the bells and whistles people asked for the past 20 years. If you can even compare the function offered. But we also get orders of magnitude more resources in our mainframes now. Other aspects of the business justify such a move. Can make a lot of sense. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
