Is there any *official* plan to have a MySQL provider now? I assume now we have more control to its source tree than before. -- This message posted from opensolaris.org
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.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
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.com Everything MCslp: http://planet.mcslp.com
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.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
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.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
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.com > Everything MCslp: http://planet.mcslp.com > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
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
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 at HOST QUERY root at localhost select * from months root at localhost select * from months where num > 6 root at localhost select * from months where num > 6 and num < 11 root at localhost show tables root at localhost show databases root at 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 at HOST COUNT QUERY root at localhost 1 select * from months where num > 3 root at localhost 1 select * from months where num > 3 and num < 9 root at localhost 1 select num, name from months root at localhost 1 show databases root at 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. # ./mysqld_qchit.d Tracing... Hit Ctrl-C to end. ^C QUERY RESULT COUNT select * from months miss 1 select * from months where num > 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 at HOST ms RET QUERY BrendanDatabase root at localhost 0 0 show databases BrendanDatabase root at localhost 0 0 show tables BrendanDatabase root at localhost 0 0 select * from months BrendanDatabase root at localhost 1 0 select * from months BrendanDatabase root at localhost 14 0 select * from words where nam... BrendanDatabase root at localhost 158 0 select * from words BrendanDatabase root at localhost 51 0 select * from words BrendanDatabase root at localhost 41 0 select * from words BrendanDatabase root at localhost 35 0 select * from words BrendanDatabase root at localhost 35 0 select * from words BrendanDatabase root at 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 at localhost show tables value ------------- Distribution ------------- count 131072 | 0 262144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 524288 | 0 root at localhost show databases value ------------- Distribution ------------- count 524288 | 0 1048576 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 2097152 | 0 root at 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 at localhost select * from words value ------------- Distribution ------------- count 16777216 | 0 33554432 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5 67108864 | 0 root at localhost select * from words where name < ''fish'' value ------------- Distribution ------------- count 8388608 | 0 16777216 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 11 33554432 |@@@ 1 67108864 | 0 In the above output, the "select * from months" query had 1 execution take between 8 and 16 milliseconds, 11 executions take between 0.5 and 1.0 milliseconds, and 9 executions take between 131 and 262 microseconds. Presumably the slow execution (8 to 16 ms) was the first (which DTrace can confirm), which put the data in memory. ... Anyhow, I want to write more scripts - but I''ll need more arguments and probes available first (see suggestions below). Trying to create useful scripts is a good exercise to generate ideas for what else this provider needs to support; which is similar in idea to what Mike and Jon suggested - writing a real world case study would also generate such ideas. *** 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"). 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). 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). cheers, Brendan -- Brendan [CA, USA] -------------- next part -------------- A non-text attachment was scrubbed... Name: mysqld-demos-1.0.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080126/0c6e25fe/attachment.tar>
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.com Everything MCslp: http://planet.mcslp.com
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.com>
Date: Saturday, January 26, 2008 12:17 pm
Subject: Re: [dtrace-discuss] DTrace for MySQL?
To: Brendan Gregg - Sun Microsystems <brendan at sun.com>
Cc: dtrace-discuss at opensolaris.org, Alex Peng <pengjx73 at yahoo.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.com
> Everything MCslp: http://planet.mcslp.com
>
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
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. -- This message posted from opensolaris.org
I should not say "have more control". :) But hopefully our influence should be stronger than before. -- This message posted from opensolaris.org
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
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.org [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of Richard L. Hamilton Sent: samedi 26 janvier 2008 07:41 To: dtrace-discuss at opensolaris.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.org