Beware too with the SET SHARE of MP virtual machines. Simply said: CP does *not* schedule/dispatch virtual machines, it dispatches/schedules virtual processors, and each virtual processor gets a SHARE assigned. So, for a virtual machine with SET SHARE REL 100 and two processors, each virtual processor gets a SHARE REL 50 assigned. Such a REL 50 virtual processor looks then less important amongst the competing REL 100 virtual processors. This has been discussed here more extensively in the past. Search the archives for SHARE and Processor and author address contains Buelens
2008/2/14, Rob van der Heij <[EMAIL PROTECTED]>: > On Thu, Feb 14, 2008 at 1:54 AM, Paul Vincent > <[EMAIL PROTECTED]> wrote: > > > I'm new to z/VM and have a question. Should I define virtual processors > to > > z/VM service ids/guests (TCPIP, Linux guests...) with the 'MACHINE ESA ## > & > > CPU #' control statements in the USER DIRECT file? Is there a performance > > benefit/cost, if I have more than 1 IFL, to define virtual processors > equal > > to the number of IFLs? Or will a single virtual processor perform just > > fine. > > > To avoid possible misunderstanding: there is no fixed relation between > virtual and real CPUs. You don't *have* to define multiple virtual > CPUs to use multiple real CPUs. z/VM will nicely spread the work of > multiple virtual machines over the real CPUs. Those who say you *must* > define virtual CPUs the same as real CPUs are from a different world > than most of us. In many cases things work better with only one > virtual CPU. > > For CMS applications there is no benefit because additional virtual > CPU's will not be used. That's easy. With Linux, the answer is much > more complicated. That's one of the reasons progress on my "Virtual-MP > is Evil" paper is less than I would like it. There is a lot of detail > in this that you probably don't care about yet. Let me try to be very > brief... > > The question is rather unique for Linux on z/VM. In the world of > dedicated servers you normally don't have the option to only add a CPU > but not change anything else. Most installations use "standard > configurations" - more like rental car classes (it can not only seat > more people, but also holds the bags of more people and has a bigger > engine, etc). So when you get a 2-way server, you also get more > memory, maybe different disks, etc. Without proper instrumentation you > may not be able to tell which of the items got you improved response > times, you only know the class D server was faster than the class A > server. > But with Linux on z/VM you *can* change a single configuration > parameter (in fact, many of us were trained to change only one thing > at a time). This flexibility only makes sense when you measure and > tune. Otherwise you might be better off doing classes (sometimes > combined with "political sizing" as well). > > Cost of defining multiple virtual CPUs for Linux comes in two areas: > * increased CPU usage inside Linux because of overhead related to > locking, scheduling, etc > * increased cost for z/VM to provide the virtual machine with the net > CPU capacity it consumes > When you have more than enough hardware (CPU as well as storage) and > you only have one virtual machine that you care about (a lab > environment, for example) you may be able to afford the cost. When you > have many Linux virtual machines running, efficiency of the operation > becomes an issue. > > Linux can benefit from multiple virtual CPUs in some situations, but > only if both of these apply: > * if the application is able to use multiple CPUs during peak times > (through threads for example) Running multiple different aplications > on the same Linux server fits this, but it may not be the best way to > run them. > * if at peak times z/VM is likely to have enough CP capacity available > to run all virtual CPUs at the same time (only in a lab environment > with no real competition this is the same as the number of real CPUs > defined) > > When there is a benefit for your server, the hard question is how that > relates to the increased cost of running it. When you have low > utilized servers, multiple virtual CPUs are normally not justified > (what Mark referred to: even when configured properly you will find a > low utilized server with multiple virtual CPUs more "sluggish" than a > virtual-UP server. But when your application is using a fair amount of > resources during longer periods, it may be justified to accept the > increased cost to have it complete the workload quicker. > > Did I mention instrumentation and performance monitor? I should have - > that is what helps to understand your workload and how system > resources are being utilized. > > Rob > > -- > Rob van der Heij > Velocity Software, Inc > http://velocitysoftware.com/ > -- Kris Buelens, IBM Belgium, VM customer support
