<div dir="ltr">Hello Michael, <div><br></div><div>Thanks for the reply and I have used top plus the other variants in the past. The issue I should have explained clearly in the first e-mail is finding the root cause for high CPU load and if it&#39;s really a valid measurement of system performance. At my job, we have a majority of alerts that are focused on application metrics (latency and api calls), system level (free memory, CPU load, disk space), and finally synthetic checks (user simulation). </div><div><br></div><div>We will semi-frequently find CPU load spikes on the host, but nothing else is alerting. Taking a look at the load trending, through sar, it&#39;s jumping from 1~4 to 20~30 within minutes, holds this for about an hour, then drops back to the previous levels. While I check the various metrics from our monitoring, I do not see anything that is obvious to the rise.  </div><div><br></div><div>My knowledge within the cpu calls and how the system works is very limited, wonder if there is a good reference I should look for as a starting guide?</div><div><br></div><div>Thanks,</div><div>Robert</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Mar 20, 2016 at 1:05 PM Michael Eager &lt;<a href="mailto:eager@eagercon.com" target="_blank">eager@eagercon.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/18/2016 04:48 PM, Robert Freiberger wrote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; I still consider myself pretty new to the world of UNIX/Linux, and find that when I investigate an<br>
&gt; issue with CPU load, it&#39;s very difficult to trace the issues. Unlike performance problems with<br>
&gt; network or NFS, where I can test latency with simple commands, load appears to be much harder to<br>
&gt; test in real time.<br>
<br>
Are you familiar with &quot;top&quot; or the graphical variant &quot;htop&quot;?<br>
Both will give a real-time display of current system load<br>
and activity.  KDE and Gnome have graphical monitors for CPU<br>
utilization and other activity, such as memory or network use.<br>
<br>
Tecmint.com has an article about 20 different tools which can<br>
be used to monitor Linux performance.<br>
<br>
&gt; Is there any recommendations how to really investigate this and how effective is CPU load to a<br>
&gt; systems health?<br>
<br>
It&#39;s not clear what you are investigating.  Do you have a problem<br>
or are you simply curious?<br>
<br>
High or low CPU utilization is not a cause or solution to poor<br>
performance.  If you are running at 80% CPU, that means that the<br>
CPU is idle 20% of the time.  Any program which is ready to run<br>
while the CPU is idle will be dispatched.  On most systems, reducing<br>
CPU load to 60% will not make programs run faster, it will just increase<br>
your idle time.  (This may not be true if you are running CPU-intensive<br>
programs like transcoders or video editors.)<br>
<br>
More interesting is load averages displayed by top/htop and<br>
uptime.  This is the average number of runnable processes which<br>
are waiting at any particular time.  High load averages result<br>
in poor responsiveness.<br>
<br>
--<br>
Michael Eager    <a href="mailto:eager@eagercon.com" target="_blank">eager@eagercon.com</a><br>
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077<br>
</blockquote></div></div>