From owner-freebsd-hackers Wed May 15 10:33: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id A69C237B409 for ; Wed, 15 May 2002 10:32:58 -0700 (PDT) Received: from onyx ([128.226.182.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g4FHWsZ16403; Wed, 15 May 2002 13:32:54 -0400 (EDT) Date: Wed, 15 May 2002 13:32:53 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: Terry Lambert Cc: Doug White , freebsd-hackers@FreeBSD.ORG Subject: Re: Collect process sleeping statistics In-Reply-To: <3CE1F48A.532F0649@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Basically I have a program that does a lot of I/O and alloctes/frees a lot of memory. The time command gives result like this: 6.239u 19.329s 7:59.76 5.3% 310+775k 3993+246io 7pf+0w I want to know why CPU is running only 5.3% of the total time. I just want know how long it is waiting for memory and how long it is waiting for I/O. No other process is running at the same time. -Zhihui On Tue, 14 May 2002, Terry Lambert wrote: > Doug White wrote: > > On Mon, 13 May 2002, Zhihui Zhang wrote: > > > A process can sleep for various reasons such as memory, I/O etc. Is there > > > a way to collect statistics about how long it sleeps for different > > > reasons? Thanks. > > > > I don't think it's actually accounted for anywhere, but if a process does > > go to sleep the WCHAN will be filled in and visible in top and ps. > > > > You could write a program to collect the WCHANs every so often and build > > some course stats. And if you really wanted to get fancy it might not be > > too hard to build a scheduler or hz-driven procedure to log them directly > > in the kernel. > > Profiling will also show the amount of time spent in "sleep" for > a process. Generally, you eliminate these arc's as "unrecoverable > system overhead". You typically "treat" these symptoms by changing > algorithms in user space, or, if you have an application specific > need, hacking the kernel after doing kernel profiling on the code > paths. > > I don't think a statistical sampling of the wait channels outstanding > would be very useful. Statistical sampling done for normal profiling > (profiling without compiler hacks for recording function entry and > exit) is barely generally useful on its own (IMO); you would effectively > have to hook into the profiling clock, which means kernel space work, > for "outstanding wait channel" tagging. > > The reason it wouldn't be that useful is that profiling arcs are > generally either above or below -- not spanning -- the user/kernel > boundary, so there's a lot of information that would get lost in > the process, I think. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message