|< Day Day Up >|| |
Processor capacity planning should begin by analyzing the requirements of the workload. Ideally, performance would be gathered for several weeks or months to understand when the workload peaks and how much resource is required during those peaks. The data that can be collected depends on what agents are installed. Using the SNMP interface provided by ESALPS, there are two types of data that can be acquired: processor data and process data.
Figure 11-3 contains an ESAMON display showing five minutes of processor data provided by a Linux server running the NETSNMP implementation.
Figure 11-3: ESAUCD4 Linux processor utilization example
Figure 11-4 shows the process data for one of those one-minute intervals.
Figure 11-4: ESAHST1 Linux process utilization example
One other perspective, useful for capacity planning, is the ability to look at all the processes as a group. Looking at a sorted list of several hundred processes provides only a quick idea of which processes are using CPU. The ESAHSTA report (in this case, from ESAMAP) groups all of the processes of the same name and reports as a group. Record how much of the resource is taken by java (or update or server), then you can characterize your workload.
Figure 11-5: ESAHSTA Linux application example
Processor planning can sometimes be done by guessing at the number of users that will be supported and the amount of resource used by those users. But since every company (maybe every department) will have a different work profile, guessing is just guessing. For installations that run a Domino workload already, the best method would be to capture the performance data for a month to determine existing processor requirements.
If the data from the above ESAHSTA report was captured for a month from one platform, it is then possible to estimate CPU requirements on another platform. For example, if the total requirement is an average of 10% of a 1 GHz Intel-based processor, you could estimate an average requirement of about 25 MIPS requirement on a z800 or z900. This calculation is an estimate based on "Barton's Number" of 4, which calculates the MHz requirement, in this case 100 MHz, and divides by 4 to get an estimate of MIPs requirement.
One of the functions of ESALPS is to collect data from many other platforms. Using either NETSNMP or another SNMP implementation, ESALPS will collect the performance data and store it into the Performance DataBase. This data is then used to project future capacity requirements.
When running large numbers of servers, there is a cost that should be recognized. An idle server seems to require some amount of storage and processor resources. Factors include the number of virtual processors per virtual server, and the configuration of the network. The cost of this for us seemed to be about 2 to 3% of a z800 processor. Thus, one hundred idle servers has the cost of at least two z800 engines. Some consolidation will help reduce the infrastructure and management cost of this environment.
Although we did not trace this, possible causes for this CPU usage include:
We were running with the Linux timer enabled and at the default setting of 100 times per second. This keeps Linux active and ineligible to page. We recommend that you apply a kernel timer patch (see 10.2 on page 264) to reduce the number of timer pops.
Also examine APAR VM63282 to see if your situation calls for it. It is discussed in 7.4, "QDIO and the dispatch queue" of Linux on IBM eServer zSeries and S/390: Performance Measurement and Tuning, SG24-6926.
Authors of the SG24-6926 redbook believe that a shared kernel is advantageous when running Linux under z/VM. They explain how to do this in 4.2, "Exploiting the shared kernel" of that redbook.
Domino servers with no workload actually consume some amount of CPU through numerous processes and threads performing sleep()/usleep() calls, only to wake up find out there is no work to do and go back into sleep()/usleep().
|< Day Day Up >|| |