I am trying to measure the cost (cpu impact) of transactions on a network mamangement server that runs solaris 9. I generate a predetermined rate of a certaintransaction type, then see the CPU impact. Here I look at the total CPU reported by vmstat. However, to open-up cup utilization I use prstat to see utilization by process/thread.
I noticed that often cpu per process reported by prstat does not add up to vmstat (cpu_us). More-over, when an activity starts, the vmstat reports the impact immediately, while prstat has a dampening effect and it takes several samples before full cpu utilization is reported. The impact of this is that CPU utilization for short0lived processes is under-reported. So I was looking for ways to reduce/explain this dampening effect and ideally to find a tool that breaks-down cpu by lwp, that is as responsive to the cpu load changes as vmstat and that would match the results of vmstat. Then I came across the following: From: http://www.opensolaris.org/jive/thread.jspa?messageID=44020꯴ [i]prstat is printing procfs's pr_pctcpu, typedef struct psinfo { ... ushort_t pr_pctcpu; /* % of recent cpu time used by all lwps */ "recent" as it is a heavily damped measurement. It is maintained per LWP, and combined to create the by-process measurement. The actual value is calculated by cpu_grow() and cpu_decay() (called when threads context switch) from uts/common/os/msacct.c, which has a comment to describe the behaviour, /* * Given the old percent cpu and a time delta in nanoseconds, * return the new decayed percent cpu: pct * exp(-tau), * where 'tau' is the time delta multiplied by a decay factor. * We have chosen the decay factor (cpu_decay_factor in param.c) * to make the decay over five seconds be approximately 20%. * * 'pct' is a 32-bit scaled integer <= 1 * The binary point is to the right of the high-order bit * of the 32-bit word. */ static uint32_t cpu_decay(uint32_t pct, hrtime_t nsec) ... So, decay by 20% per 5 seconds would explain your gradual change in %CPU. Use "prstat -m" to get a direct measurement.[/i] So I started experimenting with prstat -m. Also, as I ran more tezts I realized that my previous assertion that [b]PRSTAT:SUMofALL(SYS+USR)/Nprocessors = VMSTAT:cpu_us[/b] does not hold when you have many threads each using little amount of cpu. -eM This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org