The reason such a script doesn't already exist is that CPU / memory utilization is pretty difficult to get using DTrace. DTrace is best for sampling data on a certain event. To get CPU utilization using DTrace, you would need to track every time a CPU became free and every time it became busy and then do some addition. Note that this is different from the provider that DTrace gives for tracking scheduler operations since those are on a per-thread basis rather than a per-CPU basis. Memory is even more annoying, since you would be tracking every memory allocation and deallocation.
To get these data sources, you might be better served by pulling the data from kstat
(it sounds like you're using Solaris, which AFAIK is the only platform that has kstat
). The information you're looking for can be found using it like so:
$ sudo kstat unix:0:system_misc:ncpus # this is the number of CPUs you have
module: unix instance: 0
name: system_misc class: misc
ncpus 2
$ sudo kstat cpu::sys:cpu_ticks* # ticks of each type for each core since boot
module: cpu instance: 0
name: sys class: misc
cpu_ticks_idle 9375292
cpu_ticks_kernel 82658
cpu_ticks_user 23684
cpu_ticks_wait 0
module: cpu instance: 1
name: sys class: misc
cpu_ticks_idle 9410367
cpu_ticks_kernel 49141
cpu_ticks_user 21956
cpu_ticks_wait 0
$ sudo kstat unix:0:system_pages:physmem # pages of physical memory (multiply by page size for number of bytes)
module: unix instance: 0
name: system_pages class: pages
physmem 1045390
$ sudo kstat unix:0:system_pages:freemem # pages of free memory (multiply by page size for number of bytes)
module: unix instance: 0
name: system_pages class: pages
freemem 880842
Note that you need to subtract each new reading from the last reading for the CPU ticks counters - otherwise, you'll be tracking the total number of ticks since system boot. When the counters overflow, they are set to 0 and then the new value is added to them (it's not just a blind addition overflow).
You can also use kstat
to monitor the number of bytes read/written over network links using the link:0::
. I'm not sure if this information can be found per-zone, but there's probably a kstat
that tracks that, too.
I guess if you were determined to use DTrace to monitor the values, you could force it to do so by tracking the moments when these counters are being modified in the kernel and record the modifications. However, I don't really see the point of doing that as it's easier to use other methods as you've already discovered. Why not make a script that starts up both data sources and combine the results into something nicer to look at?