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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
