> Thanks! As long as I can trust (more or less) the numbers for the > USR/SYS and avoid the dampening effect of the regular prstat - I am > happy.
I'm not sure I understand your comments about regular prstat. Would you be kind enough to describe the dampening effect you've mentioned? I'd be interested to know what observability problems this causes for you too. > I run a little test comparing "prstat -m 1" to "vmstat" 1. I took about > 300 samples each starting at about the same time. Then I added USR and > SYS percentages for all processes for each sample and divided the result > by 4 (number of CPUs). I plotted this against vmstat cpu_us - and the > result was not identical but very close. Essentially: > > PRSTAT:SUMofALL(SYS+USR)/Nprocessors = VMSTAT:cpu_us > > Is this what one would expect? My reccolection in this department is fuzzy. I believe that these are two different mechanisms on Solaris 9. The cpu_us value is determined by sampling the system usage when the clock() thread files. The SYS+USR totals from microstate accounting are generated as the lwps change state. In Solaris 10, the mechanism used by mpstat/vmstat, etc which determine the CPU usage have been re-designed. They use a state transition-based method instead of sampling. I'm not sure that you can always expect that 'PRSTAT:SUMofALL(SYS+USR)/Nprocessors = VMSTAT:cpu_us' will always be true. I there are pathological cases where a thread can be scheduled in such a way that it avoids detection by the clock thread. I'm sorry I didn't ask this before, but what exactly are you trying to measure? -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
