From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:40:06 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF7616A405; Mon, 25 Feb 2008 08:40:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id F287C13C457; Mon, 25 Feb 2008 08:40:05 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1P8e3eV071926; Mon, 25 Feb 2008 03:40:04 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 24 Feb 2008 22:41:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Daniel Gerzo In-Reply-To: <1172441424.20080225092945@rulez.sk> Message-ID: <20080224223903.Q920@desktop> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> <20080224124342.E920@desktop> <1172441424.20080225092945@rulez.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Ivan Voras Subject: Re[2]: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 08:40:06 -0000 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@FreeBSD.org >