No, i'm not thinking about the numbers like "good" or "bad" for now. Because of
that little bug in the first script, i'm just trying to realize if the numbers
are OK. ;-)
Like Max said, all the IO's time can be greater than the tracing period. The
only problem was the "two" days of the first sc
Hi Marcelo,
Marcelo Leal wrote:
> Sorry, but i do not agree.
> We are talking about a NFSv3 provider, and not about how many cpu's there
> are on the system. I do not have the knowledge to discuss with you the
> aspects about the implementation, but as a user point of view, i think that
> numb
No bug here - we can absolutely use DTrace on MP systems,
reliably and with confidence.
The script output shows some nasty outliers for a small percentage
of the reads and writes happening on the server. Time to take a closer
look at the IO subsystem. I'd start with "iostat -znx 1", and see what
t
Sorry, but i do not agree.
We are talking about a NFSv3 provider, and not about how many cpu's there are
on the system. I do not have the knowledge to discuss with you the aspects
about the implementation, but as a user point of view, i think that numbers
don't make sense. If the fact that the
Hi Marcelo,
Marcelo Leal wrote:
> Ok, but that is a bug, or should work like that?
> We can not use dtrace on multiple processors systems?
> Sorry, but i don't get it...
>
I don't consider this a bug. I think it depends on what you are trying
to measure.
The script you are using measures l
Ok, but that is a bug, or should work like that?
We can not use dtrace on multiple processors systems?
Sorry, but i don't get it...
__
Leal
[http://www.eall.com.br/blog]
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtra
Hi Marcelo,
Marcelo Leal wrote:
> I think (us) is microseconds. There is one division by "1000" on the source
> code...
>
>
Oops. You're right. I did not see that. (That might explain
the 4-8 nanosecond I/Os, which I did think seemed pretty fast.
They are actually 4-8 microsecond). So, you
I think (us) is microseconds. There is one division by "1000" on the source
code...
Leal
[http://www.eall.com.br/blog]
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Marcelo Leal wrote:
>> Marcelo Leal wrote:
>>
>>> Hello all...
>>> Thanks a lot for the answers! I think the problem
>>>
>> is "almost" fixed. Every dtrace documentation says to
>> use predicates to guarantee the relation between the
>> start/done probes... Max was the only one paying
> Marcelo Leal wrote:
> > Hello all...
> > Thanks a lot for the answers! I think the problem
> is "almost" fixed. Every dtrace documentation says to
> use predicates to guarantee the relation between the
> start/done probes... Max was the only one paying
> attention reading the docs. ;-)
> >
>
Marcelo Leal wrote:
> Hello all...
> Thanks a lot for the answers! I think the problem is "almost" fixed. Every
> dtrace documentation says to use predicates to guarantee the relation between
> the start/done probes... Max was the only one paying attention reading the
> docs. ;-)
>
Actually,
Hello all...
Thanks a lot for the answers! I think the problem is "almost" fixed. Every
dtrace documentation says to use predicates to guarantee the relation between
the start/done probes... Max was the only one paying attention reading the
docs. ;-)
But i'm still getting weird numbers:
Wed D
On Tue, Dec 09, 2008 at 05:04:49PM +0100, [EMAIL PROTECTED] wrote:
> Hi,
> I have looked at the script, and there is no correspondence between
> start and done.
> So, I am not sure how this script is supposed to work.
> I think there should be a predicate in the done probes...
> The way the script
Hi Brendan,
Brendan Gregg - Sun Microsystems wrote:
> On Tue, Dec 09, 2008 at 05:04:49PM +0100, [EMAIL PROTECTED] wrote:
>
>> Hi,
>> I have looked at the script, and there is no correspondence between
>> start and done.
>> So, I am not sure how this script is supposed to work.
>> I think there
Marcelo Leal wrote:
> Oops, that would be a nice test, but something i cannot do. ;-)
>
What is it that you cannot do?
> [http://www.eall.com.br/blog]
>
> Leal.
>
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Hi Marcelo,
Marcelo Leal wrote:
> Some kind of both... ;-)
> I was investigating a "possible" performance problem, that i'm not sure if
> is the NFS server or not.
> So, i was faced with that weird numbers. I think one thing is not related
> with the other, but we need to fix whatever is the
D'oh! Good spot Max - feeling sheepish that I missed that.
Marcelo - add the predicate to the "done" probes as per Max's
message, and let's see where that takes us
Thanks,
/jim
[EMAIL PROTECTED] wrote:
> Hi,
> I have looked at the script, and there is no correspondence between
> start and
Some kind of both... ;-)
I was investigating a "possible" performance problem, that i'm not sure if is
the NFS server or not.
So, i was faced with that weird numbers. I think one thing is not related with
the other, but we need to fix whatever is the problem with the script or the
provider, t
Oops, that would be a nice test, but something i cannot do. ;-)
[http://www.eall.com.br/blog]
Leal.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Hi,
I have looked at the script, and there is no correspondence between
start and done.
So, I am not sure how this script is supposed to work.
I think there should be a predicate in the done probes...
The way the script is written, it assumes that for any start, the done
that fires after it is for
Hi Marcelo and Jim,
Marcelo Leal wrote:
> Hello Jim, this is not a benchmark. The filenames i did change for privacy...
> This is a NFS server, yes.
>
> # uname -a
> SunOS test 5.11 snv_89 i86pc i386 i86pc
>
> # cat /etc/release
>Solaris Express Community Edition snv_89 X86
>
Also (I meant to ask) - are you having performance problems, or
just monitoring with the NFS provider scripts?
Thanks,
/jim
Marcelo Leal wrote:
> Hello Jim, this is not a benchmark. The filenames i did change for privacy...
> This is a NFS server, yes.
>
> # uname -a
> SunOS test 5.11 snv_89 i8
Hello Jim, this is not a benchmark. The filenames i did change for privacy...
This is a NFS server, yes.
# uname -a
SunOS test 5.11 snv_89 i86pc i386 i86pc
# cat /etc/release
Solaris Express Community Edition snv_89 X86
Copyright 2008 Sun Microsystems, Inc. All Rig
HmmmSomething is certainly wrong. 11 writes at 137k - 275k seconds
(which is where your 1.5M seconds sum is coming from) is bogus.
What version of Solaris is this ('uname -a' and 'cat /etc/release')?
Your running this on an NFS server, right (not client)?
Is this a benchmark? I ask because t
Hello Jim!
Actually i can repeat it... every time i did run some d script to collect some
data i got some (how do you call it? nasty :) values. Look:
Fri Dec 5 10:19:32 BRST 2008
Fri Dec 5 10:29:34 BRST 2008
NFSv3 read/write distributions (us):
read
value - Distrib
Nasty, nasty outlier.
You have a very nasty outlier in the quantized write latency data;
34359738368 | 0
68719476736 | 1
137438953472 | 0
See that sucker with th
36 hours... ;-))
Leal.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Hello Jim,
- cut here ---
Qui Dez 4 19:08:39 BRST 2008
Qui Dez 4 19:18:02 BRST 2008
- cut here ---
NFSv3 read/write distributions (us):
read
value - Distribution - count
2 |
Got it.
OK, so you traced for 10 minutes, and dtrace reported a total
value of 131175486635, which we'll round up to 132 billion
microseconds, or (if I'm doing the math right),
132,000 seconds or 2200 minutes. That certainly seems to be
an extraordinarily large value for 10 minutes of data collect
Hello,
> Are you referring to nfsv3rwsnoop.d?
>
> The TIME(us) value from that script is not a latency
> measurement,
> it's just a time stamp.
>
> If you're referring to a different script, let us
> know specifically
> which script.
Sorry, when i did write "latency", i did assume that you wil
Are you referring to nfsv3rwsnoop.d?
The TIME(us) value from that script is not a latency measurement,
it's just a time stamp.
If you're referring to a different script, let us know specifically
which script.
/jim
Marcelo Leal wrote:
> Hello there,
> Ten minutes of trace (latency), using the
31 matches
Mail list logo
