Hello,
Let me suggest a hypothetical process and activity and clarify what you
actually want to collect:
You have a process which has an existing socket connection and log file
which are sporadically being used (meaning they are being used but not
necessarily during the time frame that your Dtrace process runs).
During the time frame that you run your Dtrace script it also opens a
new file with fopen (libc call which calls open system call) and also
creates a new network connection by creating a socket and then using
connect { sorry, I haven't done much network programming and none
recently, so I am based this on quick check of the man pages }).
So, here is a brief time line
process opens log file
process creates network connection
Monitoring of process starts
process creates file
process creates network connection
Monitoring of process stops
The pfile command stops the process and will list all the existing file
descriptors which includes the open files and sockets. If run when
monitoring starts, it can't show anything about the new file or socket
because they don't exist yet.
If you use Dtrace you won't know anything about the already existing
file or socket, and depending on what you monitor you may not may not
even be aware that a new socket is being created.
If you only trap/instrument the open system call, then you won't know
about the socket, but you could also trap/instrument other calls and add
to what you are monitoring but there is a cost to everything.
While pfiles (and all of the pcommands ) stop the process and do the
work external to the running process, Dtrace actually steals/side tracks
the CPU cycles from the running process to do additional processing.
The effect from either method can range from minor to severe. A quick
way to judge how monitoring more details can increase the impact is to
use truss.
truss can record a while range of activities, by default it only
monitors system calls, but it can also monitor function calls either
within the executable or within libraries.
try the following:
time ls -ald .
time truss -o /dev/null ls -ald .
time truss -o /dev/null -u a.out ls -ald .
time truss -o /dev/null -u a.out -u :: ls -ald .
As for the warning about pfiles. I have seen crash dumps where
monitoring software panicked the system because some p-command had been
run against a process which introduced a delay. The delay in that cause
was due to one of the threads in the process taking a long time to stop
while the rest of the threads had already stopped. I think that is the
only case where I have seen such a panic in approximately 4+ years in
the Kernel group. So the risk is real, but generally minor. Just like
the performance impact of just counting the number of files being opened
or closed during the run of Dtrace script would be minor, but they
really do report different types of information and you can't replace
one with the other.
Hope this helps,
Robert
On 12/23/2011 8:29 AM, Anne Adema wrote:
Hi James,
What I'm looking for in a while true loop to see amount fopen calls for
a certain pid
while true
do
cmd for amount fopen call for certain pid dtrace script
sleep 60
done
or dtrace script with same loop
Gr Anne
Op 12/23/11 1:58 PM, James Carlson schreef:
Anne Adema wrote:
Hi
Does anyone has a dtrace script which determine in a life system the
amount of open files per process id in a Non Global Zone.
In general, dtrace allows you to look at *events* as they occur. It's
not so good at summarizing system state at a point in time.
GZ> lsof -z<zonename> -p pid
Does not give the right output.
ls /proc/<pid>/fd | wc -l gives not the open files per process id.
Both of those work fine for me. It might help if you can describe what
you see that's wrong with the output of those sorts of commands.
Otherwise, it will probably be hard to determine what sort of solution
might help you.
--
Oracle <http://www.oracle.com/>
Robert Alatalo | Solaris and Network Domain, Global Systems Support
Email: robert.alat...@oracle.com
Phone: +1.781.442.1301
Oracle Global Customer Services
Log, update, and monitor your Service Request online using My Oracle Support
https://support.oracle.com
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
