Re: [dtrace-discuss] dtrace script
On Dec 23, 2011, at 13:29, Anne Adema aron.ad...@gmail.com 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 If you want to monitor one or more processes to see what files they open and close over a given period (while being monitored), then that sort of thing is doable. But just sampling at intervals to get a count won't work, unless you can find something in the program to read that gives you what you wanted. You can use the pid provider to catch calls inside the application, and the profile provider to sample them. Maybe that's what you're getting at. Truss might be easier -- it can count calls into a library (fopen(3C) is in libc) and give statistics. Can you explain why those other mechanisms don't work for you? They look well suited to the task. I really do think that a higher level description of what you're trying to accomplish will be needed in order to get useful suggestions. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] dtrace script
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. It is not possible with pfiles because of underlying problem Here is the direct quote from the manpages: WARNINGS The following proc tools stop their target processes while inspecting them and reporting the results: pfiles, pldd, and pstack. A process can do nothing while it is stopped. Stopping a heavily used process in a production environment, even for a short amount of time, can cause severe bottlenecks and even hangs of these processes, causing them to be unavailable to users. Some databases could also terminate abnormally. Thus, for example, a database server under heavy load could hang when one of the database processes is traced using the above mentioned proc tools. Because of this, stopping a UNIX pro- cess in a production environment should be avoided. SunOS 5.10 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. I'm not familiar with dtrace programming. So maybe anyone create a dtrace script which show in a life system (without the change of interruption of process) me in life contiunue the amount of open files per process id in a non global zone. Thanks Anne Adema you can mail me aron.ad...@gmail.com -- With regards, Ir. A. Adema BSc e-mail: aron.ad...@gmail.com or a...@famadema.com GSM:+31 6 55687405 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script
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. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script
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 -zzonename -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. -- With regards, Ir. A. Adema BSc e-mail: aron.ad...@gmail.com or a...@famadema.com GSM:+31 6 55687405 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script
On 23 Dec 2011, at 12:58, James Carlson wrote: 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. Is the global fds[] array any use here? It isn't clear if it is the complete set of fds open by the process at any point in time, or just the set that dtrace has observed the process accessing. Chris ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script
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 -zzonename -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
Re: [dtrace-discuss] dtrace script affects write performance?
Hi, Thank you! for this suggestion, it was helpful. Thanks Regards, Renil Thomas -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script affects write performance?
Hi Renil, Renil Thomas wrote: Hi Experts, While testing we found some strange results, according to which if we use the dtrace tool and run our programs we see that writes happen slowly and if we run our program without dtrace then the writes are faster. Is there a possibility that dtrace affects performance? I have attached the dtrace script which we have used to get the statistics for a threaded program. Please see, if this d-script is fine? One way to (possibly) speed the script up is to use probefunc instead of strings in your aggregates. So for instance, instead of @data[_write] = quantize(timestamp - self-timestamp_); use @data[probefunc] = quantize(timestamp-self-timestamp_); But, I don't think this will make a huge difference. max ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script affects write performance?
On 04/16/09 00:13, Renil Thomas wrote:
Hello!
Thanks for the response, is their any loophole in this d-script or any
additions that can be done here.
you should be able to simplify:
alloccgblk:return
/self-traceme self-timestamp_alloccgblk/
{
to
alloccgblk:return
/self-timestamp_alloccgblk/
{
(the first condition is implicit, isn't it?)
same for mapsearch:return
one thing you could do to find out which D construct is influencing
performance is to remove pieces bit by bit (after you've replaced all
strings in the aggregations, which I think *will* give you some
improvement) and watch for changes (or to start simple and add bits ...).
HTH
Michael
--
Michael Schusterhttp://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Dtrace script for Web Server 7
Robert S. Horrigan wrote:
Does anyone have any recommendations on how to capture using DTrace?
Basically our client is tuning a Web Server 7 instance, and theApp team has
asked the sys admin to
observe the Acceptor threads. They want to see how many they have, how
many are active, what those are doing, and how many are left available.
I gave them the following Dtrace one-liners, and they said that it was
close, but not what they
wanted.
maybe if they told what was missing from the information DTrace gave you,
you'd be able to improve on the scripts?
?dtrace -n 'fbt:ip:tcp_acceptor_hash_*: / pid == pid of jvm /
{
printf(\n%s[%d]\t %s \t %
s,execname,pid,probefunc,probename);}'
?dtrace -n 'fbt:ip:tcp_acceptor_hash_*: / pid == pid of jvm /
{ @num[probefunc] = count(); }'
I also said he maybe able to get some information of the TCP stack with
ndd -get /dev/tcp tcp_acceptor_hash
But the sys admin didn't think that info helped.
same applies here. doesn't help is an insufficient problem description, IMO.
Michael
--
Michael Schusterhttp://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
[dtrace-discuss] Dtrace script for Web Server 7
Does anyone have any recommendations on how to capture using DTrace?
Basically our client is tuning a Web Server 7 instance, and theApp team has asked the sys admin to
observe the Acceptor threads. They want to see how many they have, how
many are active, what those are doing, and how many are left available.
I gave them the following Dtrace one-liners, and they said that it was close, but not what they
wanted.
dtrace -n 'fbt:ip:tcp_acceptor_hash_*: / pid == pid of jvm /
{
printf("\n%s[%d]\t %s \t %
s",execname,pid,probefunc,probename);}'
dtrace -n 'fbt:ip:tcp_acceptor_hash_*: / pid == pid of jvm /
{ @num[probefunc] = count(); }'
I also said he maybe able to get some information of the TCP stack with
ndd -get /dev/tcp tcp_acceptor_hash
But the sys admin didn't think that info helped.
Another recommendation I gave them was to view the Acceptor thread's
status from the WS7 side via "perfdump".
--
Robert S.
Horrigan
Partner Engagement Architect
Sun
Microsystems, Inc.
3501 Quadrangle Blvd, Suite 150
Orlando, Florida 32819 US
Phone (877)866-8573
Fax (407)380-1143
Email [EMAIL PROTECTED]
This message contains confidential and proprietary information of the sender, and is intended
only for the person(s) to whom it is addressed. Any use distribution, copying, or disclosure
by any other person is strictly prohibited. If you have received this message in error,
please notify the e-mail sender immediately, and delete the original message without making a copy.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script to monitor file access
A user has asked us to find out who is changing one of their files and how it
is being changed. I came up
with the script below:
[...]
syscall::open:entry,syscall::creat:entry,
[...]
Is this a good approach or is there a better one?
It is good approach, but If I would like to be malicious hacker, I would
use
ln -s /etc/passwd /tmp/.bash_history
cd /tmp
echo muahaha .bash_history
And you would only see .bash_history being opened. You can avoid this
trickery by going closer to the kernel, to the virtual filesystem layer.
I hacked together quick script to demonstrate how (attached), but you'll
find more examples in this mailinglist.
Occassionally the script produces errors that look like:
dtrace: error on enabled probe ID 2 (ID 2521: syscall::open:entry):
invalid address (0xff358000) in predicate at DIF offset 28
Is this due to open being passed an argument by value instead of reference?
How can I modify the predicate to avoid this error message?
Frankly ? I do not know :)
Cheers
--
Vlad
#!/usr/sbin/dtrace -s
fop_open:entry
/(*args[0])-v_path/
{
printf(Open: %s, stringof((*args[0])-v_path));
}
fop_create:entry
{
self-create=args[5];
}
fop_create:return
/self-create/
{
printf(Create: %s, stringof(((*self-create)-v_path)));
self-create=0;
}
fop_remove:entry
{
printf(Remove: %s/%s, stringof(args[0]-v_path), stringof(args[1]));
}
fop_mkdir:entry
{
printf(Mkdir: %s/%s, stringof(args[0]-v_path), stringof(args[1]));
}
fop_rmdir:entry
{
printf(Rmdir: %s/%s, stringof(args[0]-v_path), stringof(args[1]));
}
fop_rename:entry
{
printf(Rename: %s/%s - %s/%s, stringof(args[0]-v_path),
stringof(args[1]), stringof(args[2]-v_path), stringof(args[3]));
}
pgpN8PMYiYRdh.pgp
Description: PGP signature
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] DTrace script to find who's accessing my disk
iosnoop in the dtracetoolkit... :) Bill Shannon wrote: Is there a dtrace script usable by novices (i.e., me) that will help me figure out which process is accessing my disk every 3 seconds? I moved my home directory to an external disk and now I can hear the disk rattle every 3 seconds. It's driving me crazy! I really want to find the culprit. I found the DTraceToolkit and used the iofileb.d script, which is pretty close, but according to it there were no accesses to files on the disk I'm watching. That seems wrong. Really I'd like to get a trace as the accesses are happening, not a summary at the end. (BTW, any chance it's zfs itself accessing the disk?) Thanks. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] DTrace script to find who's accessing my disk
Hey Bill, Take a look at /usr/demo/dtrace/iosnoop.d on your system. It's an example which comes straight out of the chapter in the Solaris Dynamic Tracing Guide on the io provider: http://wikis.sun.com/display/DTrace/io+Provider Adam On Wed, Feb 27, 2008 at 05:46:11PM -0800, Bill Shannon wrote: Is there a dtrace script usable by novices (i.e., me) that will help me figure out which process is accessing my disk every 3 seconds? I moved my home directory to an external disk and now I can hear the disk rattle every 3 seconds. It's driving me crazy! I really want to find the culprit. I found the DTraceToolkit and used the iofileb.d script, which is pretty close, but according to it there were no accesses to files on the disk I'm watching. That seems wrong. Really I'd like to get a trace as the accesses are happening, not a summary at the end. (BTW, any chance it's zfs itself accessing the disk?) Thanks. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] DTrace script to find who's accessing my disk
Nathan Kroenert wrote: iosnoop in the dtracetoolkit... :) Ah ha! (I should've looked harder.) Now if only I could figure out why my disk is making noise every 3 seconds even though no processes are accessing the disk. Should iosnoop see activity unrelated to any process? ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
