Re[2]: cpu usage in 7.0

From: Jeff Roberson <jroberson_at_chesapeake.net>
Date: Sun, 24 Feb 2008 22:41:37 -1000 (HST)
On Mon, 25 Feb 2008, Daniel Gerzo wrote:

> Hello Jeff,
>
> Sunday, February 24, 2008, 11:47:39 PM, you wrote:
>
>>> So how does a multithreaded process get 458% CPU on a quad-core machine? :)
>>> (Really, I want to know; I thought thread CPU accounting was fixed in 7.x.
>>> Unless I'm mistaken, 4 CPU-intensive threads in a single process should
>>> account as 4 CPU-intensive single-thread processes; i.e. each could only take
>>> up to 100% of a core/CPU, accounting for NCPU*100% total).
>>>
>>>
>
>> It is possible for the sum of all threads in the system to exceed 100%
>> cpu.  This is because the decay function is not precise.  15% over is a
>> bit more than I would expect but I suppose it's possible.  We also inhert
>> pcpu information from the parent on fork/thread creation so the child
>> isn't created with a priority as if it had been idle.  So for a moment the
>> utilization is duplicated.
>
> I have a box running mysqld, which sometimes exeeds 130%, what about
> this? ;)
>
> Also the mysqld is alsmost all the time in the "ucond" state, what
> does it mean? I've been told that it is probably waiting for I/O, but
> then, I have another box which is currently completely idle, but
> running mysql shows that it is "ucond" as well.

You should switch top to display threads.  'H' is the key to do it. 
Otherwise you only get the wait channel for one of the threads.  Others 
may be busy doing things.

'ucond' means the thread is waiting on a userland condition variable. 
This is a type of synchronization point in userland accessed via the 
pthread_cond_*(3) api.  It may indicate a thread that is waiting for work 
but other threads may be busy.

Do you only have one CPU?  If you're seeing 130% on a single cpu system we 
may need to take some steps to improve the reporting.


>
> -- 
> Best regards,
> Daniel                            mailto:danger_at_FreeBSD.org
>
Received on Mon Feb 25 2008 - 07:40:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:28 UTC