Information Technology Reference
In-Depth Information
data you want. The design of DTrace makes it inherently safe to use: It is impos-
sible to create an infinite loop in DTrace, and it is impossible to dereference an
invalid pointer. For these and other reasons, it is safe to use DTrace on production
systems (which you should not do with a kernel debugger).
OSV implementations include just one OS kernel, which is shared by all of the
VEs. This facet of the OSV model enables you to use OS tools such as DTrace to look
at all of the VEs as entities, or to peer into each VE and view its constituent parts.
Earlier we saw how DTrace can be used to examine aggregate memory usage,
with the zvmstat script. You can also use this tool to gather and report data
for a single Container. For example, if vmstat showed an unusually high system
call rate, you could use these DTrace commands to determine which Container
is causing these calls, which system call is being made most often, and which
program is issuing them.
GZ# dtrace -n 'syscall:::entry { @num[zonename] = count(); }'
dtrace: description 'syscall:::entry' matched 234 probes
^C
appzone 301
global 11900
webzone 91002
GZ# dtrace -n 'syscall:::entry/zonename=="webzone"/ \
{ @num[probefunc] = count(); }'
dtrace: description 'syscall:::entry' matched 234 probes
^C
exece 1
fork1 1
fstat6 9181
getdents64 9391
lstat64 92482
GZ# dtrace -n 'syscall::lstat64:entry/zonename=="webzone"/ \
{ @num[execname] = count(); }'
dtrace: description 'syscall::lstat64:entry' matched 1 probe
^C
find 107277
GZ# dtrace -n 'syscall::lstat64:entry/zonename="webzone" && \
execname=="find"/ { @num[uid] = count(); }'
dtrace: description 'syscall::lstat64:entry' matched 1 probe
^C
1012 16439
 
Search WWH ::




Custom Search