From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 25 10:30:03 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63587106566B for ; Sun, 25 Jan 2009 10:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50C2B8FC14 for ; Sun, 25 Jan 2009 10:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0PAU3PY077824 for ; Sun, 25 Jan 2009 10:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0PAU3Jb077819; Sun, 25 Jan 2009 10:30:03 GMT (envelope-from gnats) Date: Sun, 25 Jan 2009 10:30:03 GMT Message-Id: <200901251030.n0PAU3Jb077819@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Mikolaj Golub Cc: Subject: Re: misc/130954: can not obtain which process take all CPU time X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mikolaj Golub List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 10:30:03 -0000 The following reply was made to PR bin/130954; it has been noted by GNATS. From: Mikolaj Golub To: Eugen Konkov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/130954: can not obtain which process take all CPU time Date: Sun, 25 Jan 2009 01:56:57 -0800 (PST) Can you specify how you run gzip? Do you run gzip on one large file or rather there are many gzip processes spawned one by one? I can't reproduce this on 7.1-RELEASE-p1 amd64 and 7.0-STABLE (Jun18 2008) i386 (I don't have 7.1-RELEASE i386 at present). I have been observing the same on my loaded nagios host (6.3 i386), but I interpret it in this way. There are many short living processes spawned every second here, which are born and die faster then top update its statistics, so the top can't show them. You can check if it is your case, running something like this in the problem period: while sleep 1; do sysctl kern.lastpid; done If last pid grows fast you have the case I have described above. If it is not your case and you are observing the problem running one gzip process on large file, can you check if you see the same running something like this: gzip -c - < /dev/random > /dev/null If you don't, add file system IO: gzip -c - < /dev/random > test gzip -c - < test > /dev/null gzip -c - < test > test1 Also, it would be nice to check if you have your world in sync with kernel. I think '/usr/bin/top -v', 'ident /usr/bin/top' could be helpful here. -- Mikolaj Golub