CPUs not sharing an equal proportion of the total load

[Yogeeraj_1]

Dear experts!

Have been observing an improper balance between the proportion of load shared by my 2 CPUs...

Have also got an alert "HP-UX PATCH NOTIFY: Patch PHNE_31247 Has Warnings" from HP recently saying that:
==============================================
Hewlett-Packard has issued a new warning for the following patch:

PHNE_31247 : s700_800 11.11 cumulative ARPA Transport patch

"Warning: 05/04/13 - This Critical Warning has been issued by HP.

- PHNE_30656 introduced behavior that can cause the performance
of network-intensive applications to decrease due to the
processing workload becoming unbalanced between CPUs.
The CPU utilization could significantly increase on CPUs
servicing LAN card interrupts in comparison to the other CPUs
following the installation of PHNE_30656. This can lead to
lower network performance on systems that have a high number
of CPUs, few network cards with high network traffic, and long
TCP connection lifetimes.
- This same behavior is exhibited with superseding patches
PHNE_31247 and PHNE_32042.
....
"

When checking my patches i see:
==================================
SLX2:>swlist -l patch |grep ARPA
# PHNE_31247 1.0 cumulative ARPA Transport
patch
SLX2:>


Attached a snapshot from the TOP command.

Comments or recommendations from those who are Knowledgeable of this, would be most appreciated.

kind regards
yogeeraj

[harry d brown jr]

Are those processes that are at the top of top communicating to something over the network?

Fire up glance and check to see where each one of those processes are consuming the most resources.

If the answer is they do a lot of network traffic, then HP recommends you uninstall these patches: PHNE_30656, PHNE_31247, PHNE_32042

live free or die
harry d brown jr

[Bill Hassell]

Nothing improper here at all. It is very difficult to "spread the load" evenly across the processors. The reason is that multiple processors cannot run portions of the same job. When any process runs, it starts executing each instruction in order, making calculations, testing values, branching to other parts of the program. It makes no sense to run instructions in other parts of the program at the same time. The processors are equally loaded with processes but each process is not presenting the same load, thus the difference in loading. Your different processes are simply doing different tasks, probably reading/writing files while other processes are computing.

If you want to see each processor equally loaded, do this:

while :;do :;done &
while :;do :;done &

Since each line represents 100% CPU load, running it twice will load each processor and thus you'll see processor=100% and overall system load=100%. This do-nothing loop consumes 100% CPU and no I/O so it represents a steady load on the CPU.

[Emil Velez]

As mentioned before it is hard to totally equal the CPU utilization on a system.. What happens is the OS checks every second if there is a 20% or more deviation between the cpu utilization of the most and the least CPU. Then it moves a thread over from the busiest to the least busiest. As you can see from this algorithym it is not perfect but good enough. A lot really depends on whether the thread can be moved. Alot can happen in a second. Many processes can goto sleep, be created and die so the whole world changes in a second. Many drivers and some code can only run on a specific processor or they cannot be moved once they start, so they cannot be moved. If you look at a system with 75% and 56% thats not too badly balanced.

I hope this makes sense and helps.

[Steven E. Protter]

Over the years I've seen on multi processor machines imbalances in loads, especially when use factors were on the light side.

Things tended to even out when machine use got heavier.

Based on the information you submitted I would not say you have a problem right now.

If you have one of the patches thats been pulled, I would like that patch out of production, but unless you exhibit the exact symptoms of the warning, I would not be in a hurry.

SEP