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.adema at gmail.com
--
With regards,
Ir. A. Adema BSc
e-mail: aron.adema at gmail.com or
anne at famadema.com
GSM: +31 6 55687405
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20111223/f0a9da64/attachment.html>
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 <carlsonj at workingcode.com>
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. >-- With regards, Ir. A. Adema BSc e-mail: aron.adema at gmail.com or anne at famadema.com GSM: +31 6 55687405
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
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.Alatalo at 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
On Dec 23, 2011, at 14:20, Chris Ridd <chrisridd at mac.com> wrote:> > 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. >Lacking looping facilities, I don''t think you''ll get too far that way. It''s just not the right tool for the job, if the job doesn''t revolve around events.
On Dec 23, 2011, at 13:29, Anne Adema <aron.adema at 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 AnneIf 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.