Re: [perf-discuss] Per thread CPU statistics

2010-01-07 Thread Chad Mynhier
On Thu, Jan 7, 2010 at 8:44 AM, Paul wrote: > I have no problem finding, from with a "C" app, my process utilization. > > I need now to dig deeper and extract internally to the app the CPU > utilisztion of each thread within my app > > Any help, better still source fragment, would be much appreci

Re: [perf-discuss] Kernel usage

2009-10-19 Thread Chad Mynhier
On Mon, Oct 19, 2009 at 7:23 AM, Chad Mynhier wrote: > On Mon, Oct 19, 2009 at 6:47 AM, Matt V. wrote: >> Hi, >> >> On a Solaris 10 server, with 'top' command, we have: >> CPU states: 28.9% idle, 14.2% user, 56.9% kernel,  0.0% iowait,  0.0% swap >>

Re: [perf-discuss] Kernel usage

2009-10-19 Thread Chad Mynhier
On Mon, Oct 19, 2009 at 6:47 AM, Matt V. wrote: > Hi, > > On a Solaris 10 server, with 'top' command, we have: > CPU states: 28.9% idle, 14.2% user, 56.9% kernel,  0.0% iowait,  0.0% swap > > How to know where is spent kernel usage please ? > > Thank you in advance. > Matt There are a number of t

[perf-discuss] fuser(1M) performance fix

2009-09-02 Thread Chad Mynhier
I've filed a bug about the performance of fuser(1M) (6878048: fuser performance is suboptimal, which hasn't shown up on bugs.opensolaris.org as I write this.) I've also coded up a fix that makes the performance more reasonable. (I've requested a sponsor on request-sponsor, but I figured I'd add m

Re: [perf-discuss] prstat consuming 100% sys

2009-06-18 Thread Chad Mynhier
On Thu, Jun 18, 2009 at 5:37 AM, Mikael Kjerrman wrote: > Thanks for the help. > BTW this is what I see, [ ... ] >              genunix`rm_assize+0xa0 >              procfs`prgetpsinfo+0x3d0 >              procfs`pr_read_psinfo+0x38 >              genunix`fop_read+0x20 >              genunix`pread+

Re: [perf-discuss] prstat consuming 100% sys

2009-06-17 Thread Chad Mynhier
On Wed, Jun 17, 2009 at 11:03 AM, Mikael Kjerrman wrote: > Hi, > > by accident I observed that various CPU on a rather heavily loaded Oracle > server sometimes consumed 100% sys > and apparently this was caused by prstat. > >   PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/L

Re: [perf-discuss] real meaning of ithr from mpstat

2009-05-12 Thread Chad Mynhier
On Tue, May 12, 2009 at 9:07 AM, Qihua Wu wrote: > From the man page, > ithr is "interrupts as threads", but what's the detailed meaning of > "interrupts as threads"? And under what condition will this interrupt > happen? The ithr column shows the number of interrupts that are converted to real t

Re: [perf-discuss] Sol10 Leak memory

2009-03-09 Thread Chad Mynhier
On Mon, Mar 9, 2009 at 3:52 AM, elkhaoul wrote: > Hi, > > Solaris 10 3/05 s10_74L2a SPARC use 30% of memory and it increase every days. > > Is there any leak memory in this OS (Sol10 118822-26) ? > No, this is normal behavior. The buffer cache will grow to use all of free memory. It won't steal

Re: [perf-discuss] The rm_assize() problem

2009-03-02 Thread Chad Mynhier
On Thu, Feb 26, 2009 at 2:10 PM, wrote: > >> (To expand on the problem a bit, the problem comes when a process maps >> a file into a segment that's larger than the file, e.g., mapping a 1K >> file into a 10K segment.  Currently rm_assize() will only count the >> space used through the end of the

Re: [perf-discuss] The rm_assize() problem

2009-02-25 Thread Chad Mynhier
On Wed, Feb 25, 2009 at 10:26 AM, Chad Mynhier wrote: >> vm/vm_rm.c: >> >>  - lines 105-135: Dumb question -> Where is this case handled now? >> > > Nope, not a dumb question, a dumb oversight on my part.  And this > might completely scupper what I want to do.

Re: [perf-discuss] The rm_assize() problem

2009-02-25 Thread Chad Mynhier
Thanks for the comments. On Tue, Feb 24, 2009 at 5:15 PM, wrote: > Hi Chad, > You probably want a vm expert to take a look at this code, but I'm > happy to provide comments anyway. > > vm/as.h: > >  - line 114: You probably want this member at the end of the >    structure.  If we end up backpor

[perf-discuss] The rm_assize() problem

2009-02-24 Thread Chad Mynhier
I've submitted a bug related to this problem: http://bugs.opensolaris.org/view_bug.do?bug_id=6801244. The gist of this problem is that Solaris calculates the VM size of a process when asked, i.e., when some utility like ps(1) or prstat(1M) reads /proc//psinfo. This can be a problem on servers wit

Re: [perf-discuss] Contributer grant nomination for Chad Mynheir

2009-02-08 Thread Chad Mynhier
I don't know if I need to explicitly state my acceptance, but if so, I accept. Thanks, Chad On Fri, Feb 6, 2009 at 1:23 PM, Jonathan Chew wrote: > +1 > > > Jonathan > > Eric Saxe wrote: >> I'd like to put forth a contributer grant nomination for Chad Mynhier,

[perf-discuss] ptime(1) improvements

2009-01-21 Thread Chad Mynhier
If anyone's interested, a few improvements to ptime(1) went back into build 104. The default resolution for ptime(1) is now nanoseconds, not milliseconds. ptime(1) now gives you microstate accounting with the -m flag. ptime(1) can give you a snapshot of stats for a running process with the -p fl

Re: [perf-discuss] [request-sponsor] 4532599: ptime should report resource usage

2008-04-22 Thread Chad Mynhier
On Fri, Apr 18, 2008 at 4:17 PM, Richard L. Hamilton <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 18, 2008 at 7:32 AM, Richard L. Hamilton > > <[EMAIL PROTECTED]> wrote: > > > How does this behave with the -p option - does it just report > > > the current usage, or does it wait for the process to exi

Re: [perf-discuss] [storage-discuss] zpool io to 6140 is really slow

2007-11-20 Thread Chad Mynhier
On 11/20/07, Asif Iqbal <[EMAIL PROTECTED]> wrote: > On Nov 20, 2007 7:01 AM, Chad Mynhier <[EMAIL PROTECTED]> wrote: > > On 11/20/07, Asif Iqbal <[EMAIL PROTECTED]> wrote: > > > On Nov 19, 2007 1:43 AM, Louwtjie Burger <[EMAIL PROTECTED]> wrote: > >

Re: [perf-discuss] [storage-discuss] zpool io to 6140 is really slow

2007-11-20 Thread Chad Mynhier
ut at a data transmission rate around 200MB/s rather than the 256MB/s that you'd expect. Fibre channel uses an 8-bit/10-bit encoding, so it transmits 8-bits of data in 10 bits on the wire. So while 256MB/s is being transmitted on the connection itself, only 200MB/s of that is the data that you