Link to home
Start Free TrialLog in
Avatar of Chaitu
Chaitu

asked on

Application Load on CPU

Hi,

In my AS400 system, there are around 20 applications which runs and occupies around 90% of CPU.

I would like to Know the process to find how much a particular application is putting load on that CPU.

Example, app1 takes 20% of CPU out of 20 applications.

Can somebody shed some lights on how to find this.

Thanks
Chaitu
Avatar of Anthony Janson
Anthony Janson
Flag of Hungary image

Can you let us know first which Operating System you are running? The AS400 is capable of multiple OS products. Knowing which OS you are using helps us in a more detailed answer.
ASKER CERTIFIED SOLUTION
Avatar of John
John
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Chaitu
Chaitu

ASKER

Thanks for your replies.

OS is on V5R3.
I got no experience with that. Did the comment of Gary help?
OS/400 can work on many things at once and limit any one application or session to its share of CPU, so it can handle a large load with no issue or significant degradation of performance.
Avatar of Chaitu

ASKER

Hi John,

Actually there are 20 applications which runs on this V5R3 system which has severe performance issues as there are so many interfaces interacts with these applications.

We are trying to move 2-3 applications out of this system and put it in a brand new system to reduce the load on the current system.

Now how do we calculate how much load these 2 applications would reduce on overall CPU % if  I move it from the current system.

Other way of asking the same question is, how much load these 2 apps are putting now on the current CPU%. If it is 90% overall then is it 10% or 20%. these 2 apps are consuming from that 90%. How do we calculate this.

Thanks
Chaitu
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The AS/400 can handle large loads at high CPU % in a very stable fashion as noted.
Actually, reported CPU percentages often go above "100%". It depends one how many processors are used (and/or fractional processors) and exactly where the number is being seen.

It's not clear if there is any problem here. 90% CPU isn't as much a problem as it possibly ought to be a goal. It can indicate that full usage is being received from the hardware. Ideally, a system would regularly and consistently run at 90% or higher. That would only be a "problem" if there are other troublesome symptoms such as jobs running far too long or user response times being too long.

If a system runs at 90% and there are no (or very few) performance complaints, it indicates a well-tuned system for its workload and capacity.

So, what is the actual problem?

Finding performance issues on a system running numerous apps, as well as handling the networking services and more, can be difficult. In the past 30 years, I doubt if I've seen more than three or four "well tuned" systems.
This is a very complicated topic that requires workload estimation.  The problem is, that existing applications that are fighting with each other for resources will cause the system to take measures to try to work out a compromise.  Let me give you an example:

First of all, most systems aren't CPU bound - they are I/O bound.  When you start talking about moving jobs around to different systems, you sometimes also need to move the supporting data.  These data moves can also have an impact on performance.  There are three basic metrics we typically look at when evaluating the performance of a system, and of individual jobs in a system:

1) CPU utilization
2) Memory utilization
3) I/O utilization  (generally disk I/O and sometimes network I/O, depending on the job).

IBM provides a tool called the Workload Estimator (WLE) that we typically use to help make these kinds of system sizing decisions:

https://www-947.ibm.com/systems/support/tools/estimator/index.html

This is not a trivial chore, and I recommend you engage the assistance of an IBM Business Partner or if you are a direct IBM customer, then engage IBM Support directly.

- Gary
Systems are initially shipped with very "generic" tuning. IBM has no way to know how each customer's apps will do their work, so systems only have a basic set of subsystems, memory pools, routing entries and all other work management components. All of them are essentially set to 'Medium'; most stuff is done okay and little gets done truly well.

To get best usage, customers always should start a new system by creating two, three or more new subsystems, changing memory pool assignment for all subsystems (including, and perhaps especially, the default subsystems), setting routing entries for appropriate subsystems (including, and perhaps especially, the default routing entries) and other steps. Of course, almost no customers ever do. Most assume that IBM set it up, so don't mess with it. (IBM is fine with selling more memory, more processors, higher tiers... or selling performance services. And documentation does indeed cover enough for do-it-yourself.)

Initial goal would be to get nearly everything out of *BASE and into memory pools that isolate workloads appropriately. I usually even separate IBM TCP/IP server and host server jobs into separate memory pools. My batch jobs are isolated into another memory pool, and there may be others. By getting as much stuff out of *BASE as is reasonably possible, the purpose of *BASE can be implemented again. And by getting things separated, it starts to become much more possible to see where resource conflicts are happening.

When everything runs in *BASE, system performance adjustments practically have nothing to "adjust". Running with adjustments enabled does little more than use up resources without useful results. Also, having all server jobs and batch jobs and comm jobs (and whatever) all running in *BASE, it's almost impossible to see which jobs are stomping on which other jobs.

Until individual work units can be observed, there's little chance of finding the real problems without quite a bit of effort. When work management is appropriately configured, it takes hardly more than a couple quick looks at subsystem statistics to see right where to look.