|
Replies:
13
-
Last Post:
Jan 29, 2008 12:43 AM
by: quartier
|
|
|
Posts:
67
From:
CN
Registered:
8/2/06
|
|
|
|
DTrace for MySQL?
Posted:
Jan 23, 2008 1:36 AM
To: Communities » dtrace » discuss
|
|
Is there any *official* plan to have a MySQL provider now? I assume now we have more control to its source tree than before.
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 23, 2008 8:15 AM
in response to: alpen
|
|
Alex Peng wrote:
> Is there any *official* plan to have a MySQL provider now? I assume now we have more control to its source tree than before.
*We* don't, do you? Remember that corporate mergers & acquistions
take months to process, and during that period, business has to
continue as if it may be called off until it's final, as it may be
if not approved by boards, shareholders, regulatory agencies, etc.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 25, 2008 7:38 AM
in response to: alanc
|
|
Alan Coopersmith wrote:
> Alex Peng wrote:
>> Is there any *official* plan to have a MySQL provider now? I assume now we have more control to its source tree than before.
>
> *We* don't, do you?
[That was the answer to the "we have more control" part - not
the question about a plan, BTW, since I realize I wasn't
clear there.]
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
67
From:
CN
Registered:
8/2/06
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 27, 2008 6:57 PM
in response to: alanc
To: Communities » dtrace » discuss
|
|
I should not say "have more control". :) But hopefully our influence should be stronger than before.
|
|
|
|
|
Posts:
96
From:
Lincolnshire, UK
Registered:
9/21/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 25, 2008 12:50 AM
in response to: alpen
|
|
On 23 Jan 2008, at 09:36, Alex Peng wrote:
> Is there any *official* plan to have a MySQL provider now?
MySQL will have DTrace support in the forthcoming 6.0.4 release that
is currently going through QA.
I haven't finished documenting it yet, otherwise I'd point you to the
documentation.
You should find, however, that the latest version on mysql.bkbits.net
of the 6.0 tree has the code. You'll need to use --enable-dtrace
during configure to enable it during build.
Currently the support is very basic, partially because we want to test
out the different areas that are useful and that people want
supported, and partially because there are current limitations in the
DTrace support on non-Solaris platforms (notably OS X) that we'd like
to address before expanding support.
I can certainly let you know when I've completed the documentation
(which will be next week some time, certainly before the end of Jan).
> I assume now we have more control to its source tree than before.
Until the acquisition is complete, no, you (and more specifically,
Sun) don't.
Even then, I doubt 'control' is the right terminology to use.
MC
--
Martin 'MC' Brown, mc at mcslp dot com
Everything MCslp: http://planet.mcslp.com
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
16
From:
San Bruno, CA
Registered:
12/27/07
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 25, 2008 7:01 PM
in response to: mcslp
|
|
At 08:50 +0000 1/25/08, Martin MC Brown wrote:
> I haven't finished documenting it yet, otherwise I'd point you
> to the documentation.
You could always tease us with a list of the probes you support ...
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm at cfcl dot com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
45
From:
SG
Registered:
7/30/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 25, 2008 10:20 PM
in response to: mcslp
|
|
Hi Martin,
Anywhere we could download it to have a peek at the probes that you
have integrated??
Cheers,
Peter
On Jan 25, 2008, at 15:50, Martin MC Brown wrote:
>
> On 23 Jan 2008, at 09:36, Alex Peng wrote:
>
>> Is there any *official* plan to have a MySQL provider now?
>
> MySQL will have DTrace support in the forthcoming 6.0.4 release that
> is currently going through QA.
>
> I haven't finished documenting it yet, otherwise I'd point you to the
> documentation.
>
> You should find, however, that the latest version on mysql.bkbits.net
> of the 6.0 tree has the code. You'll need to use --enable-dtrace
> during configure to enable it during build.
>
> Currently the support is very basic, partially because we want to test
> out the different areas that are useful and that people want
> supported, and partially because there are current limitations in the
> DTrace support on non-Solaris platforms (notably OS X) that we'd like
> to address before expanding support.
>
> I can certainly let you know when I've completed the documentation
> (which will be next week some time, certainly before the end of Jan).
>
>> I assume now we have more control to its source tree than before.
>
>
> Until the acquisition is complete, no, you (and more specifically,
> Sun) don't.
>
> Even then, I doubt 'control' is the right terminology to use.
>
> MC
>
> --
> Martin 'MC' Brown, mc at mcslp dot com
> Everything MCslp: http://planet.mcslp.com
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris dot org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,580
From:
US
Registered:
6/14/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 25, 2008 10:41 PM
in response to: mcslp
To: Communities » dtrace » discuss
|
|
I wonder if anyone is thinking about probes that could be standardized
among various open-source RDBMSs into which they might be added.
To the extent that common measurements could be taken, or skills learned
with one applied to another, it seems to me that all would benefit from the
friendly competition and cross-pollination that would result.
|
|
|
|
|
Posts:
67
From:
CN
Registered:
8/2/06
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 27, 2008 6:56 PM
in response to: rlhamil
To: Communities » dtrace » discuss
|
|
Yes, I like this "standardized" idea. During the TechDay, I saw that PostgreSQL has some DTrace probes, and in "DTrace for web 2.0" session, we use PID and c++filt to find out dispatch_command() and trace its argument. If there are any USDT probes there, then the observation would be much easier.
|
|
|
|
|
Posts:
32
From:
Austin, TX
Registered:
12/16/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 28, 2008 6:23 AM
in response to: rlhamil
|
|
Richard L. Hamilton wrote:
> I wonder if anyone is thinking about probes that could be standardized
> among various open-source RDBMSs into which they might be added.
>
>
A few of us have thought about this idea. The thinking was to define a
set of probes that are common to all DBs and put them in one provider
(eg: database or db). For DB specific probes, they can be in different
providers (eg: postgresql, mysql, etc).
After we got some DTrace probes into PostgreSQL
(http://www.postgresql.org/docs/8.2/static/dynamic-trace.html), I talked
to some folks at MySQL about the standardization idea, and they were in
favor of it. I'd imagine developers from other OSDBs would be interested
in doing this as well.
Now that we have probes in MySQL and PostgreSQL, we can start defining
what the standard set should look like. I'll create a wiki page to
capture what we have so far, and please contribute especially those who
are familiar with the MySQL probes. This wiki page will be linked from
http://opensolaris.org/os/community/databases/, and I should have in up
in a couple of days.
-Robert
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
12
From:
Paris, France
Registered:
1/17/08
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 29, 2008 12:43 AM
in response to: rlhamil
|
|
Agree on that, similar to the RDMBS MIB we have in the SNMP world. One
day we will have more DTrace probes usage than MIBs ...
Sylvain
-----Original Message-----
From: dtrace-discuss-bounces at opensolaris dot org
[mailto:dtrace-discuss-bounces at opensolaris dot org] On Behalf Of Richard L.
Hamilton
Sent: samedi 26 janvier 2008 07:41
To: dtrace-discuss at opensolaris dot org
Subject: Re: [dtrace-discuss] DTrace for MySQL?
I wonder if anyone is thinking about probes that could be standardized
among various open-source RDBMSs into which they might be added.
To the extent that common measurements could be taken, or skills learned
with one applied to another, it seems to me that all would benefit from
the
friendly competition and cross-pollination that would result.
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
438
From:
CA, USA
Registered:
4/27/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 26, 2008 1:40 AM
in response to: mcslp
|
|
|
|
G'Day Martin, Folks,
On Fri, Jan 25, 2008 at 08:50:33AM +0000, Martin MC Brown wrote:
[...]
> You should find, however, that the latest version on mysql.bkbits.net
> of the 6.0 tree has the code. You'll need to use --enable-dtrace
> during configure to enable it during build.
Thanks for the link, and I can see the 26 probes listed in sql/probes.h.
I'm glad this provider is now public and we can discuss it - it's going
to be of great use, and I'm really looking forward to writing more scripts
for it. I tested a prototype about six months ago and emailed demos of
scripts and suggestions for probe and argument additions; by the looks of
the current probe list, these demos and suggestions may still be relevant,
so I've attached them below.
Note, the demos that follow are not possible with the probes I see in
the 6.0 tree, since they require arguments other than just the thread id.
The 6.0 tree does look like it has a well thought out set of basic probes,
but not interesting arguments such as query strings and database names.
Adding these arguments shouldn't be that difficult (I still have the
mysql patch from when I tried it earlier), the difficult part is choosing
consistent arguments across probes (something worth discussing here).
Writing DTrace scripts will help confirm that the argument choice is
working.
*** Demos ***
The following are fairly simple but useful. The scripts are in the tar
file attached.
mysqld_qsnoop.d traces queries live and prints the user, host and query
string.
# ./mysqld_qsnoop.d
USER@HOST QUERY
root@localhost select * from months
root@localhost select * from months where num > 6
root@localhost select * from months where num > 6 and num < 11
root@localhost show tables
root@localhost show databases
root@localhost select * from words where name > 'z'
^C
In the above example, several simple queries were performed. This script
can be handy for use when troubleshooting to see what is happening. For busy
servers the output can scroll very fast, and mysqld_qcount.d may be more
appropriate.
...
mysqld_qcount.d counts the queries that are requested from mysqld.
# ./mysqld_qcount.d
Tracing... Hit Ctrl-C to end.
^C
USER@HOST COUNT QUERY
root@localhost 1 select * from months where num > 3
root@localhost 1 select * from months where num > 3 and num < 9
root@localhost 1 select num, name from months
root@localhost 1 show databases
root@localhost 3 select * from months
In the above example output, the "select * from months" query was perfomed 3
times, where the others were all performed once.
...
mysqld_qchit.d traces mysqld query cache activity, and prints a report
of hit and miss counts by query string, and totals.
# ./m 3 hit 1
select * from months where num > 3 miss 1
select * from months where num > 3 and num < 9 miss 1
select * from words where name > 'z' miss 1
show databases miss 1
show tables miss 1
select * from months where num > 3 and num < 9 hit 3
select * from words where name > 'z' hit 4
select * from months hit 9
Hits : 17
Misses : 6
Hit Rate : 73%
...
mysqld_qestat.d traces mysqld query execute time and prints a summary line
for each query. Query execution is the last stage in processing a query
(after parsing and planning), and only occurs for queries that miss the
query cache.
# ./mysqld_qestat.d
DATABASE USER@HOST ms RET QUERY
BrendanDatabase root@localhost 0 0 show databases
BrendanDatabase root@localhost 0 0 show tables
BrendanDatabase root@localhost 0 0 select * from months
BrendanDatabase root@localhost 1 0 select * from months
BrendanDatabase root@localhost 14 0 select * from words where nam...
BrendanDatabase root@localhost 158 0 select * from words
BrendanDatabase root@localhost 51 0 select * from words
BrendanDatabase root@localhost 41 0 select * from words
BrendanDatabase root@localhost 35 0 select * from words
BrendanDatabase root@localhost 35 0 select * from words
BrendanDatabase root@localhost 22 -1 select * from bogus
^C
In the example output above, the execution time can be seen for each
query execution, in milliseconds. The RET column shows the return
value for that query, with -1 meaning an error; the "select * from bogus"
query returned an error as that table does not exist.
...
mysqld_qetime.d traces mysqld query execute time and prints distribution
plots of nanosecond times for each query. Query execution is the last stage
in processing a query (after parsing and planning), and only occurs for
queries that miss the query cache.
# ./mysqld_qetime.d
Tracing... Hit Ctrl-C to end.
^C
root@localhost show tables
value ------------- Distribution ------------- count
131072 | 0
262144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1
524288 | 0
root@localhost show databases
value ------------- Distribution ------------- count
524288 | 0
1048576 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1
2097152 | 0
root@localhost select * from months
value ------------- Distribution ------------- count
65536 | 0
131072 |@@@@@@@@@@@@@@@@@ 9
262144 | 0
524288 |@@@@@@@@@@@@@@@@@@@@@ 11
1048576 | 0
2097152 | 0
4194304 | 0
8388608 |@@ 1
16777216 | 0
root@localhost select * from words
value ------------- Distribution ------------- count
16777216 | 0
33554432 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5
67108864 | 0
root@localhost select * from words where name ]
|
|
|
|
|
Posts:
96
From:
Lincolnshire, UK
Registered:
9/21/05
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 26, 2008 12:17 PM
in response to: bgregg
|
|
Hi Brendan,
> G'Day Martin, Folks,
>
> On Fri, Jan 25, 2008 at 08:50:33AM +0000, Martin MC Brown wrote:
> [...]
>> You should find, however, that the latest version on mysql.bkbits.net
>> of the 6.0 tree has the code. You'll need to use --enable-dtrace
>> during configure to enable it during build.
>
> Thanks for the link, and I can see the 26 probes listed in sql/
> probes.h.
>
> I'm glad this provider is now public and we can discuss it - it's
> going
> to be of great use, and I'm really looking forward to writing more
> scripts
> for it. I tested a prototype about six months ago and emailed demos
> of
> scripts and suggestions for probe and argument additions; by the
> looks of
> the current probe list, these demos and suggestions may still be
> relevant,
> so I've attached them below.
Thanks - interesting :)
> Note, the demos that follow are not possible with the probes I see in
> the 6.0 tree, since they require arguments other than just the
> thread id.
>
> The 6.0 tree does look like it has a well thought out set of basic
> probes,
> but not interesting arguments such as query strings and database
> names.
> Adding these arguments shouldn't be that difficult (I still have the
> mysql patch from when I tried it earlier), the difficult part is
> choosing
> consistent arguments across probes (something worth discussing here).
> Writing DTrace scripts will help confirm that the argument choice is
> working.
Please feel free to suggest anything/everything - I'll pass it back to
the team working on this :)
I've already requested my on enhancement, many of which you already
cover (I would like, for example, the thread ID (as exposed internally
through SHOW PROCESSLIST or query at a minimum when examining the
output, otherwise we merely get counters of events, rather than the
ability to track individual queries through the system.
To be fair, remember that at the moment we are merely examining where
best to put these things. Particularly in the 6.0 server there are
some changes that might affect some areas of this. We are also, as I
mentioned originally, trying to be compatible with OS X, but I know
there are some limitations with the current DTrace implementation on
OS X that might make that process more complex than we would like.
> *** Demos ***
>
> The following are fairly simple but useful. The scripts are in the
> tar
> file attached.
It should go without saying that these are pretty cool :)
>
> *** Suggestions ***
>
> here are my suggestions:
>
> 1) Probes
>
> There are many probes to pick from, which is good, but some are
> missing -
> such as probes for the query cache (I have added query cache probes in
> my patch). A quick way to check what might be useful, is to search
> for
> the DBUG_PRINT calls in the code - if it is instrumented for
> debugging,
> it may be useful to instrument it for DTrace.
>
> I'd suggest probes to observe:
>
> - query cache hits / misses
> - connection logins (successful and failed)
> - database startup / shutdown
> - sorts
> - replication events
>
> Of course, we need to focus on probes that are actually useful at
> solving real issues, and not create too many unneeded probes.
> Having a
> small sufficient set of probes will make it easier to keep the
> provider
> as a stable interface.
>
> Also, the "-end" probes I think would be better renamed "-done"
> probes,
> as is the convention in other DTrace providers (such as "io").
I will pass all of this on. As I said earlier, we are still in the
early stages of the process and are trying to work out where best to
add the probes, both in terms of the information that can be tracked/
returned and in terms of selecting the most relevant location.
> 2) Probe Arguments
>
> The provider really needs many more arguments, and there are plenty to
> pick from in the THD class and what it inherits. Here is what I got
> going in my suggested patch:
>
> Probes,
> query-parse-start(thr, database, user, host, query)
> query-parse-done(thr, database, user, host, query, result)
> query-execute-start(thr, database, user, host, query)
> query-execute-done(thr, database, user, host, query, result)
> query-cache-hit(thr, database, user, host, query)
> query-cache-miss(thr, database, user, host, query)
>
> Arguments,
> (void *)thr THR Class pointer (for raw debugging)
> (char *)database Database name string
> (char *)user Username string
> (char *)host Hostname or IP address string
> (char *)query SQL Query string
> (int)result Result (0 == success, -1 == failure)
>
> I didn't find thread_id useful (DTrace already has thread IDs), but
> the
> thr pointer may be useful (both as a unique ID and for raw debugging
> - where
> pretty much any data can be fetch if you know the offset).
>
> The order of arguments is from most to least common. Most probes
> should
> have thr and database, so they go first, followed by user and host,
> then specific arguments - such as query string and result.
>
> The result argument is invaluable. I picked variables that seemed
> reasonable
> for that patch - but please check them more carefully (they look fine,
> but I didn't read all the code).
I'll check this out. It would be nice if we could get some, all or
more of these into the code.
> There is a lot of very cool info in the THD class, but we need to
> consider
> stability (and not expose private implementation details).
> For connection/login probes, the Security_context class has some very
> interesting fields - check them out. Although, they aren't always
> populated
> (I used "user" and "host_or_ip" in my suggested patch - as they seem
> most
> frequently populated).
There's lots all over the place that we could if we wanted to. I think
the key thing is possibly not what we add, but what we don't add.
There's a temptation here to add lots and track everything, but we
have to be sensible...
MC
--
Martin 'MC' Brown, mc at mcslp dot com
Everything MCslp: http://planet.mcslp.com
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
31
From:
Registered:
4/10/07
|
|
|
|
Re: DTrace for MySQL?
Posted:
Jan 26, 2008 6:36 PM
in response to: mcslp
|
|
Hi,
It is great to see that some DTrace probes finally goes into the MySQL 6.0 src tree...
I'm wondering if there is any plan to insert more probes into the storage engine layer as well? so that we can measure the time spending on the defined events in addtion to the count of the events which we can get from the other monitor tools, such as:
- wait on innodb flush logs(flush_log_start/done)
- innodb dirty buffer flush(innodb_dirty_buffer_flush/done)
- MyISAM table locks (myisam_wrlock_start/done)
- row locks(row_lock_start/done)
- innodb buffer wait(reading page synchronous from disk)
- innodb spin wait(innodb_spin_wait_start/done)
- innodb os wait(innodb_os_wait_start/done)
- rollback (rollback_start/done)
and also:
- index/table scan(index_scan_start/done, table_scan_start/done)
- binlog cache spill to disk(binlog_cache_flush/done)
Thanks,
Luojia(Jenny) Chen
Software Engineer
ISV Engineering
v-mail:(510) 550-2394
SUN Microsystems
----- Original Message -----
From: Martin MC Brown <dev at mcslp dot com>
Date: Saturday, January 26, 2008 12:17 pm
Subject: Re: [dtrace-discuss] DTrace for MySQL?
To: Brendan Gregg - Sun Microsystems <brendan at sun dot com>
Cc: dtrace-discuss at opensolaris dot org, Alex Peng <pengjx73 at yahoo dot com>
> Hi Brendan,
>
> > G'Day Martin, Folks,
> >
> > On Fri, Jan 25, 2008 at 08:50:33AM +0000, Martin MC Brown wrote:
> > [...]
> >> You should find, however, that the latest version on mysql.bkbits.net
> >> of the 6.0 tree has the code. You'll need to use --enable-dtrace
> >> during configure to enable it during build.
> >
> > Thanks for the link, and I can see the 26 probes listed in sql/
> > probes.h.
> >
> > I'm glad this provider is now public and we can discuss it - it's
>
> > going
> > to be of great use, and I'm really looking forward to writing more
>
> > scripts
> > for it. I tested a prototype about six months ago and emailed
> demos
> > of
> > scripts and suggestions for probe and argument additions; by the
> > looks of
> > the current probe list, these demos and suggestions may still be
> > relevant,
> > so I've attached them below.
>
> Thanks - interesting :)
>
> > Note, the demos that follow are not possible with the probes I see
> in
> > the 6.0 tree, since they require arguments other than just the
> > thread id.
> >
> > The 6.0 tree does look like it has a well thought out set of basic
>
> > probes,
> > but not interesting arguments such as query strings and database
> > names.
> > Adding these arguments shouldn't be that difficult (I still have the
> > mysql patch from when I tried it earlier), the difficult part is
> > choosing
> > consistent arguments across probes (something worth discussing here).
> > Writing DTrace scripts will help confirm that the argument choice is
> > working.
>
> Please feel free to suggest anything/everything - I'll pass it back
> to
> the team working on this :)
>
> I've already requested my on enhancement, many of which you already
>
> cover (I would like, for example, the thread ID (as exposed
> internally
> through SHOW PROCESSLIST or query at a minimum when examining the
> output, otherwise we merely get counters of events, rather than the
>
> ability to track individual queries through the system.
>
> To be fair, remember that at the moment we are merely examining where
>
> best to put these things. Particularly in the 6.0 server there are
> some changes that might affect some areas of this. We are also, as I
>
> mentioned originally, trying to be compatible with OS X, but I know
>
> there are some limitations with the current DTrace implementation on
>
> OS X that might make that process more complex than we would like.
>
> > *** Demos ***
> >
> > The following are fairly simple but useful. The scripts are in the
>
> > tar
> > file attached.
>
> It should go without saying that these are pretty cool :)
>
> >
> > *** Suggestions ***
> >
> > here are my suggestions:
> >
> > 1) Probes
> >
> > There are many probes to pick from, which is good, but some are
> > missing -
> > such as probes for the query cache (I have added query cache probes
> in
> > my patch). A quick way to check what might be useful, is to search
>
> > for
> > the DBUG_PRINT calls in the code - if it is instrumented for
> > debugging,
> > it may be useful to instrument it for DTrace.
> >
> > I'd suggest probes to observe:
> >
> > - query cache hits / misses
> > - connection logins (successful and failed)
> > - database startup / shutdown
> > - sorts
> > - replication events
> >
> > Of course, we need to focus on probes that are actually useful at
> > solving real issues, and not create too many unneeded probes.
> > Having a
> > small sufficient set of probes will make it easier to keep the
> > provider
> > as a stable interface.
> >
> > Also, the "-end" probes I think would be better renamed "-done"
> > probes,
> > as is the convention in other DTrace providers (such as "io").
>
> I will pass all of this on. As I said earlier, we are still in the
> early stages of the process and are trying to work out where best to
>
> add the probes, both in terms of the information that can be tracked/
>
> returned and in terms of selecting the most relevant location.
>
> > 2) Probe Arguments
> >
> > The provider really needs many more arguments, and there are plenty
> to
> > pick from in the THD class and what it inherits. Here is what I got
> > going in my suggested patch:
> >
> > Probes,
> > query-parse-start(thr, database, user, host, query)
> > query-parse-done(thr, database, user, host, query, result)
> > query-execute-start(thr, database, user, host, query)
> > query-execute-done(thr, database, user, host, query, result)
> > query-cache-hit(thr, database, user, host, query)
> > query-cache-miss(thr, database, user, host, query)
> >
> > Arguments,
> > (void *)thr THR Class pointer (for raw debugging)
> > (char *)database Database name string
> > (char *)user Username string
> > (char *)host Hostname or IP address string
> > (char *)query SQL Query string
> > (int)result Result (0 == success, -1 == failure)
> >
> > I didn't find thread_id useful (DTrace already has thread IDs), but
>
> > the
> > thr pointer may be useful (both as a unique ID and for raw
> debugging
> > - where
> > pretty much any data can be fetch if you know the offset).
> >
> > The order of arguments is from most to least common. Most probes
>
> > should
> > have thr and database, so they go first, followed by user and host,
> > then specific arguments - such as query string and result.
> >
> > The result argument is invaluable. I picked variables that seemed
>
> > reasonable
> > for that patch - but please check them more carefully (they look fine,
> > but I didn't read all the code).
>
> I'll check this out. It would be nice if we could get some, all or
> more of these into the code.
>
> > There is a lot of very cool info in the THD class, but we need to
>
> > consider
> > stability (and not expose private implementation details).
>
> > For connection/login probes, the Security_context class has some very
> > interesting fields - check them out. Although, they aren't always
>
> > populated
> > (I used "user" and "host_or_ip" in my suggested patch - as they
> seem
> > most
> > frequently populated).
>
>
> There's lots all over the place that we could if we wanted to. I
> think
> the key thing is possibly not what we add, but what we don't add.
> There's a temptation here to add lots and track everything, but we
> have to be sensible...
>
> MC
>
> --
> Martin 'MC' Brown, mc at mcslp dot com
> Everything MCslp: http://planet.mcslp.com
>
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris dot org
>
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
