Installations that expect to use "top" or other agents running in Linux under z/VM to determine capacity requirements or current CPU useage should know that the data is VERY wrong. All agents under Linux get their data from exactly the same /proc table, and thus all agents have exactly the same problem. The means of CPU accounting for Linux is to wake up 100 times per second and allocate the 10ms of CPU based on which process happens to be using the CPU at that time. But in a virtual environment, Linux doesn't always get dispatched at exactly the 10ms mark, and doesn't have the ability to recognize this fact. When the VM system is very busy, Linux is not dispatched consistently, and does accounting for processor a bit randomly.
This short presentation shows a very typical case using real data, and shows how Velocity Software has the technology to provide signficantly better data that can be used for capacity planning and performance analysis. This example shows the process data as being reported at 10 times the actual value. Cases much worse than this are common. Imagine if you have one process in a loop, and all your z/VM processors are 100% utilized, with 20 linux servers. In this case, every server you use "top" to measure will show it is using 100%. Which server should you eliminate to solve the problem?
The solutions to this problem are to
1) use the VM
monitor to determine which Linux server is using the
CPU, and then use "top" to determine the process using
the CPU. This is difficult, time consuming, and does not
lend itself to capacity planning or timely problem resolution.
2) Fix Linux process accounting to use the CPU timer
instead of the TOD timer, will not happen in near future.
3) Use Velocity Software's ESALPS technology to provide
accurate data...
1) Performance Instrumentation Issues
2) Performance Case Study
3) Performance Case Study
4) Performance Case Study
How ESALPS provides accurate data.
5) Prorate Linux data
6) Prorate Linux data
7) Prorate Linux data
Why ESALPS can fix the data?
8) Prorate Linux data
9) Prorate Linux data
10) Prorate Linux data
Author: Barton Robinson
Mail us
